Who are you? From Directories and Identity Silos to Ubiquitous User-Centric Identity

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

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

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

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

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

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

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

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

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

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

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

12. 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 What is a Digital Identity?

13. The Laws of IdentityEstablished through Industry Dialog • User control and consent • Minimal disclosure for a defined use • Justifiable parties • Directional identity • Pluralism of operators and technologies • Human integration • Consistent experience across contexts Join the discussion atwww.identityblog.com

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

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

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

17. SELF - ISSUED MANAGED 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

18. CardSpace Experience

19. 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, email, telephone, age, gender • No high value information • Effective replacement for username/password

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

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

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

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

24. 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 2006 • http://www.microsoft.com/interop/osp/

25. For More Information • http://cardspace.netfx3.com/ • http://www.bandit-project.org/ • Mike Jones – mbj@microsoft.com • Dale Olds – dolds@novell.com

26. (Backup Slides)

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