Who are you? From Directories and Identity Silos to Ubiquitous User-Centric Identity Mike Jones, Microsoft and Dale Olds, Novell

Who are you? Question central to enabling you to do things you're entitled to do, preventing you from doing things you’re not. True in both physical world, online world.

Who are you (online)? Past, present, and future: From directories, to identity silos, to ubiquitous, interoperable, user-centric digital identity.

The Bad Old Days Username/password per application But that’s preposterous and inconvenient!

The Bad Old Present Username/password per web site But that’s preposterous and inconvenient!

Enter Directory Services Identity attributes for users in a central repository Allows multiple applications within a domain to share identities Attributes can be retrieved by applications Examples: LDAP implementations Novell eDirectory Microsoft Active Directory

Directory Services Advantages Applications within the domain can use the same identity attributes Allows enterprise single-sign-on within participating applications Some directory interoperation via LDAP, virtual directories, meta-directories And, recently shown at Monday's keynote, federation

Directory Services Disadvantages Several incompatible protocols – silos Applications know which directory they use Identities only valid usable a single domain Disjoint and overlapping domains are inevitable as organizations evolve

Directory Services, Meta and Virtual Directories Very useful systems which solve some of silo problems of overlapping identity domains Accessed as a central repository of identity data by many other services Services and revisions of services accumulate over time Control of repository schema and updates becomes political The central repository tends to become an immovable political mass

Identity Silos In the Web and within the enterprise, disjoint identity domains are common Username/password per site X.509, Kerberos, SAML have not helped Each with its own protocol Each operates only within its own silo

Enter Federation Enables use of identities at other sites Advantages Extends login identities to other trust domains Standards-based interoperation Disadvantages Requires establishing explicit trust relationships No user choice of which identity to employ relative to each domain Examples SAML based federation WS-Federation based federation OpenID

What is a Digital Identity? Set of claims one subject makes about another Many identities for many uses Required for transactions in real world and online Model on which all modern access technology is based

The Laws of Identity Established through Industry Dialog 1. User control and consent 2. Minimal disclosure for a defined use 3. Justifiable parties 4. Directional identity 5. Pluralism of operators and technologies 6. Human integration 7. Consistent experience across contexts Join the discussion at

Identity Metasystem We need a unifying “Identity Metasystem” Protect applications from identity complexities Allow digital identity to be loosely coupled: multiple operators, technologies, and implementations Not first time we’ve seen this in computing Emergence of TCP/IP unified Ethernet, Token Ring, Frame Relay, X.25, even the not-yet- invented wireless protocols

Enter User-Centric Identity Enables people to choose which of their identities to use at which sites Analogously to how they choose which card to pull out of their wallet in different circumstances Used through Information Card metaphor Visual cards represent different identities Benefits People in control of their identity interactions Easy to use – no passwords to remember! Strong crypto – instead of shared secrets Phishing-resistant

Identity Roles Relying Parties Require identities Subjects Individuals and other entities about whom claims are made Identity Providers Issue identities

Contains self-asserted claims about me Stored locally Effective replacement for username/password Eliminates shared secrets Easier than passwords Provided by banks, stores, government, clubs, etc. Cards contain metadata only! Claims stored at Identity Provider and sent only when card submitted Information Cards SELF - ISSUEDMANAGED

CardSpace Experience

Information Card Properties Cards are references to identity providers Cards have: Address of identity provider Names of claims Required credential Not claim values Information Card data not visible to applications Stored in files encrypted under system key User interface runs on separate desktop Self-issued information cards Stores name, address, , telephone, age, gender No high value information Effective replacement for username/password

Open Identity Architecture Microsoft worked with industry to develop protocols that enable an identity metasystem: WS-* Web Services Encapsulating protocol and claims transformation: WS-Trust Negotiation: WS-MetadataExchange and WS- SecurityPolicy Technology specifically designed to satisfy requirements of an Identity Metasystem

Not just a Microsoft thing… Based entirely on open protocols Identity requires cooperation – and you’re seeing it today! Interoperable software being built by Novell, IBM, Sun, Ping, BMC, VeriSign, … For UNIX/Linux, MacOS, mobile devices, … With browser support under way for Firefox, Safari, … Unprecedented things happening Microsoft part of JavaOne opening keynote Microsoft sponsoring BrainShare

LINUX Journal Sep ’05 Cover By Doc Searls Linux Journal Editor Author of the “cluetrain manifesto” Introducing “The Identity Metasystem”

WIRED Magazine - Mar ’06 By Lawrence Lessig Influential Internet & Public Policy Lawyer Special Master in antitrust case against Microsoft Quotation:

Microsoft Open Specification Promise (OSP) Perpetual legal promise that Microsoft will never bring legal action against anyone for using the protocols listed Includes all the protocols underlying CardSpace Issued September

For More Information Mike Jones – Mike Jones – Dale Olds – Dale Olds –

(Backup Slides)

Protocol Drill Down Identity Provider (IP) Relying Party (RP) Client Client wants to access a resource RP provides identity requirements 1 2 User 3 Which IPs can satisfy requirements? User selects an IP 4 5 Request security token 6 Return security token based on RP’s requirements 7 User approves release of token 8 Token released to RP