Design Choices Underlying the Identity Metasystem Proposal

Kim Cameron and Mike Jones

Microsoft

The Goal

• A ubiquitous, user-centric identity solution for the Internet

• that moves identity beyond incompatible identity technology silos

• and results in a safer, more trustworthy Internet.

What is a digital identity?

• A set of claims someone makes about me

• Many identities for many uses

• Required for transactions in real world and online

• Useful to distinguish from profiles

Metasystem Players

Relying PartiesRelying PartiesRequire identitiesRequire identities

SubjectsSubjectsIndividuals and other Individuals and other entities about whom entities about whom

claims are madeclaims are made

Identity Identity ProvidersProviders

Issue identitiesIssue identities

Demo: User Experience

Preconditions to Ubiquity– Secure design and implementation

• Resist accelerating attacks such as phishing and pharming

– Integrate existing technologies and incorporate emerging ones

– Accommodate breadth of use cases, including those with contradictory requirements, for example:

• When browsing web, don’t disclose sites visited to identity providers

• In some governmental and financial settings, audit record of sites visited using an identity may be required

– Incremental and parallel deployment• Must co-exist with and complement existing solutions• No “forklift upgrades” required

What is Success?

– Metrics• Ubiquity• Security-enhancing design and implementations• Single, simple user experience across systems• Simplicity of the programming model

– How to achieve success?• Broad collaborations• Encapsulation and transformation• Applying technology standards• Ensuring that all participants benefit

Need Four Kinds of Risk Analysis

• Business analysis– What will get identity providers,relying parties, and

end users to buy in?• Security threat analysis

– What kinds of attacks can be staged and how can they be mitigated?

• Privacy threat analysis– How can privacy be compromised through identity

and how can we make sure that doesn’t happen?• Performance analysis

– Make sure it works at scale for both identity providers and relying parties

“Identity 1.0” (old)Enterprise-Centric Model

• Identity Provider intermediates between user and Relying Party

• IP offers a service that can be consumed directly by RP

• IP has panoptical view of RPs serving a user• Back channels in use• Identity of RP exposed to IP when releasing

attributes• RP dependent on IP for access to user

“Identity 2.0” (new)User-Centric Model

• User intermediates between identity provider and relying party

• User decides when to release identity information to RP

• No requirement that IP knows anything about RPs serving a user (including their network addresses)

• No reliance on back channels• Relying Party is NOT dependent on identity

provider for access to user

Incremental Addition of InfoCard

User

Web FarmHTTPServer

HTTPServer

HTTPServer

HTTPServer

FormsBasedLogin

InfoCardLogin

Authentication

CookieCookie

Authentication

Cookie

Specific Design Choices

Protocol ≠ Payload

• Switch payloads without changing protocols• Single protocol set allowing:

– Specification of requirements– Negotiation of capabilities– Transformation of payload– Transmission of payload

• Protocol stays stable as payload evolves• Design decision: Do not tie solution to protocol

designed around a single payload type

Identity Selector ≠ Identity Provider

• Identity Selector independent of any specific Identity Provider (technology or operator)

• Plug in multiple providers and technologies to make open architecture that can embrace both existing systems and those yet to be invented

• Allow Identity Provider to live anywhere – e.g. “in the cloud”, at ISP, on a device (dongle, media player, or cell phone), on a PC, …

• Design decision: Identity Selector does not run in same process as IP. Local IP just one IP amongst many

Identity Selector ≠ Metadata Store

• User interface separate from InfoCard metadata pointing to Identity Providers

• UI wherever you want it: on telephone or media player or PC using same metadata store

• Metadata stored wherever you want: on PC or telephone or IPod or dongle or in the cloud (including physical tokens supporting roaming)

• Design decision: Metadata store does not run in identity selector process

Auditing ≠ Non-auditing IPs

• Auditing IPs know which RPs you have visited

• Non-auditing IPs do not know which RPs you have visited

• Need to support both requirements

• Design Decision: Support ability to either reveal or provide a one-way function of the identity of the RP to IP

Guarantee Separation of Contexts

• Unidirectional identifiers:– Identifiers given to one RP ≠ identifiers given

to another– Automatically generate pairwise identifiers – No URL or GUID to serve as a correlation

handle

• Set of claims released varies on a per RP basis

Facilitate “Data Rejection”

• Currently sites retain a dossier of information about you: “Customer Record”

• With metasystem, users supply sites information about them at every sign-on

• Result: Sites can throw away information about you between interactions– Since you’ll give it to them when they need it

Claims ≠ “Trust”

• Factor out the trust decisions– Avoid building them into the protocol and

payload• as is the case with X.509 PKIX, for example

– Verify cryptography but leave trust analysis for a higher layer that runs on top of the identity metasystem

Human Token ≠ Computational Token

• Identity Selector must be able to display claims so user can control them

• It must be easy to introduce new payloads and display them without introducing new attack vectors (new code!) on the Identity Selector

• Allow complex claims• Design decision: Cryptographically bind display

token and computation claims to allow audit of IP by user or RP auditor

Authentication Goes Both Ways

• Identity systems typically used to prove identity of user to the Relying Party

• Phraud possible because identity of the Relying Parties not proven to users

• Design Decision: Prove identity of sites to users before users ever interact with sites

Protection of Human Communication

• Based on narrowband state engine– Suppression of complexity (noise)

• Familiar, predictable interactions• An InfoCard is an InfoCard in spite of underlying technology

or operator

– Use familiarity to protect against social engineering• You recognize your own wallet

• Isolation from Pharmland– Separate desktop to prevent interprocess snooping

• Localization of secrets– Visual representations, keys, ledger

Decisions, Decisions!

• Decisions intended to result in:– Widely accepted– Broadly applicable– Inclusive– Compensable– Privacy enhancing– Security enhancing– Identity Solution

Let’s talk about it!

Demo: The Real Thing!