[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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]