A Model for Separating Token and Attribute Manager Functions

Some time ago I attended an event at which some members of the Kantara Initiative Identity Assurance Working Group presented “an approach to separating credential provision functions from identity attribute functions” (PDF). I’ve given this a bit of thought and, using their work as a starting point, modified it to incorporate terminology consistent with the NIST Electronic Authentication Guideline (SP 800-63-1)

As noted in the Kantara IAWG draft paper, the model shows the abstract components of the ‘system’ and how they interact. Where I have differed from the paper is in the use of the “Token Manager” role instead of a “Credential Manager” role, and in the use of “Token” instead of “Credential”. The reason for my divergence is to maintain consistency with NIST SP 800-63-1 in its use of the terms “token” and “credential”, and to avoid overloading terms:

Token: Something that the Claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the Claimant’s identity. In the e-authentication context, a token contains a secret to be used in authentication processes. Tokens are possessed by a Claimant and controlled through one or more of the traditional authentication factors (something you know, have, or are).

Identity: A set of attributes that uniquely describe a person within a given context.

Credential: An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a Subscriber. While common usage often assumes that the credential is maintained by the Subscriber, this document also uses the term to refer to electronic records maintained by the CSP which establish a binding between the Subscriber’s token and identity

In the above model, I also note the following clarification for the roles:

<div class=“table-responsive”>

</div>

Some salient points:

• Model does not show timing or sequence
• An entity may possess multiple tokens and identity records
• Binding between the token and identity record may take as input multiple tokens and/or multiple identity records
• Model does not assign any of the roles to a real organization

A value of this model is for it to serve as a framework for discussion around the mapping of specific roles to specific entities, and what some of the potential trade-off’s (business/incentive/technical) would be.

Mapping to the NIST SP 800-63-1 E-Authentication Architectural Model:

Mapping to the Canadian “anonymous credential” model</a> implemented via their Credential Brokering Service:

Mapping to the current model implemented by the US Social Security Administration for the my Social Security Application:

Mapping to the consumer facing implementation of facebook and Google+:

More to come. Comments and feedback are appreciated.

RELATED INFO

• Credential Manager in the Token and Attribute Manager Separation Model
• Anonymity in the Token and Attribute Manager Separation Model
• Can NIST E-Authentication Guideline SP 800-63-1 Support a Token-Attribute Separation Model?
• An approach to separation of credential provision functions from identity attribute functions in the KI IAF and SAC (PDF)
• Approaches to separation of Identity and Credential Management in IAF and SAC (PDF)
• NIST Electronic Authentication Guideline (NIST SP-800-63-1) (PDF)