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