Design Choices Underlying the Identity Metasystem Proposal

1. Design Choices Underlying the Identity Metasystem Proposal Kim Cameron and Mike Jones Microsoft

2. 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.

3. 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 What is a digital identity?

4. Metasystem Players Identity Providers Issue identities Relying Parties Require identities Subjects Individuals and other entities about whom claims are made

5. Demo: User Experience

6. 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

7. 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

8. 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

9. “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

10. “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

11. InfoCard Login Forms Based Login Incremental Addition of InfoCard HTTP Server HTTP Server HTTP Server HTTP Server Web Farm Cookie Cookie Cookie New! Authentication User Authentication

12. Specific Design Choices

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. Decisions, Decisions! • Decisions intended to result in: • Widely accepted • Broadly applicable • Inclusive • Compensable • Privacy enhancing • Security enhancing • Identity Solution Let’s talk about it!

24. Demo: The Real Thing!