- From: Joe Andrieu <joe@joeandrieu.com>
- Date: Sun, 25 Jun 2017 14:52:05 -0400
- To: public-credentials@w3.org
- Message-Id: <1498416725.2720719.1020713312.2F8AA5DF@webmail.messagingengine.com>
Good discussion. I've done my best to trim my response. My apologies for its length. On Sun, Jun 25, 2017, at 05:37 AM, David Chadwick wrote: > To be more precise, verification comprises authentication and > identification. I appreciate where you're coming from, but I think authentication is explicitly out of scope for VCs. I'll restate see if I'm understanding what you meant, prefixing with =>. > 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. => The inspector needs to correlate the issuer and subject in the claimwith entity representations in its own model, either relating them to entities already known or bootstrapping new entities to associate with the identifiers. This is innate to applying the claim to the internal model of the inspector. An important step, but not one particularly facilitated by the VC architecture. In fact, selective and minimal disclosure will make it more challenging as identifiers increasingly become unique, pair-wise, and self-sovereign. For example, verifiable claims don't depend on a centralized registry for looking up public keys for well-known entities. This, IMO,is fundamental to the principle that anyone can issue a claim about anything. There is no PKI or DNS to anchor a root identity authority. However, there is also nothing keeping an issuer from using PKI, DNS, or DIDs from publishing well-known IDs and associated keys for use in Verifiable Claims. > 2. The inspector then needs to authenticate that the VC was issued by> the identified issuer and has not been revoked since issuance. => Given the cryptographic signature, the id of the issuer and a potential external revocation method, the inspector determines whether or not the statement is legitimate. This is what I consider verification in the sense we mean it in verifiable claims. That is, this is what "verifiable" means. > 3. The inspector then needs to verify that the issuer is trusted to > issue the contents of the claim. => The inspector then judges the merit of a claim based on the contents of the claim and its own trust model of the issuer for the statement in the claim. This is true of any data acquired by the inspector. Fundamentally, the inspector has to decide who to trust for what types of assertions. > 4. If the subject is 'any/bearer' the verification procedure now ends. => In the case of a bearer claim, no further action necessary. > 5. Otherwise the inspector needs to authenticate the presenter. If the> presenter is the subject the verification procedure ends. => The inspector then needs to ascertain if the presenter is who they think it is. If the subject and presenter are the same entity, stop. This is only true in cases where the presenter is semantically relevantto the statement. If the statement is that the "The president denies the allegations of misconduct." and the issuer is authenticated as the White House Press Secretary, then it doesn't matter who presents the claim. Perhaps you could say statements of this kind are "bearer claims" but that seems odd to me. It is an independent claim. Maybe that's a better term for claims independent of the presenter. Your argument suggests that claims about the presenter imply consent. That's valid, but the inverse is not. Just because the claim is not about the presenter doesn't imply a separate consent from the subject is necessary. If it does, we have a lot more work to do. This begs the question "Are VCs designed to be dependent on the presenter?" Nowhere in our literature do we make that assertion, but I think it is an expectation underlying many of comments in the terminology discussion. My interpretation is that there is no innate semantic assertion about the presenter when presenting a claim about a different subject.This is the crux of the disconnect. There is no consensus language about the meaning of presenting a claim. There is agreement that the presenter need not be the subject, but not about what they *do* need to be. > 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. => If the presenter and subject are distinct entities, the => inspector mustascertain if the presenter is authorized to present the claim. In some cases, this is entirely appropriate. However, this process of authorization is, IMO, a part of the inspectors role in evaluating the merits of a given claim. So far, we don't have hooks for limiting who the presenter can be nor defining how authorization of a presenter would be handled. To wit, nowhere in the data model do we mention an identifier for the presenter. However, we probably do need to make sure a TOS field is available for credentials, claims, and profiles. https://github.com/w3c/vc-data-model/issues/48 This could be the hook that enables authentication and authorization of a presenter, but to date we have no language addressing this requirement. > 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. That's right. "Verifiable" in the sense of Verifiable Claims is specifically limited to the mathematical proof of the cryptographic signature combined with the procedural proof of non-revocation. That's it. Authentication, authorization, evaluation for merit, are all outside the scope of Verifiable Claims data model. Yes, these are vital for understanding how Verifiable Claims are going to be used in practice and our use cases should explore these requirements, however, they are not embedded in the promise of "verifiable". I think it is important that a VC can be "verified" without dependence on the quality of the authentication, authorization, and merit determinations of the inspector. The quality of those processes are outside our remit. What we can control is how one verifies that a given statement was legitimately made by a given issuer. That's hugely powerful. I think we should avoid implying benefits beyond that. So, while I agree that the extra steps you describe are likely tasks for many use cases, they are not innate to VC and as such, should not drive terminology. Which is to say, defining the claimant/holder/presenter as "presenter of profiles" or "presenter of claims" is the most rigorous option, without attempting to require any rights or privileges with respect to said presentation. What's important is that they do the presenting, not that such presentation is appropriate, authorized, or allowed. If it is inherent in VCs that all presenters are authenticated and authorized, we have a ton of work to do on the data model before its ready for FPWD. If I'm off base on my understanding of what VCs are designed to do, I'm open to being corrected. -j -- Joe Andrieu, PMP joe@joeandrieu.com +1(805)705-8651 http://blog.joeandrieu.com
Received on Sunday, 25 June 2017 18:52:34 UTC