Re: Terminology poll

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
+1(805)705-8651
http://blog.joeandrieu.com