1. Open Standards for Network Identity Liberty Alliance Project Open Standards for Network Identity Will open standards increase eCommerce? Bill Smith Director, Liberty Alliance Technology Sun Microsystems

2. 1 The author has graciously given permission to reproduce his presentation at the XML 2002 Conference in Baltimore, Maryland. If copied, changes should not be made and appropriate citation of the author’s work should be given. Instructional media + magic, inc., December 2002 Permissions

3. 1 Brief Intro to Liberty Alliance Business Needs and Uses Technical Overview Scenario Q&A

4. 11 Physical Height, Weight, Gender Experiential Education, Travel, Dining Preferential Food, Clothing, Shelter Identity

5. 11 Physical Height, Weight, Gender Blood Type, Fingerprint, DNA Experiential Education, Travel, Dining Stock Purchases, Mortgage Balance, Drug Use Preferential Food, Clothing, Shelter Religion, Political affiliation, Club Memberships Identity

6. 11 Some information needed to determine who I am is widely available – I distribute it A larger set of information is unavailable – I restrict access to trusted relationships Most of this information is in digital form Identity

7. 11 Control who has access to what information Choose who to trust, what to give, when to change Trust relationships take time to establish Identity

8. 11 Much of the information about me is in digital form, accessible via the Web It is kept by “trusted brokers” High-quality services are provided I can access and update Digital Identity

9. 11 Much of the information about me is in digital form, accessible via the Web It is kept by “trusted brokers” High-quality services are provided I can access and update What's the problem?... Digital Identity

10. 11 I have multiple Digital IDs Information is duplicated and difficult to synchronize Better services are possible Digital Islands

11. 11 Multiple, disconnected identities scattered across isolated Internet sites User Name: Bill Smith Email: bsmith48@freemail.com PIN: wcs@foobar.com Credit card number Social security number Drivers license Passport Entertainment preferences Notification preferences Employee authorization Business calendar Dining preferences Education history Medical history Financial assets… Digital Islands

12. 11 Multiple, disconnected identities scattered across isolated Internet sites Inconvenient and frustrating for users Distributed identity- services are difficult to develop and deploy Continual re- authentication to disparate systems Digital Islands – the problem

13. 11 A method to link the Digital Islands Provide a logical single identity Preserve and enhance existing trust relationships Provide choice and opportunity for better services Network Identity – the solution

14. 1 Simplify B2B e-commerce offerings  Simplify the ability for businesses to collaborate online  Make it easier to offer new services to customers  Allow organizations to maintain ownership of their customer bases and to maintain operational autonomy Simplify and expand employee use of enterprise Intranets  Enable employees to move seamlessly from one application to another Facilitate interoperability  With existing systems, standards, and protocols Increase consumer confidence and usage in electronic transactions  Easier and more convenient to use  Available via any digital device  As secure as possible  Targeted and more personalized  Enable offerings that allow consumers to maintain control over their information Why is Liberty Alliance the Solution?

15. 11 A Network Identity is a user’s overall global set of attributes constituted from their various accounts Network Identity – it’s simple

16. 11 Digital Islands Disparate Systems Lack of communication, interoperability Conflicting Interests Technology suppliers, Technology consumers Service providers, fixed vs. mobile Consumer Demands Better services, Improved convenience Respect Privacy Network Identity – not so fast

17. 11 Broad scope Web itself Fixed, wireless, desktop, cell phone, PDA, car... Complexity Technology, Business, Consumer Service providers Reality Digital Islands exist Trust relationships well-established Network Identity – practical solutions

18. 1 Over 130 for-profit, not-for-profit and government organizations, representing a billion customers, are currently Alliance members * Only a sample of Liberty members A Business Consortium Solving A Business Problem

19. 1 Liberty’s commercial investment in network identity and the collaboration of its diverse array of member companies can bring a lot to this space. The group’s combined experience, their collective ability to drive usage and the fact that they’re not trying to promote a product but a solution to a problem will help in their success. Dan Blum Burton Group

20. 1 Improve ease of use for e-commerce Support a broad range of identity-based products and services Allow for consumer choice of identity provider(s) and the ability to link accounts through account federation Provide the convenience of simplified sign-on, when using any network of connected services and devices Enable organizations to realize new revenue and cost saving opportunities Allow organizations to economically leverage relationships with customers, business partners, and employees 1 Establish an open standard for federated network identity through open technical specifications that will: Mission of the Liberty Alliance

