Internet-Scale Identity

What follows is an excerpt from our recently published paper on Internet-Scale Identity Systems.

An Internet-scale identity system is an architecture that defines standardized mechanisms enabling the identity attributes of its users to be shared between applications and Web sites. This enables a streamlined and optimized online experience for users, greater protection from identity theft and opportunities for customization and personalization that do not require the user to manually configure account information. There are a number of different technologies and standards initiatives designed to deliver an Internet-scale identity system including SAML, Windows CardSpace, OpenID and ID-WSF. This white paper provides an overview of the key initiatives and explores the similarities, differences, and synergies between them.

Identity Type

Identity systems typically focus on the exchange of certain types of identity attributes – either unique user identifiers or more general attributes (such as email address, tele­phone number, user profile information, etc.).

While the communication of an identifier on its own can enable Single Sign-On, richer use cases generally require additional information.

Identifiers

The nature of the identifiers used by RP/SPs to identify users is a key differentiator of identity systems. Most significantly, the nature of the identifier impacts the privacy characteristics of the systems with respect to guarding against inappropriate correlation of user actions at different RP/SPs.

Identifiers used by Identity Systems fall into three general categories:

Global Identifier– all RP/SPs use the same identifier to refer to a given user. While attractively simple, the global model makes collusion trivial between RP/SPs.

Pair-wise Pseudonyms – pairs of providers establish and subsequently use unique identifiers for users. This model inhibits collusion between RP/SPs as they share no common identifier for a user; however, correlation based on other identity character­istics (e.g. phone number) is possible.

One-time Identifier – each time a user accesses an RP/SP they have a different identifier; consequently preventing that RP/SP from correlating their actions across subsequent visits. In such a model, because identifying the user accessing an account at the RP/SP is necessarily impossible, the RP/SP generally customizes service based on other identity attributes of the user (e.g. role in an enterprise scenario, frequent flyer status for a B2C scenario, etc).

SAML supports all of the above identifier types and defines a number of mechanisms tailored to support pseudonyms.

OpenID 1.1 primarily relies on global URIs and inherits the attendant privacy risks. Advocates claim the risk is mitigated by a user’s ability to present different OpenIDs to different RP/SPs as necessary. While true, the implication is that the user bears the burden of remembering and managing multiple URI personas.

ID-WSF and CardSpace primarily rely on pseudonymous identifiers.

Authentication

Single Sign-On enables a user to authenticate to an IDP and then have their digital identity asserted by the IDP to RP/SPs – thereby enabling user access to resources at that RP/SP. For some identity systems, the act of authentication by which the user presents some credentials (e.g. password, OTP, X.509 certificate, IP address, etc.) to the IDP is deemed out of scope – the focus is instead on the protocols and syntax by which this act can be communicated to RP/SPs to enable SSO. Both SAML and OpenID take this approach, neither defines mechanisms by which a user authenticates to the IDP, but rather mechanisms to allow the RP/SP to request that the IDP authenticate the user, and mechanisms to allow the IDP to respond that the user has been authenticated. SAML’s Authentication Context allows the IDP to describe how the authentication occurred (e.g. Biometric or SIM card) but not how to perform it, OpenID is currently exploring comparable functionality.

Alternatively, both CardSpace and ID-WSF define mechanisms by which a user (using a client with capabilities beyond a default browser) can authenticate to an IDP in order to enable subsequent SSO and other identity transactions. Perhaps CardSpace’s most notable functionality is a model where there is no IDP per se. The user authenticates to RP/SPs simply by presenting a previously established identifier and demonstrating possession of a secret cryptographic key to enable protection from the many issues surrounding passwords (i.e. phishing)

Identity Flow

Identity systems can be characterized by the channel through which identity information flows from the IDP to the RP/SP. Fundamentally, there are two high level choices:

·         Front Channel – Identity information flows through the user-agent from IDP to RP/SP and thereby makes possible direct user mediation

·         Back Channel – Identity information flows direct from IDP to RP/SP

In principle, the front-channel promises improved privacy through the stronger control point enabled by realtime user consent for attribute exchange. Against this must be bal­anced the reality of insecure clients and the inability of this model to support use cases where the user is offline and not present to actively mediate the identity flow.

