OpenID Connect Update

1. OpenID ConnectUpdate March 28, 2012 Mike Jones Identity Standards Architect – Microsoft

2. Working Together OpenID Connect

3. Working Group Participants • Key working group participants: • Nat Sakimura – Nomura Research Institute – Japan • John Bradley – Independent – Chile • Breno de Medeiros – Google – US • Paul Tarjan – Facebook – US • Axel Nennker – Deutsche Telekom – Germany • Torsten Lodderstedt – Deutsche Telekom – Germany • Kick Willemse – Independent – Netherlands • Chuck Mortimore – Salesforce – US • Justin Richer – Mitre - US • Mike Jones – Microsoft – US • By no means an exhaustive list!

4. OpenID Connect Intro • Simple identity layer on top of OAuth 2.0 • Enables clients to verify identity of end-user • Enables clients to obtain basic profile info • REST/JSON interfaces => low barrier to entry

5. OpenID Connect Range • Spans use cases, scenarios • Internet, Enterprise, Cloud, Mobile • Spans security & privacy requirements • From non-sensitive information to highly secure • Spans sophistication of claims usage • From basic default claims to specific requested claims to aggregated and distributed claims • Maximizes simplicity of implementations • Reuses existing OAuth 2.0, JWT, SWD specs • Build only the pieces you need

6. Key Diffs from OpenID 2.0 • Support for native client applications • Identifiers using e-mail address format • Standard UserInfo functionality for simple “Connect” capability • Designed to work well on mobile phones • Uses JSON/REST, rather than XML • Support for encryption and higher LOAs • Support for distributed and aggregated claims

7. Presentation Overview • Introduction • Design • A Look Under the Covers • Overview of Connect Specs • Recent Timeline • Developer Feedback Incorporated • Next Steps • Resources

8. Design Philosophy

9. Standard UserInfo for Simple “Connect” Ability Simple Things Simple • Designed to Work Well on Mobile Phones

10. How We Make It Simple • Build on OAuth 2.0 • Use JavaScript Object Notation (JSON) • Can build only the pieces that you need • Goal: Easy implementation on all modern development platforms

11. Aggregated Claims Complex Things Possible • Distributed Claims • Encrypted Claims

12. Aggregated Claims Data Source Data Source Signed Claims Claim Values Identity Provider Relying Party

13. Distributed Claims Data Source Data Source Signed Claims Claim Refs Relying Party Identity Provider

14. Connect Interop Status • Interop at http://osis.idcommons.net/ • By the numbers: • 8 implementations participating • 56 feature tests defined • 507 feature test results recorded • 57 members of interop mailing list • 239 messages to interop mailing list

15. A Look Under the Covers • ID Token • Claims Requests • UserInfo Claims

16. ID Token • JWT token representing logged-in session • Claims: • iss– Issuer • user_id – Identifier for user • aud – Audience for ID Token • exp – Expiration time • nonce – Mitigates replay attacks

17. ID Token Claims Example { "iss": "https://server.example.com", "user_id": "248289761001", "aud": "0acf77d4-b486-4c99-bd76-074ed6a64ddf", "exp": 1311281970, "nonce": "n-0S6_WzA2Mj" }

18. Claims Requests • Basic requests made using OAuth scopes: • openid– Declares request is for OpenID Connect • profile – Requests default profile info • email – Requests email address and verification status • address – Requests postal address • phone– Requests telephone number • Requests for specific claims made using JSON OpenID Request Object • Enables requesting arbitrary sets of claims

19. UserInfo Claims • user_id • name • given_name • family_name • nickname • profile • picture • website • email • verified • gender • birthday • zoneinfo • locale • phone_number • address • updated_time