21. 1 Management Board Public Policy Expert Group Marketing Expert Group Technology Expert Group Advise on privacy, security, and other public policy issues Liaison to privacy groups and government agencies Develops technical architecture and engineering requirements Develops technical specifications Interoperability Develops marketing requirements and use cases Responsible for membership, press relations, and marketing communications Adoption Consists of 16 founding sponsors Responsible for overall governance and maintenance Final voting authority for specifications and other output Management Structure

22. 1 Brief Intro to Liberty Alliance Business Needs and Uses Technical Overview Scenario Q&A

23. 1 Provider Central Provider Centralized Model Network identity and user information in single repository Centralized control Single point of failure Links similar systems Open Federated Model Network identity and user information in various locations No centralized control No single point of failure Links similar and disparate systems Why is Federated Important?

24. 1 Bank ATM Network A Bank ATM Network B Bank ATM Network C Bank A ATM Card Bank B ATM Card Bank C ATM Card Bank A ATM Card Bank B ATM Card Bank C ATM Card Bank ATM Network A Bank ATM Network B Bank ATM Network C Separate Cards with Each Bank Linked Cards within Bank Networks Seamless Access Across all Networks Solution Analogous to ATM Networks

25. 1 Linkage of Trust Domains.com Bank ATM Network A Bank ATM Network B Bank ATM Network C Bank A ATM Card Bank B ATM Card Bank C ATM Card Individual Accounts with Many Web Sites.com Bank A ATM Card Bank B ATM Card Bank C ATM Card Federated Accounts within Trust Domain.com Bank ATM Network A Bank ATM Network B Bank ATM Network C Separate Cards with Each Bank Linked Cards within Bank Networks Seamless Access Across all Networks Solution Analogous to ATM Networks

26. 1 TreasuryDebt Equity Commercial Banking Credit Clearing House B2B – Financial Services SuppliersDealers Transport Agencies Manufacturers FinancingFleet B2B - Automotive Car Rental Hotel Partner Airlines Airline Livery Cruise Line B2C – Travel Industry 401k 3d Party Providers Employee Purchase Plans Dental Insurance Health Insurance Company Intranet B2E – Employee Intranet Examples of Trust Domains

27. 1 Support rapid acceptance and deployment Phases build on each other Enable incremental adoption Permissions-based attribute sharing Schema/protocols for core identity profile service Simplified sign-on across authentication domains created in version 1.0 by business agreements Delegation of authority to federate identities/accounts Future Versions Version 1.0 (Released 15 July 2002) Federated network identity Opt-in account linking and simplified sign-on within an authentication domain created by business agreements Security built across all the features and specifications Approach Drivers Specifications: A Phased Approach

28. 1 Enhance “Affinity” Relationships More Easily Offer Value Add Services to Customers Simplify Customer Experience Improve Customer Confidence Enhance Intra-Enterprise Relationships Offers Accelerated Time to Market for Identity Based Services Business Benefits for Version 1.0 Specifications

29. 1 Brief Intro to Liberty Alliance Business Needs and Uses Technical Overview Scenario Q&A

30. 1 Security Assertion Markup Language (SAML) An XML-based framework for exchanging security information (e.g. authentication) A committee specification in the OASIS security services technical committee Liberty Alliance Defines protocol specifications for federated identity built on SAML to provide additional privacy and security Liberty is not an identity network or authentication authority -- it defines specs that can be used to create identity networks Enabling the Federated Identity

31. 1 Builds on top of SAML to provide additional privacy and functionality  Opt-in account linking – Users can link their accounts with different service providers within “circles of trust”  Enhanced single sign-on for linked accounts – Once users’ accounts are federated, they log-in, authenticate at one linked account and navigate to another linked account, without having to log-in again  Authentication context – Companies linking accounts communicate the type of authentication that should be used when the user logs-in  Global log-out – Users can be automatically logged-out of all sites to which they have active sessions  Multiple Client Support – browser, mobile device, and proxy Version 1.0 Specifications

