Anonymity in the Token and Attribute Manager Separation Model

The ability to conduct transactions using anonymous, pseudonymous or fully verified credentials, depending on context, is core to the success of online services. In this blog post, I take a deeper look at the token and attribute manager separation model to see what flexibility exists to enable this capability, and discover that the choices available are not constrained by architecture but by policy.

As explained in the previous blog post on this topic, the three roles that are relevant to this discussion are that of the Token Manager, the Attribute Manager and the Credential Manager. Please note that I renamed the “Token-Identity Link Record Manager” in the previous blog post, which is an unwieldy mouthful, to “Credential Manager” given that the “Token-Identity Link Record” fits the definition of a “Credential”.

The salient point to understand is what the Credential Manager is embedding within the binding between the Token and the Identity Record (as part of the creation of the Credential) based on the identifier/”look-up key”/pointer provided by the Attribute Manager. In particular, can that item be an a opaque identifier, a pseudonym or does it need to be the verified name of the person?

Looking at this from a purely technical and architectural perspective, there does not appear to be any such restriction and the model fully supports all. As such the choice of what is used becomes a policy decision which will vary across jurisdictions.

To take this through its natural conclusion, let me take a look at how the US Federal Government’s policy on this topic, as articulated by OMB M-04-04 (PDF) and the associated technical guidance from NIST SP 800-63-1 (PDF) could be mapped to these particular aspects of the model.

The policy, as applicable to Federal Government IT systems, is stated in OMB M-04-04:

Attribute authentication is the process of establishing an understood level of confidence that an individual possesses a specific attribute. If the attribute does not provide ties to the user’s identity; it would be considered an anonymous credential. […] anonymous credentials may be appropriate to use to evaluate an attribute when authentication need not be associated with a known personal identity.

To protect privacy, it is important to balance the need to know who is communicating with the Government against the user’s right to privacy. This includes using information only in the manner in which individuals have been assured it will be used. It may be desirable to preserve anonymity in some cases, and it may be sufficient to authenticate that:

• The user is a member of a group; and/or
• The user is the same person who supplied or created information in the first place; and/or
• A user is entitled to use a particular pseudonym.

These anonymous credentials have limited application and are to be implemented on a case- by-case basis. Some people may have anonymous and identity credentials. As general matter, anonymous credentials are appropriate for Levels 1 and 2 only.

The technical guidance on how to implement OMB M-04-04, i.e. NIST 800-63-1, states:

The name specified in a credential may either be a verified name or an unverified name. If the RA has determined that the name is officially associated with a real person and the Subscriber is the person who is entitled to use that identity, the name is considered a verified name. If the RA has not verified the Subscriber’s name, or the name is known to differ from the official name, the name is considered a pseudonym. […]

• At Level 1, identity proofing is not required so names in credentials and assertions are assumed to be pseudonyms.
• At Level 2, identity proofing is required, but the credential may assert the verified name or a pseudonym.
• In most cases, only verified names may be specified in credentials and assertions at Levels 3 and 4.
• The required use of a verified name at higher levels of assurance is derived from OMB M-04-04 and is specific to Federal IT systems, rather than a general e-authentication requirement.

NIST SP 800-63-1 defines a Credential Service Provider (CSP) as a trusted entity that issues or registers Subscriber tokens and issues electronic credentials to Subscribers. Within the context of the model, the most important role the CSP fulfills is that of the Credential Manager. But depending on capabilities, competencies and specialization, the CSP typically also fulfills the Token Manager and/or the Attribute Manager role(s):

In both cases, policy determines how the CSP fulfills the Credential Manager role, and in the case of interacting with US Federal Government IT Systems, OMB policy drives the usage of pseudonyms and verified names.

RELATED INFO

• A Model for Separating Token and Attribute Manager Functions
• Can NIST E-Authentication Guideline SP 800-63-1 Support a Token-Attribute Separation Model?
• OMB E-Authentication Guidance for Federal Agencies (OMB-M-O4-O4) [PDF]
• NIST Electronic Authentication Guideline (NIST SP-800-63-1) [PDF]
• Credential Manager in the Token and Attribute Manager Separation Model