- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 13 Jun 2016 12:21:45 +0000
- To: David Chadwick <d.w.chadwick@kent.ac.uk>, public-credentials@w3.org
- Message-ID: <CAM1Sok13q-G=bOXeziCiJbEcPkY2gf8RanjQCt7XTFc5sNS0fg@mail.gmail.com>
I'd say the issuer and the holder are both legal entities. However, given we've been fragmented away from the ID layer; we would surmise that the Issuer has been able to be ID'd and that an ID will relate somehow to the Holder, assuming i'm not going to be holding someone else's passport to 'pass off' as my own online. the simple use-case of saying 'i am over 18' may otherwise be a bit like - 'here's my mums credit card for in-game gems'... not what we want really is it... But beyond the problem of what is out of scope - what is in scope, and the terms we use for what is in-scope should relate to the legal entity IMHO. I also suggest it is important to ensure we have notated the use of a group or chain of linked credentials in-our use-cases. Only human actors are really responsible for actions. whether they do so for a company, bot, or other 'thing' (understanding companies are legal entities whereas bots, cars, fauna / flora would likely be considered property) a human is still involved in making decisions. they may do so by way of consensus or vote; but it is still a group of humans involved in making decisions. therefore; if the medical registration board agrees that subject 128846669247#237afPPdfG = Jane Doe who is issued a credential for practicing medicine for the specific disciplines of general practice; and thereby is also issued medical practitioner insurance plan for her specified services under specified conditions; and through so doing any of the following happens 1. someone uses her credentials to prescribe drugs that are later found to have been prescribed fraudulently 2. treats a patient but fails to check for something that later causes a medical crisis event 3. prescribes drugs that react badly with the patient (whether or not the patient used the medication as prescribed) 4. is in attendance of a medical emergency outside of the scope of her insured and approved registration (but may be able to immediately obtain approval via an online / emergency services interaction); then... 5. Because we're not doing the ID system - if fraud happens it's not a problem with the credentialing system, it's the ID system that someone else made that's been bonded to this thing. 6. The chain of credentials that can develop may interoperate with, within reason, any form of ID system as to support 'entity credentials' (or whatever they'll be called) and no-one system needs to be the holder of all relevant creds for the business system. (therein: use of linked-data) In summary; I think the benefits of our designs really start to become highlighted not in the singular document use-cases, but rather when a plurality of documents are used in an interrelated manner across disparate yet web-connected systems. We have an ID/AUTH problem; Creds helps solve some of that by enabling the 3rd parties to make claims about person/s and/or things. That's important for solving the broader identity problem - but it is not the traditional, blunt instrument approach - nor should we consider this work in the specificity we've been asked to deliver, be considered a golden hammer for ID. yet; i note it seems there is a distinction between what we can promote to the IG/WG vs. what we can 'play with' in the CG 'where the wild things are'.. i'll say it again; Web-DHT seems like something that's got real merit for utility in association with a social-distribution for ID/AUTH support of humans; and other agents can hang off that capability. I do think the WebID group - we should seek to integrate it their, yet, i think we can still do some 'visionary' incubation of the concepts prior to shipping it off to a better home. I think the two fields will interoperate. Perhaps labelling the work as 'socially encrypted documents' (that in-turn could be used for ID/AUTH) could mitigate any issues people have about religion and ID. Tim.H. On Mon, 13 Jun 2016 at 17:59 David Chadwick <d.w.chadwick@kent.ac.uk> wrote: > > > On 12/06/2016 22:13, Steven Rowat wrote: > > On 6/12/16 1:32 PM, David Chadwick wrote: > >> I believe the latest definition of claim in the architecture document > >> > >> http://w3c.github.io/webpayments-ig/VCTF/architecture/ > >> > >> is fundamentally wrong. It says > >> > >> Claim > >> A statement made by an entity about a subject. For example: "Jane is > >> a doctor." > >> > >> The example is not one claim, but two claims. It claims that the subject > >> is a doctor and that the subject is called Jane. We should rewrite this > >> to say > >> > >> Claim > >> A statement made by an entity about a holder. For example: "The > >> holder is a doctor." > > > > +1 > > So, "The holder's name is Jane" is separate claim. > > > > Then, sorry to partially hijack your thread, but as an interesting > > extension, I can relate this to my other concern about pseudonyms > > (aliases), and make a third claim: > > > > "The holder has a pseudonym 'George'". > > > > This leads specifically to the interesting fact that the simple 'name' > > of Jane is implied to be the 'legal name' (unless stated otherwise). > > > > So perhaps it would be best to always make that explicit. Otherwise it's > > ambiguous -- what sort of name is it? Who calls Jane Jane? > > > > Claim: The holder has legal name 'Jane'. > > Claim: The holder has pseudonym 'George'. > > This can be addressed in a couple of ways (at least) > > 1. Who is the issuer? If the issuer is a legal entity, this implies the > name is a legal one, whereas if the issuer is the holder, it implies a > pseudonym. > 2. The attribute can be subclassed so that the holder/issuer can decide > to issue either a generic name claim, or a specialised name claim (such > as pseudonym, legal name etc.) > > regards > > David > > > > Claim: The holder is a doctor. > > > > Steven > > > >> > >> > >> regards > >> > >> David > >> > >> > >> > >> > > > > > >
Received on Monday, 13 June 2016 12:22:25 UTC