- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Sun, 25 Jun 2017 10:37:00 +0100
- To: public-credentials@w3.org
On 24/06/2017 20:30, Joe Andrieu wrote: > David, > > I can see where it reads that way, but I'm not making that assumption at > all. > > Relating the subject to any particular entity is dealt with outside the > claim. There may be enough information in the claim itself to do the > correlation or it may need to be done externally either in context or > based on other data. This is a problem of authentication, not verification. To be more precise, verification comprises authentication and identification. In order to verify a claim I think that the following procedure is needed: 1. The inspector needs to first identify the issuer and the subject. 2. The inspector then needs to authenticate that the VC was issued by the identified issuer and has not been revoked since issuance. 3. The inspector then needs to verify that the issuer is trusted to issue the contents of the claim. 4. If the subject is 'any/bearer' the verification procedure now ends. 5. Otherwise the inspector needs to authenticate the presenter. If the presenter is the subject the verification procedure ends. 6. If the presenter is not the subject then the inspector needs to verify that the presenter is authorised to present the claim. This can be done in a variety of ways e.g. a pre-established trust relationship between the inspector and presenter; a VC delegating authority from the subject to the presenter; a recognised procedure for certain classes of subject and presenter; etc. You seem to think that the VC verification model should stop at step 3. I would argue that these steps are necessary but not sufficient for verifying VCs. The VC verification process should comprise all steps necessary for the inspector to determine whether to keep the VC or discard it as untrustworthy. regards David > > Of course, if the subject is uncorrelatable through any means then the > claim can't be tied to a specific entity, then the > inspector/verifier/relying-party will have a hard time applying the claim. > > However, one could generate random pseudonymous unique identifiers and > use those to collect a set of claims from various issuers, presenting > the set of claims as a related set and the RP could correlate across > those claims some relevant fact. For any given claim the subject appears > random and private, but isn't in fact in the context the set of claims. > Each of those claims are valid, even if useless in isolation. > > In the case of a truly noncorrelatable subject, i.e., the random unique > number private to the subject, the claimant still doesn't *have* to > prove anything for the claim to be valid. The claim, however, may be > useless. Which is fine. Not all verified claims are going to be useful. > But bearer claims exactly fit this use case. The bearer of this claim > *is* the subject of the claim and due the privileges associated with the > claim. > > We don't want to conflate the possibility of authenticating the claimant > as the subject with it being an innate requirement of Verifiable Claims. > Nor do we want to require some proof of rights or relationship between > the claimant and subject. These are outside the scope of the claim > itself. That's why I say that ROLE_B doesn't innately have to prove > anything. > > The claim--including its means of verification such as checking for > revocation--stands on its own. If we presume any relationship between > the claimant and the subject we are baking in some serious limitations > to verifiable claims and introducing exogenous verification of the > relationship, which I think would be a mistake. > > Claimants present claims. That's simple. Authentication, delegation, and > proving right to use, are external to the claim. > > There is one exception that I can see, where an issuer includes a TOS > clause that explicitly affords the right to be a claimant to a specific > entity--which may or may not be the subject. In fact, I think that's a > fairly useful TOS: this claim only applicable when presented by the > subject as authenticated by procedure X. This is issue > #48 https://github.com/w3c/vc-data-model/issues/48 > > -j > > > On Sat, Jun 24, 2017, at 08:57 AM, David Chadwick wrote: >> Joe you are making a very big assumption in your message below that is >> not always true, and this is that the inspector can know from viewing >> the VC who the subject is (viz: "I might publicly post academic >> credentials to my linkedin profile"). This might be true if the subject >> has a globally unambiguous identifier that is publicly known to the >> world (as in your LinkedIn case), but if the identifier in the VC is >> some random number that is private to the subject, then what you say is >> not true. You need to cater for this (more difficult) case as well. Once >> you do, you will find that your (easier) case is covered by that >> solution as well. >> >> regards >> >> David >> >> On 24/06/2017 00:42, Joe Andrieu wrote: >> >> I don't follow the need for ROLE_B to prove anything. Nothing in the >> data model provides any proofing for the holder/presenter/claimant. In >> many use cases the relationship of the claimant to the subject is >> immaterial or at least exogeneous to the claim. >> >> Consider that I might publicly post academic credentials to my >> linkedin >> profile and that a recruiter or potential boss includes those >> credentials in recommending to HR that I come in for an >> interview. The >> credentials themselves hold the entirety of the verification required >> for the relying party/verifier/inspector, aka HR, to decide >> whether the >> credentials are valid. >> >> At no time does it matter whether or not the particular >> holder/claimant/presenter is authorized to provide the claim. >> >> In the case of negative claims, I think this is even more true. If a >> background check on me finds verifiable claims that, e.g., I failed >> physics three times or had a crappy GPA, etc., the claim >> infrastructure >> doesn't care if the claimant is an authorized representative. >> >> Seems to me the important thing about the claimant isn't whatever >> rights >> they have or what they've been authorized to do, it is simply what >> they >> do: present a claim. Whether or not presenting that claim is >> appropriate in the context in which it is presented is a completely >> different problem. >> >> -j >> >> >> On Fri, Jun 23, 2017, at 06:38 PM, David Chadwick wrote: >> >> I think that most of us have been assuming that VCs are always >> positive >> and confer some benefit on the subject. Common examples used >> by us have >> been passport, credit card, club membership etc. >> >> But what about negative VCs, such as a criminal record, >> 'points' on your >> driving licence, or failure to pay a bill on time etc. >> Subjects are >> going to be reluctant to present these to verifiers, >> especially if this >> would remove any benefit that they were hoping to obtain from the >> verifier's online service. In this case the VCs might be >> presented by >> someone other than the subject of the VC, and by someone not >> wishing to >> represent the subject of the VC. >> >> For this reason I would support the following alternative >> wording in the >> Terminology Playground >> >> ROLE_B is typically the Subject of Claims. In some >> circumstances, where >> the ROLE_B is not the Subject of the Claim, then ROLE_B must >> be able to >> prove that they are 'authorised to provide the claim'. This is a >> preferrable alternative to 'has the authority to represent the >> Subject >> of the Claims', as it covers the latter case as well as a >> third party >> providing negative VCs to a verifier. >> >> regards >> >> David >> >> >> -- >> Joe Andrieu, PMP >> >> joe@legreq.com <mailto:joe@legreq.com> >> <mailto:joe@legreq.com> >> LEGENDARY REQUIREMENTS >> >> +1(805)705-8651 >> Do what matters. >> >> http://legreq.com >> <http://www.legendaryrequirements.com> >> >> >> > > -- > Joe Andrieu, PMP > joe@legreq.com <mailto:joe@legreq.com> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. > http://legreq.com <http://www.legendaryrequirements.com> > >
Received on Sunday, 25 June 2017 09:37:38 UTC