Identity and Attribute Providers

One of the more unconventional but important aspects of the National Strategy for Trusted Identities in Cyberspace (NSTIC) is its model of attribute providers (APs) as distinct from identity providers (IdPs). However, this concept does not seem to be fully embraced by many who are active in the Identity Ecosystem Steering Group (IDESG), the organization that is working to turn the NSTIC vision into a reality.

Identity providers in current identity management systems, primarily those that are enterprise-focused or based on “social identity” like Facebook, act as attribute providers as well. In an enterprise, you would typically pass your login credentials (typically username and password) to an application that would in turn use a protocol like LDAP or Active Directory to verify the credentials with an identity provider. If the credentials are valid, the identity provider returns attributes about you, e.g., name, employee ID, department ID, and job title, to the enterprise application which uses the attributes to decide what you’re authorized to do.

Social login operates somewhat differently because the application isn’t necessarily trusted to receive your credentials. So Facebook Login collects your username and password directly, and uses the OAuth protocol to return your attributes, including name, time zone, friends list, and any links you have shared, to the application requesting the login. As in the enterprise login case, the attribute provider and the identity provider are one and the same.

In the broader context of NSTIC, there are several reasons why identity providers and attribute providers can’t be one and the same:

• Different attribute providers are authoritative for different attribute classes – In an enterprise, the enterprise itself is authoritative for nearly all attributes of interest. But in the broader NSTIC use case, there isn’t a common point that all parties trust. Users typically will have different providers for different types of attributes: proof that you’re a full-time student might come from your school district or university, an assertion that you’re an adult might come from your motor vehicle department, and your credit-worthiness might come from one of the major credit bureaus. Requiring these all to be asserted by the identity provider requires it to be trusted by basically everyone, and that’s hard to achieve.
• Users need to be able to choose their identity provider – In the course of processing transactions for you, your identity provider will be exposed to a great deal of information about where you use your identity. For that reason, the principle of IdP choice described in the NSTIC strategy document is very important. In order to make that choice meaningful, we have to minimize the trust in the IdP required by others such as relying parties. Except for self-asserted attributes where there is no trust required, attribute assertions by IdP require relying parties to consider the IdP to be authoritative for those attributes, which severely constrains the possible range of IdPs that users can choose from, making it more difficult for users to find an IdP that they can trust with this intimate information.
• Support for anonymous and pseudonymous interactions is required – NSTIC recognizes the need to support anonymous and pseudonymous interactions in order to facilitate important uses that might not occur otherwise. If user attributes accompany every use of an online identity, these types of interactions are not possible. An IdP can simply assert an identifier, which should be opaque (not divulging any other information about the user). In many cases, identifiers may also be directed (different for each place you use your identity, so that your activities aren’t as easily correlated) and sometimes ephemeral (different for each session). Depending on the specific use, some attributes might be provided with the consent of the user, such as an assertion that the user is of legal age, without identifying the specific user.
• Attribute providers must be insulated from sensitive information – When you use your driver’s license to prove that you’re of legal age, the issuer of that license doesn’t generally get information about where that ID has been checked. Given the sensitivity of some online transactions, the same characteristic is desirable: in most cases, the authoritative source for an attribute isn’t entitled to know how and where it is used. For this reason, it may be preferable to route attribute queries through the IdP to insulate the relying party from attribute providers. This characteristic isn’t called out explicitly in the NSTIC, but is a privacy enhancing technology that might be employed to prevent attribute providers from tracking users’ use of their online identities. This, in turn, motivates an arms-length relationship between users’ IdPs and attribute providers.

While some IdPs may also operate attribute providers (particularly for self-asserted attributes, which like the IdP are on behalf of the user), it’s cleaner to think of the IdP and AP as separate functions that may incidentally be operated by the same entity, subject to the arms-length concern mentioned above. More generally, an attribute provider is somewhat like a relying party, in that it receives a trustable assertion of an identifier from the user’s IdP representing that user. IdPs, since they represent the user, may also serve as directories of APs where attributes for a given user can be found. This may also limit the leakage of information about the user that comes from their choice of attribute providers. The use of a particular state DMV as an attribute provider correlates strongly with residence in that state, while the assertion provided might actually be signed on behalf of a broader authority such as AAMVA.

An area where the combined IdP/AP model seems to dominate thinking is identity proofing, which is the binding of an online identity with trusted real-world attributes, such as the user’s legal name. In the combined model, one needs to go through a process, either in person or through association with an existing relationship such as a bank account, prior to the issuance of a credential. This is important because the credentials in these cases often incorporate those identifying attributes, as a driver’s license or government PIV card has your name printed on it and incorporated into a magnetic stripe and/or chip. But when attribute providers are separate, they need an assertion from the user’s IdP to bind the attributes they are verifying to that digital identity, so the credential needs to be issued first. Identity proofing is a function of the attribute provider, not the identity provider, in this model.

The combined IdP/AP thinking also affects how one views a credential. We use the word “credential” extensively in the offline world, to describe a variety of documents and situations ranging from the presentation of a birth certificate to get a passport to the use of that passport to travel internationally. In the NSTIC authentication model, the user presents their credential to his or her IdP. It need not contain any attribute information, because the IdP does not need it. This differs from the combined model, where the relying party obtains information, such as the user’s name or employer, directly from a credential like a government PIV card. But in the NSTIC model, the choice of credential is up to the user and IdP, subject to the requirement that it be sufficiently secure to satisfy the relying party.

Illustration is taken from “Identity Systems”, a presentation I gave in late 2009. The entire presentation is available on Slideshare.