Open Identity Metasystem Architecture

Roles

Different parties participate in the metasystem in different ways. The following roles within the metasystem are:

• Identity Providers issue identities. For example, credit-card providers might issue identities that enable payment, businesses might issue identities to their customers, governments might issue identities to citizens, and individuals might use self-issued identities in contexts like signing on to Web sites.

• Relying Parties require identities. For example, a Web site or online service that uses identities offered by other parties.

• Subjects are the individuals and other entities about who claims are made. Examples include end users, companies, and organizations.

Each person and entity that participates in an identity metasystem can play all the roles, and each person and entity can play more than one role at a time. Often a person or entity plays all three roles simultaneously.

Components

This section describes the key components and concepts of the metasystem.

The metasystem is made up of five key components:

1. A way to represent identities using claims.

2. A means for identity providers, relying parties, and subjects to negotiate.

3. An encapsulating protocol to obtain claims and requirements.

4. A means to bridge technology and organizational boundaries using claims transformation.

5. A consistent user experience across multiple contexts, technologies, and operators.

Claims-Based Identities

Identities consist of sets of claims that are asserted about the subject of the identity. For example, the claims on a driver's license might include the issuing state, the driver's license number, a name, address, gender, birth date, the kinds of vehicles the licensee is eligible to drive, and so on. The issuing state asserts that these claims are valid.

The claims on a credit card might include the card issuer's identity, the card-holder's name, the account number, the expiration date, the validation code, and the card-holder's signature. The card issuer asserts that these claims are valid.

The claims on a self-issued identity (such as a business card) might include your name, address, and telephone number. For self-issued identities, you assert that these claims are valid yourself.

Negotiation

Negotiation enables participants in the metasystem to make agreements required for them to connect with one another within the metasystem. Negotiation is used to determine mutually acceptable technologies, claims, and requirements. For instance, if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties negotiate and decide to use X.509 claims with one another. Another type of negotiation determines whether the claims required by a relying party can be supplied by a particular identity. Both kinds of negotiation are simple matching exercises; they compare what one party can provide with what the other one requires to determine whether there is a fit.

Encapsulating Protocol

The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties. The participants determine the content and meaning of what is exchanged, not the metasystem. For example, the encapsulating protocol would allow an application to retrieve SAML-encoded claims without having to understand or implement the SAML protocol.

Claims Transformers

Claims transformers bridge organizational and technical boundaries by translating claims understood in one system into claims understood and trusted by another system, thereby insulating the mass of clients and servers from the intricacies of claim evaluation. Claims transformers may also transform or refine the semantics of claims. For example, a claim asserting, "Is an employee" might be transformed into the new claim, "OK to purchase book." The claim "Born on March 22, 1960" could be transformed into the claim "Age is over 21 years," which intentionally supplies less information. Claims transformers may also be used to change claim formats. For instance, claims made in formats such as X.509, Kerberos, SAML 1.0, SAML 2.0, SXIP, and others could be transformed into claims expressed using different technologies. Claims transformers provide the interoperability needed today, plus the flexibility required to incorporate new technologies.

Consistent User Experience

Many identity attacks succeed because the user was fooled by something presented on the screen, not because of insecure communication technologies. For example, phishing attacks occur not in the secured channel between Web servers and browsers—a channel that might extend thousands of miles—but in the two or three feet between the browser and the human who uses it. The identity metasystem, therefore, seeks to empower users to make informed and reasonable identity decisions by enabling the development of a consistent, comprehensible, and integrated user interface for making those choices.

One key to securing the whole system is to present an easy-to-learn, predictable user interface that looks and works the same no matter which underlying identity technologies are employed. Another key is making important information obvious—for instance, displaying the identity of the site you are authenticating to in a way that makes spoofing attempts apparent. The user must be informed which items of personal information relying parties are requesting, and for what purposes. This allows users to make informed choices about whether or not to disclose this information. Finally, the user interface provides a means for the user to actively consent to the disclosure, if they agree to the conditions.