Cisco Blogs

Credential and Attribute Providers in the NSTIC

- May 6, 2011 - 3 Comments

This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.

The National Strategy for Trusted Identities in Cyberspace (NSTIC) describes two types of intermediaries between subjects (users) and relying parties: identity providers and attribute providers. This is a separation not frequently found in identity systems. In order to emphasize this distinction, I often use the term “credential provider” or “authentication provider” rather than identity provider to refer to a service that provides authentication services and makes assertions resulting from authentication but does not directly provide attributes about the subject.

A credential provider can be thought of as a key cabinet. The subject authenticates to the credential provider in order to “unlock” the cabinet of credentials. As with a physical key cabinet where different keys inside are used for different things, the credential provider serves different credentials to different services. Ideally, the identifiers used for each of these services would be different; a good identifier is also opaque, meaning that the identifier itself provides no additional information about the subject. Provided that the choice of credential provider itself does not reveal significant information about the subject, a subject can be generally pseudonymous with respect to the relying party until the subject authorizes the release of identifying attributes.

Attribute providers are sources of information about a subject (user). In many cases, an attribute provider would be the source of some trustable or authoritative information about the user. This trust or authority may be very domain-specific: a credit bureau might be authoritative as to the credit worthiness of a subject, but one would look to a healthcare provider to determine the subject’s blood type. The methods of obtaining this trust are themselves complex, and worthy of a separate discussion.

There are benefits to being able to separate the roles of credential provider and attribute provider. This allows a single user to have multiple attribute providers, probably organized (and accredited) for specific types of information. In other words, a relying party could depend on an assertion from a credit bureau to determine credit worthiness, and on an employer’s assertion of employment status.

The separation between these roles could also broaden the choices the user has for credential provider(s). Having a lot of choices is good, and reducing the amount a relying party has to trust the credential provider helps accomplish that. Having an arm’s-length relationship between credential and attribute providers may also benefit user privacy. On the other hand, the separation of credential and attribute providers is a functional distinction; there is nothing to prevent a given entity from operating both a credential provider and a provider for some attributes. Users may find this arrangement convenient since they can enroll with a single provider for both services.

NSTIC provides considerable flexibility on how users organize their own “identity portfolio.” This wide range of choices for both credential and attribute providers allows users to create a portfolio that meets their needs best.


All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. There are a basic set of attributes that come from the identity provider even if it is only an identifier. This depends on the policy and assurance levels of the issuer. One of the issues (no pun intended) is the fact that you have a separation of identity from attribute, it requires additional steps in the use of identity in the workflow in cyberspace. It's the life cycle management of these that are different more than where you get identity or credential. Identity is long lived, credentials more dynamic separate them at use and where they come from will sort itself out...

    • Salvatore, thanks for your thoughts. You're correct that higher assurance levels do require identity proofing that associates some attributes with the credential provider itself. That can be problematic in trying to satisfy some of the anonymity and pseudonymity requirements of the NSTIC. As I said in the article, I would like to see a cleaner separation between credential and attribute provider roles, and that will probably require some rethinking of identity proofing requirements. I plan on discussing this further in another blog post in the near future.

  2. Jim, It depends on the level of relationship. Anonymity for many net transactions (browsing) may make sense, but not all. So anonymity could be default as a privacy maximizing approach. I think there are a separation at the identity (registration), credential, access and management levels (most of the privilege attributes are associate with the later) as laid out in ICAM. Also heard Andre Boysen of SecureKey at the Smart Card Alliance Annual Meeting last week liken this to relationships and that anonymity works for a one night stand but longer term relationships require more. I think the human relations analog is a useful one for NSTIC. I used the analogy in talking about trust and interoperability at the event as well. Sal