20. UserInfo Claims Example { "user_id": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com", "verified": true, "picture": "http://example.com/janedoe/me.jpg" }

21. Connect Specs Overview

22. Recent Timeline • Artifact Binding working group formed, Mar 2010 • Weekly spec calls began, Jan 2011 • Open issues closed at IIW, May 2011 • Result branded “OpenID Connect”, May 2011 • Developer feedback, May 2011 to present • Functionally complete specs, Jul 2011 • Formal issue tracking began, Jul 2011 • Interop testing, Sep-Nov 2011 • Simpler specs published incorporating developer feedback, Sep & Oct 2011 • Published Proposed Implementer’s Drafts, Dec 2011 • Implementer’s Drafts Approved Feb 2012 • Interop testing, Feb 2012 to present

23. Developer Feedback Incorporated • Ask: Simpler, more modular specs • Created Basic Client Profile as a result • Messages and Standard also simplified • Ask: UserInfo schema similar to Facebook Connect • Changed spelling of claim names from camelCase to lowercase_with_underscores • Ask: More meaningful JSON identifiers • Changed OpenID identifiers to be full words, e.g.: • it → id_token • loc → preferred_locales • Ask: Enable single-sign-on without requiring UserInfo • Can now receive just an ID Token, if desired

24. Open Issues • New Session Management spec needed • Need to understand impact on other specs • Want it to work with Account Chooser • Google prototyping possible solutions • Several specific outstanding feature proposals • Resulted from feedback on implementer’s drafts • Mostly already resolved • Need interop on the new features incorporated

25. Risks • Dependencies on IETF specs/processes • OAuth specifications: • OAuth 2.0 Core, Bearer, Assertions • JOSE specifications: • JWS, JWE, JWA, JWK • Currently homeless specifications: • JWT, OAuth JWT Profile, SWD • IETF could change/delay any of these specs

26. Next Steps • Continue incorporating spec feedback • Create new Session Management spec • Vote it to Implementer’s Draft status • Encourage/monitor deployments • Once all specs are complete/stable: • Create final specification drafts • OIDF vote to approve final specifications

27. Resources • OpenID Connect Page • http://openid.net/connect/ • OpenID Connect Working Group Mailing List • http://lists.openid.net/mailman/listinfo/openid-specs-ab • OpenID Connect Interop Wiki • http://osis.idcommons.net/ • OpenID Connect Interop Mailing List • http://groups.google.com/group/openid-connect-interop • Mike Jones’ Blog • http://self-issued.info/ • Nat Sakimura’s Blog • http://nat.sakimura.org/ • John Bradley’s Blog • http://www.thread-safe.com/

28. Backup Slides

29. Connect Capabilities • Dynamic Clients • Mobile Support • UserInfo Endpoint • Simple RPs • Session Management • Single Logout • Aggregated and Distributed Claims • Encrypted Claims

30. Authorization Request Example https://server.example.com/authorize ?response_type=token%20id_token &client_id=0acf77d4-b486-4c99-bd76-074ed6a64ddf &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj

31. Authorization Response Example HTTP/1.1 302 Found Location: https://client.example.com/cb #access_token=mF_9.B5f-4.1JqM &token_type=bearer &id_token=eyJhbGzI1NiJ9.eyJz9Glnw9J.F9-V4IvQ0Z &expires_in=3600 &state=aF0ifJsLD_k9J

32. UserInfo Request Example GET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM

33. Basic Client Profile • Single, simple, self-contained Web client spec • All you need for web-based RP utilizing pre-configured set of OPs • http://openid.net/specs/openid-connect-basic-1_0.html

34. Discovery & Registration • Enables dynamic configurations in which sets of OPs and RPs are not pre-configured • Necessary for open deployments • Discovery enables RPs to learn about OP endpoints • Dynamic registration enables RPs to use OPs they don’t have a pre-existing relationship with • http://openid.net/specs/openid-connect-discovery-1_0.html • http://openid.net/specs/openid-connect-registration-1_0.html

35. Messages & Standard • Messages spec defines data formats exchanged in OpenID Connect messages • Standard spec is HTTP binding for Messages • (Basic is a profile of Messages and Standard) • Needed for OPs, native client apps, and RPs needing functionality not in Basic • E.g., claims not in default UserInfo set • http://openid.net/specs/openid-connect-messages-1_0.html • http://openid.net/specs/openid-connect-standard-1_0.html

36. Session Management • For OPs and RPs needing session management capabilities • For example: Logout • http://openid.net/specs/openid-connect-session-1_0.html

37. Underpinnings • OAuth 2.0 family of specs • OAuth 2.0 Core • OAuth 2.0 Bearer • OAuth 2.0 Assertions • OAuth 2.0 JWT Assertions Profile • JWT family of specs • JSON Web Token (JWT) • JSON Web Signature (JWS) • JSON Web Encryption (JWE) • JSON Web Algorithms (JWA) • JSON Web Key (JWK) • Simple Web Discovery (SWD)

38. Connect OAuth Specs • draft-ietf-oauth-v2 – Nearing RFC • draft-ietf-oauth-v2-bearer – Nearing RFC • draft-ietf-oauth-assertions – Last call • draft-ietf-oauth-v2-threatmodel – Last call

39. Connect JOSE Specs • draft-ietf-jose-json-web-signature – WG Draft • draft-ietf-jose-json-web-encryption – WG Draft • draft-ietf-jose-json-web-algorithms – WG Draft • draft-ietf-jose-json-web-key – WG draft

40. Connect Homeless Specs • draft-jones-json-web-token – Target OAuth WG • draft-jones-oauth-jwt-bearer – Target OAuth WG • draft-jones-simple-web-discovery – Target OAuth WG Securing homes for these specs a key goal this week

41. Related Specs • draft-hardjono-oauth-dynreg • Related goals to open-connect-registration • Token type and use case agnostic • Versus openid-connect-registration, which intentionally embed deep knowledge of Connect use case, including token type, etc. • User Managed Access (UMA) Specs • Use Connect specs for authentication