Re: VC verification (was negative VCs)

David,

I'll let others chime in, but you fundamentally missed the main
technique in my reply.
Anywhere I used => I was summarizing your statement in my own terms to
attempt to close the loop on understanding each other. You repeatedly
took that as a response or an agreement with your point when, in fact, I
was only clarifying that I hear what you are saying so that I can
explain where my opinion differs.
The biggest take away, IMO, is this:

You say:
> Authentication is the process of
> verifying the identity of an entity, so this is definitely
> within scope.
Umm... no. 

Identity is explicitly out of scope.

Further, it doesn't help to use restricted terms that need to have
specific meaning in this community, like "verify" to define
other terms. Authentication is not verification as we mean it.

This whole conversation is about terminology as understood by 
those building the work to date. I'll let others give their opinion of
what these terms mean in our conversation. You and I clearly 
are using key terms with fundamentally different definitions and
my attempts to align our definitions didn't make much headway.

-j

On Sun, Jun 25, 2017, at 05:02 PM, David Chadwick wrote:
> 
> 
> On 25/06/2017 19:52, Joe Andrieu wrote:
>> 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.
> 
> Sorry but I have to disagree with you. Authentication is the
> process of> verifying the identity of an entity, so this is definitely
> within scope.> Issuers have to be identified and their VCs authenticated. (Actually
> when you read on I think you will find in many cases we agree on the
> substance but not on the labels we give them).
> 
>> 
>> 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
>> => claim>> with entity representations in its own model, either relating them to>> entities already known or bootstrapping new entities to associate
>> with the identifiers.
> 
> For the subject yes, but I think the inspector would be hard
> pressed to> bootstap a new trusted issuer at the time of receiving the VC.
> There has> to be a trust relationship between the issuer and the inspector, and
> creating this dynamically at the time of receipt of a VC makes the
> eco-system overly complex in my opinion (at least in the first version> of our work). It would require some sort of TTP to verify the
> trustworthiness of some (currently unknown) issuer. I suggest
> that this> is left for further study and version 2 of the VC ecosystem if we can> get version 1 accepted by people first.
> 
> 
>> 
>> 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.
> 
> It certainly is facilitated, as the VC data model contains the IDs of> both the issuer and the subject (as URIs). If they were absent
> from the> data model then the verification process would not work.
> 
> 
>> In fact, selective and minimal disclosure
>> will make it more challenging as identifiers increasingly become
>> unique, pair-wise, and self-sovereign.
> 
> I don't believe so. The subject can be identified solely by their URI> identifier, which is nothing to do with selective disclosure as the ID> is in the VC. The issuer cannot be selectively disclosed
> either. It has> to be fully disclosed whatever cryptography you are using,
> otherwise the> inspector cannot authenticate the VC.
> 
>> 
>> 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.
> 
> I think the above points are not particularly relevant to
> identification, since the VC contains the IDs of both the subject and> the issuer.
> 
>> 
>>> 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 the process of authentication. So you appear to agree with me> that the VC needs to be authenticated. Perhaps it is solely the use of> terminology where we differ, and not in the substance of the point.
> 
>> 
>> This is what I consider verification in the sense we mean it in
>> verifiable claims.  That is, this is what "verifiable" means.
> 
> Sorry but I disagree with you on this point. There is a big difference> between an authentic claim and a valid claim. The inspector is
> interested in receiving valid claims, not just authentic ones. A claim> can be authentic but invalid e.g. paper money issued by Sadam
> Hussein's> regime is authentic but not valid anywhere for purchasing anything. My> driver's licence is authentic but if you presented it, it would be
> invalid. Issuers are interested in verifying valid claims, and will
> discard all invalid claims, whether authentic or not.
> 
> So the first step of verification is to ensure the claim is authentic,> then the next step is to ensure it is valid. Both are part of the
> verification process.
> 
>> 
>>> 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.
> 
> So we agree on the substance of this point. This in my terminology is> the process of validating the claim and is part of the verification
> process.
> 
>> 
>>> 4. If the subject is 'any/bearer' the verification procedure now
>>>    ends.>> 
>> => In the case of a bearer claim, no further action necessary.
> 
> So again we agree, which is good.
> 
>> 
>>> 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.
> 
> Again, this is a definition of authentication (if you replace 'think'> with 'say').
> 
>> If the subject and presenter are the same entity, stop.
>> 
>> This is only true in cases where the presenter is semantically
>> relevant>> to 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.
> 
> Sorry, but my statement is always true. You are saying that when the
> subject and presenter are different you may also stop, but this
> does not> negate the fact that when they are the same you definitely do stop.
> 
> In fact I would argue that your example is one that requires
> moving onto> step 6. In your example, the presenter is authorised to present the
> claim, because everyone in the world has been authorised to
> present it,> by the very nature of 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. 
> 
> I would say your example is one of a 'public claim' that anyone can
> present. Public claims are quite different to the VCs we normally
> consider, since there is no privacy protection required in a public
> claim.
> 
>> 
>> Your argument suggests that claims about the presenter imply
>> consent.
> 
> When claims contain PII, then the subject does need to give
> consent for> the information to be given to the inspector. This is part of the EU
> data protection legislation (recently strengthened in the GDPR). The
> fact that the presenter (subject) has freely given his/her VC to the
> inspector shows they have consented to the release. So the VC model
> actually supports the GDPR quite nicely.
> 
> 
>> 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.
> 
> If the claim is a public claim (as in your example) then no consent is> needed as the subject's privacy has not been invaded by copying public> information. But if the claim contains some PII of the subject,
> then the> subject does need to give consent for the presenter to present
> it to the> inspector. If the presenter cannot show consent, then in Europe at
> least, the presenter can be prosecuted for violating the
> privacy of the> subject.
> 
> 
>> 
>> 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.
> 
> If you read my earlier exchange with Steven Rowat, you might find that> he has addressed this topic quite nicely.
> 
> 
>> 
>>> 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
>> => must>> ascertain 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.
> 
> In my view, this is part of claim verification, so is part of the VC
> work. In order to fully specify the lifecycle of a VC we need
> to say how> an inspector verifies a claim.
> 
>> 
>> 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.
> 
> We have clearly identified one disconnect between us, and that is the> scope of the verification of VCs. So this is definitely something that> needs to be resolved before we proceed much further, as I suggest it
> will impact on the terminology we use, and perhaps the data model as
> well.
> 
> regards
> 
> David
> 
>> 
>> -j
>> 
>> --
>> Joe Andrieu, PMP
>> joe@joeandrieu.com <mailto:joe@joeandrieu.com>
>> +1(805)705-8651
>> http://blog.joeandrieu.com
>> 
> 

--
Joe Andrieu, PMP
joe@legreq.comLEGENDARY REQUIREMENTS
+1(805)705-8651Do what matters.
http://legreq.com[1]


Links:

  1. http://www.legendaryrequirements.com