32. 1  An XML-based framework for exchanging security information 1. XML schema and definition for security assertions 2. XML schema and definition for a request/response protocol 3. Rules on using assertions with standard transport and messaging frameworks (SOAP, Web Browsers). Bindings and Profiles  An OASIS standard – Vendors and users are both involved – Codifies current system outputs rather than inventing new technology  Excellent traction in the marketplace SAML in a Nutshell

33. 1  XML Signature SAML uses this for signing assertions  XML Encryption Important for flexibly managing security and privacy risks, e.g., encrypting just the credit card number  Other XKMS can be used for key management XACML can be used for an access control policy language XML Related Security Standards Work

34. 1  An assertion is a declaration of fact, according to some authority  Assertions are produced by an asserting party (aka authority) and consumed by a relying party  An assertion contains a set of statements about a subject (human or program): Authentication statement Attribute statement Authorization decision statement  An assertion can be digitally signed by the asserting party  You can extend SAML to make your own kinds of assertions and statements SAML Assertions

35. 1 Assertion Authentication Statement Authorization Statement Attribute Statement IssuerID IssueInstant AssertionID Signature SAML Assertions and Statements

36. 1 SAML Producer/Consumer Model

37. 1  SAML can be used ala-carte: it’s a composable architecture, making it very flexible.  In practice, multiple kinds of authorities may reside in a single system  The arrows may not reflect information flow in real life The order of assertion types is insignificant Information can be pulled or pushed Not all assertions are always produced Not all potential consumers (clients) are shown  SAML must be “profiled” to specify actual usage (e.g. browser-based single-sign-on) SAML is “Cafeteria Style”

38. 1 Be recognized Excite.com Authentication Authority Pets.com Relying Party Login Browser-based SSO

39. 1 1. Relying Party uses HTTP redirect or Form Post to Authentication Authority Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

40. 1 1. Relying Party uses HTTP redirect or Form Post to Authentication Authority 2. User redirected to Authentication Authority and logs in Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

41. 1 1. Relying Party uses HTTP redirect or Form Post to Authentication Authority 2. User redirected to Authentication Authority and logs in 3. User is authenticated Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

42. 1 4. Redirect back to Relying Party with a “nonce” embedded in the URI Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

43. 1 5. Relying Party receives nonce in the redirect process. 4. Redirect back to Relying Party with a “nonce” embedded in the URI Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

44. 1 5. Relying Party receives nonce in the redirect process. 4. Redirect back to Relying Party with a “nonce” embedded in the URI 6. Relying Party invokes SAML- based web service to obtain an Authentication Assertion Excite.com Authentication Authority Pets.com Relying Party SAML Browser-based SSO

45. 1 Pre-existing accounts at various sites can be linked Pets.com Service Provider JoeSmith Books.com Service Provider Joe Excite.com Identity Provider Joe123 Liberty Federation/ Account Linking

46. 1 Upon linking those accounts, the sites need to be able to have a frame of reference for the user Pets.com Service Provider JoeSmith Books.com Service Provider Joe Excite.com Identity Provider Joe123 Liberty Federation/ Account Linking

47. 1 If account names are exchanged, sites can talk to each other without the user’s approval Pets.com Service Provider JoeSmith Books.com Service Provider Joe Excite.com Identity Provider Joe123 JoeSmith@pets.com Joe@books.com Joe123@excite.com Liberty Federation/ Account Linking

48. 1 If account names are exchanged, sites can talk to each other without the user’s approval Pets.com Service Provider JoeSmith Books.com Service Provider Joe Excite.com Identity Provider Joe123 JoeSmith@pets.com Joe@books.com Joe123@excite.com Liberty Federation/ Account Linking

49. 1 <alias="mr3tTJ340ImN2ED" SecurityDomain=“Pets.com" Name="dTvIiRcMlpCqV6xX" /> <alias=“xyrVdS+xg0/pzSgx" SecurityDomain=“Books.com" Name="pfk9uzUN9JcWmk4RF" /> <alias="dTvIiRcMlpCqV6xX" SecurityDomain="excite.com" Name="mr3tTJ340ImN2ED" /> <alias="pfk9uzUN9JcWmk4RF" SecurityDomain="excite.com" Name="xyrVdS+xg0/pzSgx" /> Instead, unique opaque handles resolvable only by the issuer should be exchanged Pets.com Service Provider JoeSmith Books.com Service Provider Joe Excite.com Identity Provider Joe123 Liberty Federation/ Account Linking

