1. Seven Perspectives on CardSpace Ronny Bjones Security Strategist Microsoft Corporation

2. The Laws of Identity The original research 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 www.identityblog.com

3. Seven Perspectives on CardSpace 1. Component of the identity metasystem 2. Abstraction layer for authentication technologies 3. Anti-phishing technology 4. User convenience 5. Security 6. Privacy 7. Development Framework

4. Perspective #1 CardSpace as a component of the Identity Metasystem The need of an identity layer on the Internet The need of an identity layer on the Internet Interoperability Interoperability Technology & Platform independence Technology & Platform independence

5. The Identity Metasystem Internet Services Partners Customers Identity Metasystem Extending the Reach of Information Workers Extending the Reach of Applications WS-* Web Services Architecture

6. WS-* Based Metasystem Internet Claim Source Enterprise Claim Source App-specific Claim Source Service 3. Obtain claims (WS-Trust) 1. Read policy (WS-MetadataExchange,WS-SecurityPolicy) 2. Select source, consent to disclosure (UX)

7. Framework for Interoperability TCP/IP of Identities Defined on open standards – WS* Extended by CardSpaces definition of CLAIMS http://download.microsoft.com/download/5/4/0/54091e0b- 464c-4961-a934-d47f91b66228/infocard-techref-beta2- published.pdf http://download.microsoft.com/download/5/4/0/54091e0b- 464c-4961-a934-d47f91b66228/infocard-techref-beta2- published.pdf CardSpace is security token agnostic SAML, Kerberos, X.509, custom Identity Providers can bridge different identity silos Multiprotocol Federation Interoperability Demonstration Burton Group – Gerry Gebel - November 1th 2005

8. Protocol Drill Down Identity Provider (IP) Relying Party (RP) Client Client would like to access a resource RP provides identity requirements: format, claims & issuer of security token 1 2 User 3 Client shows which of known IPs can satisfy requirements User selects an IP 4 5 Request to IP Security Token Service for security token providing user credentials 6 IP generates security token based on RPs requirements with display token and proof of possession for user 7 User views display token and approves the release of token 8 Token is released to RP with proof of possession RP reads claims and allows access

9. Protocol Drill Down Identity Provider (IP) Relying Party (RP) Client Client would like to access a resource RP provides identity requirements: format, claims & issuer of security token 1 2 User 3 Client shows which of known IPs can satisfy requirements User selects an IP 4 5 Request to IP Security Token Service for security token providing user credentials 6 IP generates security token based on RPs requirements with display token and proof of possession for user 7 User views display token and approves the release of token 8 Token is released to RP with proof of possession RP reads claims and allows access

11. Contains claims about my identity that I assert Not corroborated Stored locally Signed and encrypted to prevent replay attacks Provided by banks, stores, government, clubs, etc Locally stored cards contain metadata only! Data stored by Identity Provider and obtained only when card submitted CardSpace Cards SELF - ISSUEDMANAGED

12. Platform & Technology Independent Third-party support for Firefox http://perpetual-motion.com/kevin/ Information Card support on MAC-Safari http://www.identityblog.com/?p=579 Open Source Initiatives Higgens Trust Framework Project

13. Perspective #2 CardSpace as an abstraction layer for authentication mechanisms Orchestrate the dead of the password Orchestrate the dead of the password Multi-factor Authentication Multi-factor Authentication

14. Root Causes of e-Identity Theft Lack of Awareness Vulnerabilities/ Spyware Weak foundation provided by password systems Admin password Admin.R386W 992 Days After Product Release 87 Released 11/29/2000 Released 09/28/2003 51

15. Abstraction Layer

16. eID Cards Microsofts support Enterprise Scenarios Consumer Scenarios

17. Perspective #3 CardSpace as an anti-phishing technology Move away from ID/Passwords Move away from ID/Passwords Human integration Human integration

18. How to remember all these passwords?

