Re: Terminology poll

I like issuer, claimant and verifier.

Issuer is not contentious. Verifier is not so contentious and has been
posed before.

But claimant is a new term for the contentious role of the presenter, or
holder, who may or may not be the subject of the VC. Claimant sums up
quite nicely what this role is trying to do i.e. claim the benefit from
the VCs that they are presenting to the verifier.

So I would support the use of the term claimant.

David

On 23/06/2017 22:12, Joe Andrieu wrote:
> I like reviewing the NIST docs to synchronize language.
> 
> One general note: I am wary of using the language of rights anywhere in
> our language unless it is specifically listed in the claim itself, e.g.,
> rights referenced in a terms-of-use reference, granted either by the
> issuer or the claimant. That is, when the creation or transfer of a
> claim is bundled with certain rights.
> 
> Using "rights" to describe the holder is problematic because if we model
> real-world credentials like a driver's license or passport, the person
> who presents the credential may or may not have any right to do so.
> Certainly the credential doesn't contain restrictions on whether or not
> my wife can send a copy of my passport to the travel agent. The
> credential itself describes certain rights that the subject has... not
> the holder. The exception of course is bearer tokens, but that's the
> exception that proves the rule. Generally the literal holder of the
> datagram or holder of a reference to a datagram need not have any rights
> even if they have certain capabilities.
> 
> Part of what I want to be careful about is that the data model itself
> need not preclude any particular storage or transmittal architecture.
> The assertion by a claimant that they are the subject of a particular
> claim is exogenous to the claim.  We often assume that's how they will
> be used, but a significant portion of the flexibility of verifiable
> claims are that each claim stands on its own. If it represents a valid
> driver's license, it doesn't matter who presents it. The privileges
> afforded are to the subject of the claim, not its holder. I think it is
> key that our language supports this more flexible usage as it will
> enable far more use cases than we will be designing for, without
> complicating our model. In fact, it should simplify it.
> 
> In that vein, I want to suggest two equally valid approaches to naming
> the roles and it will probably help if all three names use the same
> approach.
> 
> One approach would be to focus on the action taken by each party in
> relationship to the actual claim as it is embodied in JSON-LD or some
> other serialization, e.g., issuers issuer, claimants claim, verifiers
> verify.
> 
> Another would be to focus on the the relationship of the party to the
> statement made within the claim: author's make statements, asserters
> present the statement, evaluators evaluate the statement.
> 
> FWIW, the second set was harder for me to think through. We don't have
> much language in our discourse about that secondary presentation of the
> statement as opposed to those who authored it. I tried "herald". Trump
> has a press secretary. Brands have spokespersons. "Asserter" seemed the
> least annoying.
> 
> My heart wants language that is focused on the statements because that's
> where the real meat of the claims are. The underlying reason to have
> verifiable claims is because we want to be able to reliably move
> statements around.
> 
> However, my brain think language focused directly on the actions taken
> with a given claim is simpler and probably clearer without losing any of
> the specificity of the role.
> 
> So, fwiw, I'm leaning toward issuer, claimant, and verifier, which also
> aligns well with NIST and definitely wasn't my first suggestion when we
> started this conversation, so I'm appreciating the discourse.
> 
> -j
> 
> 
> On Fri, Jun 23, 2017, at 04:38 PM, Christopher Allen wrote:
>> I note that NIST has just released a major new version of their
>> digital identity guidelines https://pages.nist.gov/800-63-3/ 
>>
>> In the first document, https://doi.org/10.6028/NIST.SP.800-63-3 on
>> page 15 describes their process (with illustration on 16)
>>
>>     "In these guidelines, the party to be authenticated is called a
>>     claimant and the party verifying that identity is called a
>>     verifier. When a claimant successfully demonstrates possession and
>>     control of one or more authenticators to a verifier through an
>>     authentication protocol, the verifier can verify that the claimant
>>     is a valid subscriber. The verifier passes on an assertion about
>>     the subscriber, who may be either pseudonymous or
>>     non-pseudonymous, to the RP. That assertion includes an
>>     identifier, and may include identity information about the
>>     subscriber, such as the name, or other attributes that were
>>     collected in the enrollment process (subject to the CSP’s
>>     policies, the RP’s
>>     needs, and consent for disclosure of attributes given by the
>>     subject). Where the verifier is also the RP, the assertion may be
>>     implicit. The RP can use the authenticated information provided by
>>     the verifier to make authorization decisions.
>>
>>     Authentication establishes confidence that the claimant has
>>     possession of an authenticator(s) bound to the credential, and in
>>     some cases in the attribute values of the subscriber (e.g., if the
>>     subscriber is a U.S. citizen, is a student at a particular
>>     university, or is assigned a particular number or code by an
>>     agency or organization). Authentication does not determine the
>>     claimant’s authorizations or access privileges; this is a separate
>>     decision, and is out of these guidelines’ scope. RPs can use a
>>     subscriber’s authenticated identity and attributes with other
>>     factors to make authorization decisions. Nothing in this document
>>     suite precludes RPs from requesting additional information from a
>>     subscriber that has successfully authenticated.”
>>
>>
>> Clearly they have two different processes. (I’m bolding the roles and
>> verbs/adverbs:)
>>
>> First:
>>
>> An *applicant* *applies* to a *CSP* through an *enrollment* process.
>> 2. The *CSP* identity *proofs* that applicant. Upon successful
>> *proofing*, the applicant becomes
>> a *subscriber*.
>> 3. *Authenticator*(s) and a corresponding credential are *established*
>> between the CSP and the
>> *subscriber*.
>> 4. The *CSP* *maintains* the credential, its status, and the
>> enrollment data collected for the
>> lifetime of the credential (at a minimum). The subscriber *maintains*
>> his or her authenticator(s).
>>
>> Then:
>>
>> 1. The *claimant* proves possession and control of the
>> *authenticator*(s) to the *verifier* through an authentication protocol.
>> 2. The *verifier* interacts with the *CSP* to validate the credential
>> that *binds* the subscriber’s identity to their *authenticator* and to
>> optionally obtain claimant attributes.
>> 3. The *CSP* or *verifier* provides an *assertion* about the
>> subscriber to the RP, which may use the information in the *assertion*
>> to make an authorization decision.
>> 4. An authenticated session is established between the subscriber and
>> the RP.
>>
>> Some clear differences because this is an older, centralized model,
>> but maybe a little harmony is possible?
>>
>> ===
>>
>> Biggest thing I see so far is that their role of verifier and our role
>> of inspector are very close.
>>
>>     Verifier - An entity that verifies the claimant’s identity by
>>     verifying the claimant’s possession and control of one or two
>>     authenticators using an authentication protocol. To do this, the
>>     verifier may also need to validate credentials that link the
>>     authenticator(s) to the subscriber’s identifier and check their
>>     status.
>>
>>
>> This makes me lean to our use of Verifier over Inspector.
>>
>> ====
>> They have a concept of Subscriber which we don’t have, however, the
>> party that gives data we are calling the Holder — maybe we are naming
>> the wrong side? Instead of the holder proving that they have the right
>> to send a claim, instead we say that the subscriber needs to
>> demonstrate the right to send the data?
>>
>> I kind of like this distinction. as it puts the burden of proof of
>> right to have the information differently. Instead of our:
>>
>>     A Holder presents claims (either directly or indirectly) to an
>>     Inspector.
>>
>>
>> Instead it would be:
>>
>>     A Subscriber presents claims (either directly or indirectly) to a
>>     Verifier.
>>
>> We would likely need to add someplace that the Verifier has to ALSO
>> prove that the subscriber has rights to present claims.
>>
>> ====
>>
>> The harder problem is our question of Issuer/Authority/Author
>>
>> They don’t use a simple word for this, but instead use two different
>> sources, the CSP and the IDP
>>
>>     Credential Service Provider (CSP)
>>     A trusted entity that issues or registers subscriber
>>     authenticators and issues electronic credentials to subscribers. A
>>     CSP may be an independent third party or issue credentials for its
>>     own use.
>>
>>     Identity Provider (IDP)
>>     The party that manages the subscriber’s primary authentication
>>     credentials and issues assertions derived from those credentials.
>>     This is commonly the CSP as discussed within this document suite.
>>
>>
>> However, as both parties “issue” in their definition, I slightly lean
>> to Issuer over Authority.
>>
>>
>> — Christopher Allen
>>
>>
>>
> 
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com <mailto:joe@joeandrieu.com>
> +1(805)705-8651
> http://blog.joeandrieu.com
>

Received on Friday, 23 June 2017 22:09:57 UTC