50. 1  Extends an authentication assertion to include the “context” How did the user log in? Password? Smartcard? Etc. When should the user be re-authenticated? How did account registration occur? (in person, via web page)  Extends the authentication request to allow for requesting a strength of authentication  Necessary for real-world scenarios: not all services require the same level of authentication. Liberty – Enhanced SSO

51. 1  Simple session management Provides “single-logout” functionality  Identity federation management Ability to terminate the federation Ability to modify the opaque handle shared between authentication authority and relying party  Identity network support Specifies a protocol by which a website can “discover” what Identity Provider a user is using Liberty – Additional Features

52. 1 Liberty Enabled-Products Coming Soon!

53. 1  Permissions-Based Attribute Sharing Enable businesses to share a principal's attributes according to their corporate policies, business agreements and local regulations, all while adhering to the principal's preferences and permissions  Interoperability Specs for Core Identity Profile Service Enables users to obtain secure, personalized services that are interoperable across different service providers  Federation of Authentication Domains Enables users to conveniently navigate and use SSO and share attributes with service providers who may be in different authentication domains. Version 2.0 specifications expected early 2003 Liberty Version 2.0

54. 1 3. Service provider sends SMS message to mobile operator 1. User registers to “watch” an auction 2. Service provider requests SMS ticket 4. Mobile operator sends SMS message to user ActionWatch.com Service Provider Excite.com Identity Provider PacBell.com Service Provider Identity Provider doesn’t see message text Possible Interactions

55. 1 User’s data is only released with the user’s consent and based on the user-defined policies Pets.com Service Provider 1. service provider requests user attributes from identity provider 3. user accepts or rejects exceptions to existing policies and preferences 2. attributes released per user’s policies and preferences Excite.com Identity Provider Policy Enforcement Concepts

56. 1 How do Liberty Alliance and Microsoft Passport Contrast and Compare?  Liberty Alliance is providing specifications supported by many companies  Offers a non-repeating unique identifier for authentication  Does not dictate authentication method (I.e. biometrics, smartcard, etc.)  Liberty Alliance has committed to use SAML, and can also support Kerberos  Microsoft Passport is a product/service supported by one company  Uses a global PUID (Passport User ID) for authentication  Limited flexibility in authentication methods (I.e. user name/password)  Microsoft has committed to Kerberos and to support SAML Liberty & Passport Comparison

57. 1 3. User redirected to Passport.com for log-in Service.com Passport 1. User attempts to access Service.com Identity.com Identity.com sits in both Passport & Liberty communities – acts as a bridge 2. User redirected to Liberty IDP Identity.com Scenario 1 Passport & Liberty Co-existence

58. 1 Service.com Passport Identity.com Identity.com sits in both Passport & Liberty communities – acts as a bridge 4. After Passport log-in, User gets redirected to Identity.com, which issues a Liberty SAML assertion 5. SAML assertion delivered to Service.com which grants access to User Scenario 1 Passport & Liberty Co-existence

59. 1 3b. User redirected to Passport.com for log-in for low-value transactions Service.com Passport 1. User attempts to access Service.com Identity.com Service.com sits in both Passport & Liberty communities – uses them appropriately 2. Service.com determines to which SSO infrastructure to redirect User based on transaction 3a. User redirected to Identity.com requesting strong authentication for high-value transaction Scenario 2 Passport & Liberty Co-existence

60. 1 Brief Intro to Liberty Alliance Business Needs and Uses Technical Overview Scenario Q&A

61. 1  Many enterprises outsource various business functions, e.g.: Corporate intranet 401(k) management Stock option management Others – (expense vouching, payroll statements, etc.)  Liberty facilitates better integration of the outsourced services to decrease administration cost and enhance user experience  Liberty-enabled enterprise will play a role of a Liberty Identity Provider to manage identities and authentications of their employees, who will access their accounts on the outsourced Liberty Services Providers without additional prompts for authentication  Enterprise-issued identities will cross application, division and corporate boundaries Enterprise Use Case

62. 1 Brief Intro to Liberty Alliance Business Needs and Uses Technical Overview Scenario Q&A

63. 11 Established to address real business and technology issues Recognized as the focal point for Network Identity discussions and solutions Produced well-received specification Proceeding with phased approach to deliver on vision and mission Liberty – the Initiative