Web Authorization Protocol V. Bertocci Internet-Draft auth0.com Intended status: Informational G. Fletcher Expires: 26 July 2021 Verizon Media 22 January 2021 Identity Use Cases in Browser Catalog draft-bertocci-identity-in-browser-00 Abstract This informational document aims to gather in a single place all the most important scenarios in which identity protocols in current use leverage web browser features to achieve their goals and deliver their intended user experience. The purpose of compiling this scenario collection is to make it easier for the identity community to engage with the browser vendors, and in particular to preserve (or enhance) user experience and expressive power of the identity protocols in mainstream use as browsers introduce new privacy preserving restrictions and new identity tailored features. By providing a single artifact, listing scenarios in a consistent format, we hope to anchor the conversation on concrete outcomes and impact of changes on end users, developers, providers and in general everyone contributing to identity in the industry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 July 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Bertocci & Fletcher Expires 26 July 2021 [Page 1] Internet-Draft browser-use-cases January 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Contribution Process . . . . . . . . . . . . . . . . . . . . 4 3.1. Contributing Scenarios . . . . . . . . . . . . . . . . . 4 3.2. Discussing Scenarios Details and Inclusion . . . . . . . 5 4. The Use Case Template . . . . . . . . . . . . . . . . . . . . 5 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. OpenID Connect Redirect Based Sign in via Form POST . . . 6 5.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Description Of The Flow . . . . . . . . . . . . . . . 7 5.1.3. Intended User Experience . . . . . . . . . . . . . . 8 5.1.4. Privacy Considerations . . . . . . . . . . . . . . . 8 5.1.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . 8 5.2. TODO Scenario Title . . . . . . . . . . . . . . . . . . . 8 5.2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Description Of The Flow . . . . . . . . . . . . . . . 9 5.2.3. Intended User Experience . . . . . . . . . . . . . . 9 5.2.4. Privacy Considerations . . . . . . . . . . . . . . . 9 5.2.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Overview As attempts to profile and track user activities on the web intensify, leading to increasingly egregious privacy violations, browser vendors introduce new constraints meant to thwart known tracking techniques. As they do so, however, they often end up breaking legitimate use cases as well- with identity protocols features such as single sign on, token renewals and the like being disptoportionally affected. Conscious of those effects and committed to preserve user experience, browser vendors are working on dedicated identity API that aim at preserving and enhancing the user experience Bertocci & Fletcher Expires 26 July 2021 [Page 2] Internet-Draft browser-use-cases January 2021 in identity transactions, without relying on the general purpose artifacts on which current identity protocols depend on. One key challenge that is emerging in the process is that browser vendors tend to design around a limited set of well-known, consumer-only use cases, classifying most other cases as enterprise use cases hence solvable by exceptions and local business policies, whereas that is often not the case (e.g., single sign on is a common requirements across web properties even for consumer services, such as online managines form the same publisher) or the expected solutions (e.g. companies deploying MDM and managing policies on their employees and contributors machines) are not always viable. Discussions between browser vendors and identity experts are not always easy, and are frequently repeated whenever the individuals and initiatives involved change. This makes progress difficult. This infomational document is a collection of use cases in which identity protocols depend on web browser features to perform their intended function. By gathering the main use cases in a single, shared artifact, and by describing every use case thru a fixed schema designed to surface the most salient characteristics germane to the identity-browser features discussion, we aim to provide a tool to facilitate conversations between browser vendors and identity experts. This is meant to be a living document, constantly gathering and discussing scenarios contribuitions (via dedicated GitHub repository and OAuth working group mailing list) and periodically incorporating new entries in the main document. The contribution process is described in Section 3. 1.1. Scope This document considers in scope scenarios and use cases for which all the following requirements apply: - must be in common use, represent a common practice, a behavior of products in widespread adoption, etc. - can be from any mainstream identity and authorization protocol specification, regardless of standard bodies affiliation: e.g. OAuth, OpenID Connect, SAML, etc. - must require use of browser features (e.g. cookies, redirects, decorated links, HTTP headers, local storage etc) for at least part of its sequence of messages. - can involve, but isn't limited to: establishing a user session, obtaining credentials and intermediate artifacts (e.g. OAuth2 authorization codes). The following is considered out of scope: - any scenario or protocol not currently in mainstream use, regardless of standardization status. - any scenario not using a web broweser in any capacity. - proposing new browser behaviors or API, or identity scenarios using hypothetical new browser capabilities. The goal of this project is to document what's already in place, to inform discussions about what's next taking place in forums shared with the browser vendors. Bertocci & Fletcher Expires 26 July 2021 [Page 3] Internet-Draft browser-use-cases January 2021 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Contribution Process Before submitting feedback and contributions, please familiarize yourself with our current issues list and review the working group home page (https://datatracker.ietf.org/wg/oauth/documents/). If you're new to this, you may also want to read the Tao of the IETF (https://www.ietf.org/tao.html). Be aware that all contributions to the specification fall under the "NOTE WELL" terms outlined here (https://www.ietf.org/about/note- well/). This informational draft is meant to be a living document, where new scenarios and refinement of the current ones will keep being added as needed. This work originated in the IETF working group for OAuth (https://datatracker.ietf.org/wg/oauth/documents/), however we hope to gather contributions from the entire identity community, regardless of affiliation. Most of the work will happen on https://github.com/IDBrowserUseCases/docs (https://github.com/IDBrowserUseCases/docs), a GitHub repository meant to facilitate contributions from the community as summarized below. 3.1. Contributing Scenarios Each scenario is captured in a document following the template described in Section 4. You can find all contributed scenarios in docs/src/scenarios (https://github.com/IDBrowserUseCases/docs/tree/main/src/). If you want to contribute a new scenario: 1. Please read the preamble in this section and ensure that you meet all requirements 2. Verify that your scenario isn't already captured in any of the documents in docs/src/scenarios (https://github.com/IDBrowserUseCases/docs/tree/main/src/scenarios). If it a variant of an already captured scenario, or if you want to contribute to an existing scenario doc, please consider chiming in on the OAuth mailing list (https://www.ietf.org/mailman/listinfo/oauth). 3. If your scenario is new, please fork the repo and create a local copy of SCENARIOTEMPLATE.md, renaming your file to match the format protocolname_protocolscenario.md 4. Edit your local copy by filing Bertocci & Fletcher Expires 26 July 2021 [Page 4] Internet-Draft browser-use-cases January 2021 the appropriate sections of the template, see Section 4 for details. 5. Once you are ready, please submit a PR to add the new doc/reflect doc updates to the scenarios folder 6. Monitor the mailing list (https://www.ietf.org/mailman/listinfo/oauth) for discussions and requests for clarification 3.2. Discussing Scenarios Details and Inclusion All submissions will be discussed on the mailing list (https://www.ietf.org/mailman/listinfo/oauth), possibly undergoing revisions according to the feedback. Once rough consensus is reached, the scenario will be included in this informational document. 4. The Use Case Template We capture all scenarios following a template, with the intent of providing readers with a consistent way of understanding the scenario goals, intended user experience, browser feature dependencies, privacy characteristics and any other consideration that might help assessing impact of browser feature changes on the scenario. Here's a quick description of each template section. For more details, please refer to the scenarios already captured. * Scenario Name Each scenario document opens with a concise description of the scenario. * Contributor This section captures the individual(s) contributing this scenario document and their affiliation. * Protocol If the scenario is part of a standard (e.g. SAML, OpenID Connect, OAuth2, etc), this section provides details such as what standard document it refers to, and any reference that can be useful to learn more about the scenario. Examples include indicating specific use cases described by the standard (grants, flows, etc), links to articles and presentations describing the scenario in more detail and so on. Please note that scenarios captured here do not necessarily need to be formally described in a standard, as long as they are in common use. A good example would be the use of cookies for preserving the nonce in OpenID Connect, or the use of cookies for representing a web app session after a federated sign in flow (regardless of the specific protocol) took place. Bertocci & Fletcher Expires 26 July 2021 [Page 5] Internet-Draft browser-use-cases January 2021 * Browser Features Required This section provides a quick reference of the browser features that play a role in the correct execution of the scenario. Examples include 1st and 3rd party cookies, redirects with link decoration, form posts, access to local storage, iFrames, JavaScript, and so on. * Intended User Experience Description of the intended user experience, with particular attention on the desired outcomes (eg no visible prompt in SSO scenarios) * Description Of The Flow Description of the flow, including entities coming into play, begin state, end state, and sequence diagram when possible. * Privacy Considerations Description of privacy characteristics of the scenario, with particular attention to aspects affecting the browser (eg presence of browser-readable artifacts carrying user info, use of global|pairwise|no identifiers, etc). * Target Audience This section is meant to indicate whether the scenario is used prevalently for a particular audience (eg B2C,B2E, B2B, G2C) or if it can be expected to be relevant for more than one category. * Adoption If known or easy to assess, this session enumerates notable products, industries, vendors that rely on the scenario as described. * Miscellaneous Anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes. 5. Scenarios 5.1. OpenID Connect Redirect Based Sign in via Form POST Web application RP1 offers sign in/sign up functionality for users of identity provider IP1, using OpenID Connect implicit flow and form_post. Ignoring how IP1 auths the user, apart from the fact that successful auth results in a cookie in IP1 domain.. 5.1.1. Summary Bertocci & Fletcher Expires 26 July 2021 [Page 6] Internet-Draft browser-use-cases January 2021 5.1.1.1. Contributor * Name: Vittorio Bertocci * Organization: Auth0 Inc * Email: vittorio@auth0.com 5.1.1.2. Protocol * Name: OpenID Connect * Grant/flow (if applicable): Implicit flow with form post * Reference: see the (OpenID Connect Implicit flow)[https://openid.net/specs/openid-connect-core- 1_0.html#ImplicitFlowAuth (https://openid.net/specs/openid- connect-core-1_0.html#ImplicitFlowAuth)] and (OAuth 2.0 Form Post Response Mode)[https://openid.net/specs/oauth-v2-form-post- response-mode-1_0.html (https://openid.net/specs/oauth-v2-form- post-response-mode-1_0.html)]. 5.1.1.3. Browser Features Required Per legs of the flow: RP1->IP1 - 1st party cookie (RP1 saves nonce) - Redirect - Decorated links - 1st party cookie (IP1 saves its session cookie upon successful authentication) IP1->RP1 - Form post - 1st party cookie (nonce carrying cookie) - Javascript (autopost) 5.1.1.3.1. Target Audience This patters applies to every audience, across the board 5.1.1.4. Adoption TODO Enumeration of products, industries, vendors that rely on this scenario as described. 5.1.2. Description Of The Flow TODO long form description of the flow, including start state, end state, and sequence diagram when possible Bertocci & Fletcher Expires 26 July 2021 [Page 7] Internet-Draft browser-use-cases January 2021 5.1.3. Intended User Experience User navigates to RP1 without any pre existing session in place. Once there, either the user clicks on something (protected route, login button) or the app determines an authentication operation is immediately required. This causes the browser to be redirected to IP1, where the user is presented with authentication prompts (details of the authentication factors/mechanics omitted in this particular scenario). Upon successful authentication, the browser is redirected to RP1, and the user is now signed in RP1. 5.1.4. Privacy Considerations An ID token does transit thru the browser, however 1. It's not meant for the browser. Format might change. It might be encrypted. 2. It might or might not contain profile user attributes 5.1.5. Miscellaneous TODO anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes. 5.2. TODO Scenario Title TODO Brief description of the scenario. This is the template source. 5.2.1. Summary 5.2.1.1. Contributor * Name: TODO * Organization: TODO * Email: TODO 5.2.1.2. Protocol * Name: TODO SAML|OIDC|OAUTH2|Other(specify) * Grant/flow (if applicable): TODO eg. Implicit|Hybrid|AuthCode|SAMLArtifact|etc * Reference: TODO aa https://linktospecandsection (https://linktospecandsection) Bertocci & Fletcher Expires 26 July 2021 [Page 8] Internet-Draft browser-use-cases January 2021 5.2.1.3. Browser Features Required todo: delete all the ones that don't apply, add anything not listed - 1st party Cookie - 3rd party cookies - Redirect with link decoration - Form post - Local Storage - IFrames - JavaScript 5.2.1.3.1. Target Audience todo: delete all the ones that don't apply, add anything not listed - B2C - B2E - B2B - G2C 5.2.1.4. Adoption TODO Enumeration of products, industries, vendors that rely on this scenario as described. 5.2.2. Description Of The Flow TODO long form description of the flow, including start state, end state, and sequence diagram when possible 5.2.3. Intended User Experience TODO long form description of the intended user experience, with particular attention on the desired outcomes (eg no visible prompt in SSO scenarios) 5.2.4. Privacy Considerations TODO long form description of privacy characteristics of the scenario, with particular attention to aspects affecting the browser (eg presence of browser-readable artifacts carrying user info, use of global|pairwise|no identifiers, etc). 5.2.5. Miscellaneous TODO anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes. 6. Acknowledgements 7. IANA Considerations This draft includes no request to IANA. Bertocci & Fletcher Expires 26 July 2021 [Page 9] Internet-Draft browser-use-cases January 2021 8. Security Considerations This document has no security considerations. Readers should refer to the security considerations of the specifications references by each of the individual use cases. 9. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Vittorio Bertocci auth0.com Email: vittorio@auth0.com George Fletcher Verizon Media Email: gffletch@aol.com Bertocci & Fletcher Expires 26 July 2021 [Page 10]