19. Identity Crisis The Internet is a dangerous place! Identity theft, spoofing, phishing, phraud, malware Username + password is weak and overwhelmed Poor choice Poor management Poor (re-)use How do we safely, reliably identify a site to a user… …and a user to a site? Good phishing sites fooled 90% of participants - Harvard

20. Human Integration A simple, consistent, secure way to represent identity Support cryptographic verifiable, yet user-friendly Security Tokens

21. Wallet Metaphor A set of claims someone makes about me Claims are packaged as security tokens Many identities for many uses Useful to distinguish from profiles

22. Windows CardSpace Enables federated claims-based identity Lingua franca for identity, roles & attributes that builds on EID Any identity/service provider can integrate using public WS-* protocols Identity provider support for: Windows Server with Active Directory PingID for Linux, UNIX, Apache, others More to come… New credential common dialog One-click login Streamlines user registration Mitigates some common attack vectors (e.g. phishing) Additional privacy benefits

23. Perspective #4 CardSpace as a user convenience technology

24. Demo

25. Perspective #5 CardSpace as a security technology Move away from ID/Passwords Move away from ID/Passwords Secure Desktop integration Secure Desktop integration

26. Windows CardSpace Easier Provides consistent user experience Replaces usernames and passwords with strong tokens Safer Protects users from phishing & phraud attacks Support for two-factor authentication Tokens are crypto- graphically strong Standards, standards, standards!! Built on WS-* Web Services Protocols Can be supported by websites on any technology & platform

27. Secure CardSpace Environment Runs under separate desktop and restricted account Isolates CardSpace runtime from Windows desktop Deters hacking attempts by user-mode processes

28. Perspective #6 CardSpace as a privacy enhancing technology User control on revealing identity information User control on revealing identity information No unique identifiers No unique identifiers Fine-grained Claims – mandates & identity attributes Fine-grained Claims – mandates & identity attributes

29. Many privacy concerns with existing identity systems Microsoft Passport The systems reveal too much privacy-related information Linkability of transactions because of unique identifier (e.g. public keys)

30. Privacy attributes of CardSpace The user controls which data to reveal to the relying party No need for the relying party to copy all privacy related information A different identifier used for each relying party Allows for fine-grained identity attributes E.g. Claim (Subject above 18)

31. Perspective #7 CardSpace as a development framework Integration into.NET Framework 3.0 Integration into.NET Framework 3.0 IE7 Integration IE7 Integration Easy integration Easy integration

32. .NET At The Core XP XP Vista Vista W2k3 W2k3

33. Building a Relying Party Four key tasks Update user database Create an association page Update the sign in page Update the registration page Examples here in ASP.NET 2.0 But can be done in PHP/Java/PERL/etc. if required

34. Create an association page Update account with your Information Card <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"> <param name="issuer value="http://schemas..../identity/issuer/self"> <param name="requiredClaims" value="http://.../claims/givenname, http://.../claims/surname, http://../claims/emailaddress, http://.../claims/privatepersonalidentifier">

35. Update the sign in page Sign in with your Information Card <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"> <param name="issuer value="http://schemas..../identity/issuer/self"> <param name="requiredClaims" value="http://.../claims/givenname, http://.../claims/surname, http://../claims/emailaddress, http://.../claims/privatepersonalidentifier">

36. Update the registration page Register with your Information Card <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"> <param name="issuer value="http://schemas..../identity/issuer/self"> <param name="requiredClaims" value="http://.../claims/givenname, http://.../claims/surname, http://../claims/emailaddress, http://.../claims/privatepersonalidentifier">

37. Seven Perspectives on CardSpace 1. Component of the identity metasystem 2. Abstraction layer for authentication technologies 3. Anti-phishing technology 4. User convenience 5. Security 6. Privacy 7. Development Framework

38. Resources Windows Vista Security http://www.microsoft.com/windows/longhorn/security.mspx CardSpace http://msdn2.microsoft.com/en-us/netframework/default.aspx http://www.identityblog.com/ http://cardspace.netfx3.com

39. © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.