The Identity Quartet

A functional model for best practice Identity implementations.

The Identity Quartet is a framework for online services that allows users to express their Identity on their own terms. When I use the term “Identity”, I refer to the set of identifiers used in reference to users in online services.

At the December 2008 Internet Identity Workshop, Randy Farmer introduced what he called the “Tripartite Model of Identity.” He presented a pattern distilled from years of groundbreaking work building virtual communities.  This article is a write up of a four component model based on Randy’s initial concept. I also build on the ideas discussed at the IIW session on Non-correlatable IDs with OpenID.

The Quartet

In online systems, we use Identity in four roles, using four potentially distinct identifiers. Each of those four will be present in any system that allows users to login, present themselves online, and receive incoming services. Often, systems use the same identifier to fulfill multiple roles. However, there are good reasons that these identifiers should be managed separately, especially across organizational boundaries.

The  four identifiers are:

1. Authentication IDs
2. Presentation IDs
3. Reference IDs
4. Internal IDs

Authentication IDs

To access privileged services, users must present an identifier to claim their right to that service. Common identifiers include session IDs, cryptographic tokens, and usernames. Usernames are probably the most common identifier for logging into services. Paired with a password for authentication, this is a cornerstone of how we use identity to gain access to privileged services. That access authorization typically persists without logging in again through the use of a session ID. In a user-centric context we can separate the authentication ID used at a Relying Party with that used at the Identity Provider, allowing for directed identity as described by Kim Cameron in his Seven Laws of Identity.  In a capability-based authentication regime, the identifier itself could contain a cryptographically signed delegation of authority for a particular privilege, but, in general authentication IDs don’t need to be that fancy.

Presentation IDs

Handles, nicknames, and character names are used to label content for display to others in the system. Often these presentation identifiers are humorous or obviously fictional, such as “HappyCamper” in an online chat or “Thor the Destroyer” in World of Warcraft. They need not relate to actual user characteristics, nor do they need to be unique. Their only role is to present a label as the author, owner, or embodiment of a post, comment, rating, or character. Just as there are multiple “John Smiths” in the New York white pages, there’s no reason there can’t be multiple accounts with the same presentation ID in an online community, as evidenced by the vast number of users with the handle “Jesus Jesus Jesus” on Facebook. In reciprocal multiplicity, online games like World of Warcraft often allow each user to create and simultaneously maintain multiple characters, with different names, avatars, descriptions, characteristics and property.

Since presentation IDs are intended to be shown to a wider audience and because their uniqueness is not technically required, it is prudent to separate presentation identifiers from authentication. There is no need to advertise authentication identifiers widely, as that simply increases security risk by giving away a critical—and preferably secret—component required for accessing privileged services.

Reference IDs

Service requests need a way to refer to intended parties. The most prevalent reference identifier is the local-part in an email address, the part before the @ sign, e.g., “joe” in “joe@example.com”.  This identifier allows users to contact one another, without referring to anything else (such as a blog post or a job listing). It should be unique for each intended incoming role (e.g., admin@example.com or joe@example.com), but there is no technical reason that any given user can’t have more than one reference identifier, as is commonly seen when multiple email addresses auto-forward to the same individual. Also, often for a given role, it makes sense for a reference identifier to forward messages to several individuals, e.g., admin@example.com could forward the email to three different users to improve the response time for handling the issue.

Since this reference ID is intended to be used by users other than the recipient (that should be obvious!), it makes sense to distinguish it from authentication IDs used to access the system. Distinguishing the reference ID from the presentation ID allows users to receive directed incoming services (such as email) while displaying handles that are common to multiple users. Combined with an appropriate service endpoint, reference IDs allow for any number of incoming services to be provided in reference to that ID.

Internal IDs

Every system needs to keep track of which identifiers relate to each other and to specific privileges. For example, what email messages should be shown to the user with a particular authentication ID?  And which users should be able to post to a bulletin board? Internal IDs link together the authentication, presentation, and reference identifiers in the system, allowing users who are logged in to a system to see the appropriate service interfaces and have particular services performed as directed, including the proper presentation of their Identity to fellow users. The internal identifier is typically the primary key in a database table managing the list of users, and may also be used in a permissions table to keep track of service privileges. Because it is an internal identifier, it need never be revealed to the outside world and, to minimize hacking, it shouldn’t be. Because it is completely internal, it can also enable anonymous access to services through appropriate anonymized mechanisms for authentication IDs.

Separation of identifiers improves Identity

Many systems use the same identifier for multiple roles, such as using your email address as your login username for a system, such as AOL once required (and might still). However, systems can be more robust, more flexible, and more secure if they explicitly delineate the four identifiers to help avoid unintended correlation and attack vectors. This is especially true across trust boundaries. Using your AOL login as the AOL email service endpoint simplifies the mental model for users new to online services at some minor cost to security by exposing the login id to everyone a user gives their email address to. Using your AOL username as a login to other services is asking for both a loss of privacy from cross-site correlation of your identity and attacks on your account login.

Fortunately, the latest technology can avoid this—if we use it correctly.

It isn’t just enough to enable OpenID, SAML, or Information Cards on our systems. For truly user-driven Identity we need to explicitly delineate the identifiers used for authentication, presentation, and reference from each other and internal identifiers, both within and between organizations. We should also enable users to choose their own identifiers for the first three… and keep the internal identifier completely secret.

Examples

There’s no reason users can’t select their own authentication ID in each of the above situations, although in practice, the RP-specific token is usually dynamically generated on behalf of users. Similarly, Presentation IDs can easily be specified by users in either system, leveraging OpenID’s Attribute Exchange Extension when appropriate. The reference IDs can also be user defined in either of the above approaches, with OpenID allowing fourth parties to discover a user’s service endpoint and endpoint-specific reference ID  for any service authorized by the user for that party. And clearly, the internal identifiers in all three situations have no innate need to be correlated with any of the others except through the secret internal ID. This allows for the maximum possible user choice and, potentially, maximum anonymity.

The Identity Quartet pattern isn’t rocket science. In fact, it makes things simpler when it comes to security, maintenance, and user control. The Quartet makes systems more flexible and more secure while giving users more freedom to manage how they interact and present themselves online. It is one way to turn user-centric Identity services of OpenID and Information Cards into truly user-driven Identity.

[Update: 4/17/2009 Revised “routing ID” to “reference ID”.]