1. InfoCard and the Identity Metasystem Kim Cameron, Chief Architect of Identity Microsoft

2. Threats to Online Safety The Internet was built without a way to know who and what you are connecting to Internet services have one-off “workarounds” Inadvertently taught people to be phished Greater use and greater value attract professional international criminal fringe Exploit weaknesses in patchwork Phishing and pharming at 1000% CAGR Missing an “Identity layer” No simplistic solution is realistic

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

4. Lessons from Passport Passport designed to solve two problems Identity provider for MSN 300M+ users, 1 billion logons per day Identity provider for the Internet Unsuccessful Learning: solution must be different than Passport

5. “The Laws of Identity” 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

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

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

8. Empowers the User… Governments Individuals Work & Consumer PrivateBusinesses Technologies X509, Kerberos, SAML Applications Existing & New Organizations Devices PCs, Mobile, Phone You

9. InfoCard Overview Simple user abstraction for digital identity For managing collections of claims For managing keys for sign-in and other uses Grounded in real-world metaphor of physical cards Government ID card, driver’s license, credit card, membership card, etc… Self-issued cards signed by user Managed cards signed by external authority Shipping in WinFX Runs on Windows Vista, XP, and Server 2003 Implemented as protected subsystem

10. Implementation Properties Cards represent references to identity providers Cards have: Address of identity provider Names of claims Required credential Not claim values InfoCard data not visible to applications Stored in files encrypted under system key User interface runs on separate desktop Simple self-issued identity provider Stores name, address, email, telephone, age, gender No high value information User must opt-in

11. Protected Subsystem Prevent disclosure of personal data and keys to malicious code on the client System service running at elevated privilege Encrypted storage accessible only by system service User session agent process on separate desktop System managed user secret displayed in UI User interaction required to release PII

12. “InfoCard” User Experience Preview

13. An Identity Metasystem 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 Only technology we know of specifically designed to satisfy requirements of an identity metasystem

14. Web Site Security Token Server (STS) Browser w/ InfoCard Identity Provider (Managed or Self-Issued) Relying Party Web Site Front End 5 HTTP(S)/POST Token to Target Page    Cookie + Browser Redirect 3 InfoCard lights up User selects card HTTP(S)/GET (Protected Page)  1  Redirect to Login Page Basic Protocol Flow 4 Get token via WS-MetadataExchange and WS-Trust  Login Page (HTML) w/ InfoCard Tags HTTPS/GET (Login Page)  2  HTML Content HTTP(s) / GET WITH COOKIE  6

15. Browser Integration Design Goals Minimal impact on web site front end Support from multiple browsers Fail gracefully if not supported – no negative impact on user experience for browsers that do not support integration

16. Incremental Addition of InfoCard User Web Farm Forms Based Login Authentication Cookie InfoCard Login Cookie Authentication Cookie HTTP Server HTTP Server HTTP Server HTTP Server

17. OBJECT Tag Welcome to Fabrikam <form name="ctl00" id="ctl00" method="post" action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx"> <input type="submit" name="InfoCardSignin" value="Log in" id="InfoCardSignin" /> <PARAM Name="issuer" Value= "urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self"> <PARAM Name="requiredClaims" Value= "http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname http://schemas.microsoft.com/ws/2005/05/identity/claims/surname"> Welcome to Fabrikam <form name="ctl00" id="ctl00" method="post" action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx"> <input type="submit" name="InfoCardSignin" value="Log in" id="InfoCardSignin" /> <PARAM Name="issuer" Value= "urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self"> <PARAM Name="requiredClaims" Value= "http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname http://schemas.microsoft.com/ws/2005/05/identity/claims/surname">

18. Ubiquitous Implementation a Key Goal Fully interoperable via published protocols With other identity selector implementations With other relying party implementations With other identity provider implementations Detailed implementation guide available The industry has created an Open Source Identity Selector Consortium animated by Verisign, Red Hat, Novell, IBM, and others Microsoft provides technical assistance

19. Components Microsoft is Building “InfoCard” identity selector Component of WinFX, usable by any application Hardened against tampering, spoofing “InfoCard” simple self-issued identity provider Self-issued identity for individuals running on PCs Uses strong public key-based authentication – user does not disclose passwords to relying parties Active Directory managed identity provider Plug Active Directory users into the metasystem Full set of policy controls to manage use of simple identities and Active Directory identities Windows Communication Foundation for building distributed applications and implementing relying party services

20. For More Information Whitepapers Microsoft’s Vision for an Identity Metasystem The Laws of Identity Documentation InfoCard implementer’s guides InfoCard browser integration guide Code and samples Federated Identity and Access Resource Kit WinFX runtime Links from: http://www.identityblog.com http://msdn.microsoft.com/winfx/ reference/infocard/

21. (Backup Slides)

22. WS-Trust, WS-MetadataExchange WS-* Metasystem Architecture Security Token Service Kerberos WS-SecurityPolicy SAML Security Token Service WS-SecurityPolicy … ID Provider x509 ID Provider Subject Relying Party Identity Selector

23. Web Site Front End Identity Provider (Managed or Self-Issued) Security Token Server (STS) Browser w/ InfoCard Relying Party 6 Token  via WS-Trust/RST Token  via WS-Trust/RSTR 3 Security Token Server (STS)  Login Page (HTML) w/ InfoCard Tags HTTPS/GET (Login Page)  2 4 InfoCard lights up User selects card 5 Get token via WS-MetadataExchange and WS-Trust 7 HTTP(S)/GET (Protected Page)   Redirect to Login Page 1 Web Site HTTP(S)/POST Token to Target Page  Retrieve Policy  via WS-MetadataExchange    Cookie + Browser Redirect Flow with Relying Party STS