VC verification (was negative VCs)

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
>

Received on Sunday, 25 June 2017 21:03:17 UTC