Re: Negative VCs

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