Inconsistency in presentation

[David-Chadwick]

In section 2 'presentation' is defined as follows

Data derived from one or more credentials, issued by one or more issuers, that is shared with a particular entity.

then 'verifier' is defined as follows

A role an entity may perform by receiving one or more verifiable presentations for processing.

These two definitions are inconsistent because presentation implies that any type of entity can receive a presentation, whilst verifier says that an entity is a verifier if it receives a presentation.

SOLUTION

change the presentation definition to state

Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a verifier.

Note the above is consistent with the definition of verifiable credential.

[jandrieu]

Hmmm... I like this. It is a modest correction that I believe improves readability and clarity.

However, our definitions are still a little off.

Technically the verifier is the one who verifies the integrity of the credential, which may or may not be the entity who receives the presentation from the presenter/holder. One could imagine needing to send a presentation through an intermediary for any number of reasons. The important thing is not the receipt of the presentation from the creator of that presentation, but rather the evaluation of a presentation for authorial integrity (determining, to the best of our ability, whether or not the utterances embedded in the presentation were made by the alleged issuers and do those issuers still stand by them). There are a lot of situations where the relying party with outsource the verification check, where the verifier actually doesn't rely on the utterance in the claim at all; they merely pass on the results of their evaluation to the actual party using the claims.

We have similar conflicts with holder/presenter. The distinguishing characteristic of the holder is that they take one or more credentials--perhaps ones they created, but they could be issued to them, given to them by an ally, or literally found online, published publicly--and create a presentation that is, by definition, a self-asserted relating of those credentials to themselves. That is, the holder is acting as an issuer when creating a presentation with the unique characteristic that the verifier is not expected to accept those assertions based on authority, but rather based on the evaluation of the presented information. (Whereas issuers' claims are typically evaluated based on their authority, e.g., the DMV).

For example, in the focal use case of claiming citizenship, our protagonist/holder creates a presentation saying, in effect, "Person X is my mom. My mom is a US citizen. I claim U.S. citizenship. Here's some evidence." These assertions, on their surface--without evaluating the claims in the attached evidence, aren't worthy of acceptance as true; anyone could claim those "facts". However, they are vital to understand why the holder is presenting that evidence in the first place. The relying party, in consideration of the evidence, may accept those assertions as true, provisionally true, or reject them as false, but what is indelible is that the holder has asserted their truth. In other words, the holder is claiming some assertion that is supported and/or derivable from the attached credentials.

In the classic case of a digital driver's license, the assertion by the holder is that the driver's license is theirs (this is not the case of an administrative assistant giving the license to the travel agent). Of course, the relying party is going to use some heuristics to decide if that is believable, beyond the simple cryptographic and procedural verification that the license itself is valid. With physical driver's licenses, this is essentially a subjective sniff test of comparing the photo, age, and other descriptive information to the claimant. Once the relying party accepts that (1) the underlying credential is valid and (2) the claimant/presenter seems to be the individual they claim--in relation to the credential, THEN they will act on the verity of the claims.

Many argue that proof of control of keys is sufficient to verify the claimant is the subject of any given credential. This may be true for most use cases, but there are definitely cases where it pays to take the extra step to corroborate what might be known about the subject with the party that is currently claiming that identifier. 100% reliance on keys simply establishes keys as the perfect hack vector. In practice, additional checks to establish superiority of information will be used for interactions of any material significance.

I'm not sure the best way out of this ambiguity. Term momentum makes these sorts of learnings hard to incorporate in a consensus process.

[stonematt]

Tactical approach: make a PR to incorporate @David-Chadwick input/suggestion here and open a discussion about the issues that @jandrieu raised in his response.

[David-Chadwick]

Has anyone volunteered to do this PR?

[msporny]

This was fixed in #272, closing.