W3C home > Mailing lists > Public > public-credentials@w3.org > June 2017

Re: Terminology poll

From: Christopher Allen <ChristopherA@blockstream.com>
Date: Fri, 23 Jun 2017 13:38:05 -0700
Message-ID: <CA+HTxFd=YNSNXj7fQAa0ZiH5FCK47VzG0Apygoi16xMRafD9uw@mail.gmail.com>
Cc: "W3C Credentials CG (public list)" <public-credentials@w3.org>
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
Received on Friday, 23 June 2017 20:39:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:38 UTC