Message size limitations of the front-channel method can be addressed through either HTML Form mechanisms or through smart clients capable of more advanced messaging.

Another aspect of identity flow is the point from which identity interactions are initiated. Most typical is a pattern that begins when the RP/SP, in trying to determine access rights or personalization, sends a request to the IDP for the desired identity. A very different set of use cases requires the flow of identity to be initiated from the IDP, and not as a result of a request from the RP/SP. This flow pattern is necessary for portal use cases in which the user, after authenticating to the IDP, can be presented with a list of available RP/SPs with which they have the option of an identity transaction (e.g. a user has seamless access to a partner Web site from a travel portal). The assumption that a particular list of available RP/SPs is presented has implications for the trust model as it requires the IDP to assert identity assertions for the user to only RP/SPs on the list.

Trust Model

A useful definition of “trust” for the purpose of this white paper is: A reasonable expectation of confidence in an actor’s behavior.

In the context of identity interactions between IDPs and RP/SPs, for one to trust the other means that the first has a reasonable level of confidence that the second will behave in a certain manner in a given context. This may include agreement upon security infrastruc­ture, privacy policies, etc.

Depending on the application, “reasonable” can mean very different things. For low-val­ue and no-risk applications like blog commenting, an RP/SP might establish reasonable confidence in an IDP based solely on the fact that the IDP is able to correctly follow the OpenID SSO protocol. Consequently, such an RP/SP may choose to be indiscriminate in choosing its IDP partners – if there is little or no risk in choosing a bad (malicious, hacked, etc) IDP, the RP/SP is motivated to accept any IDP. Likewise, an IDP assumes no risk by asserting identity to an arbitrary RP/SP because the value or sensitivity of the application creates no great risk to be distributed.

For more sensitive applications (e.g. SSO from a bank IDP to a stock analysis RP/SP), the RP/SP must have a more stringent criteria for determining with which IDPs to engage in identity interactions. If the risk of accepting an assertion from an RP/SP is non-trivial, the RP/SP will manage this risk by being more careful in selecting identity partners. Likewise, an IDP may choose to assert identity to only a certain set of RP/SPs in order to protect itself against risk. Importantly, if IDPs and RP/SPs are anything but completely indiscriminate in their choice of partners, security mechanisms are required to determine whether any particular provider meets selected criteria.

Any of the identity systems discussed in this white paper could support a range of trust models; however, each has been designed or optimized for a particular subset of use cases. OpenID defines a relatively low level of security requirements and is appropriate to low-sensitivity applications. Combined with this is OpenID’s association mechanism for authenticating protocol messages. An RP/SP and IDP, even with no prior relationship, can use Diffie-Helman cryptographic techniques to establish a shared secret key for authenticating subsequent protocol messages. Such a dynamic mechanism is appropriate for OpenID’s default assumption of indiscriminate providers.

SAML and CardSpace define a more robust security model necessary for high-sensitivity use cases. Consequently, SAML and CardSpace are more likely to rely on less dynamic cryptographic mechanisms such as X.509 certificates.

Recently the OpenID community has explored layering security in order to support higher sensitivity use cases, and the SAML community is defining profiles that diminish the security settings from those defined in the core SAML 2.0 specifications.

Discovery

Discovery mechanisms are functions by which – for a given combination of desired user identity, RP/SP identity, and policy requirements – appropriate IDPs can be identified as candidate providers. Discovery is necessary in any architecture in which there are multiple IDPs, or for which the location of IDPs is potentially dynamic. In situations where there is only ever a single identity provider (e.g. an enterprise) there is no need for a discovery operation because any RP/SPs will implicitly know where to obtain the user’s identity attributes.

Discovery is similar to a Web search for an identity. The inputs to the engine are the user in question and the type of identity being sought by the RP/SP. The output is a list of IDPs that meet the criteria.

Discovery can be preceded by a registration step. A step by which IDPs register them­selves as providing a particular identity service for a given user. Such a registry could be located on the client or on a network endpoint.