Can NIST E-Authentication Guideline SP 800-63-1 Support a Token-Attribute Separation Model?

In “A model for separating token and attribute manager functions”, I provided some examples of how that model could be mapped to instances of current online application architectures. In this blog post, I would like to explore if the components used to calculate authentication assurance levels in NIST SP 800-63-1 can be mapped into the model.

I very much appreciate the comments and feedback on the earlier post from the many corners of the identity-web Drummond Reed, Kantara Initiative, IDESG Trust Framework & Accreditation Listserves etc. As was explored by many, there are a multitude of ways you can slice-n-dice the partitioning of roles to an organization between the two extremes given below:

While that is a useful exercise, in this post I would like to explore what it would take for NIST SP-800-63-1 (PDF), arguably one of the foundational documents on identity assurance, to support the de-coupled model. Note the following statement in the NIST document, which is rather relevant to this discussion:

Current government systems do not separate functions related to identity proofing in registration from credential issuance. In some applications, credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties. While a simpler model is used in this document, it does not preclude agencies from separating these functions.

NIST SP-800-63-1

In NIST 800-63-1 the calculation of authentication assurance is the “low watermark” of the following components:

• Identity proofing and registration
• Issuance of token or combination of tokens
• Binding between identity proofing and tokens (if done separately)
• Token and credential management processes
• Authentication protocols
• Authentication assertions (if used)

Each of the components have an associated assurance level (1-4) and as you go up the levels, the requirements/responsibilities increase. The calculation of the overall assurance level is the lowest number when looking across the individual components i.e. “low watermark”. (There is no 2.5, 3.5 etc.) This is based on the concept that you are only as strong as the weakest link in the chain, and an attacker will target the least assured piece of the credential issuance process.

Given that the registration, identity proofing, token creation/issuance and credential issuance may very well be separate physical encounters or electronic transactions, there are requirements (at each level) to make sure that the same person is moving through the process.

A potential way forward could be to clearly separate out the token and credential management processes, which currently are done by a single “Credential Service Provider”. This results in the following components:

It then becomes relatively simple to assign individual components to the roles identified in the model. At the same time, it is critical to make sure that there continues to be processes in place to assure, to the required level, that the same person is moving through the various component processes. Especially since roles may be split across organizations.

The question of whether this is an interpretation of the existing NIST guideline, or requires actual change to the existing guideline to utilize is an interesting one that I will punt on for now. But I would be interested in feedback as to whether there is interest in that answer, or even if it is the right question.

RELATED INFO

• A Model for Separating Token and Attribute Manager Functions
• Anonymity in the Token and Attribute Manager Separation Model
• NIST Electronic Authentication Guideline (NIST SP-800-63-1) (PDF)
• NIST SP-800-63-1 Token Assurance Level Escalation Matrix
• How to rest assured
• Credential Manager in the Token and Attribute Manager Separation Model