| Internet-Draft | 1176 |browser-use-cases | 1177 |January 2021 | 1178 |
| Bertocci & Fletcher | 1181 |Expires 26 July 2021 | 1182 |[Page] | 1183 |
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. 1217 | 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. 1218 | 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.¶
1219 |1226 | This Internet-Draft is submitted in full conformance with the 1227 | provisions of BCP 78 and BCP 79.¶
1228 |1229 | Internet-Drafts are working documents of the Internet Engineering Task 1230 | Force (IETF). Note that other groups may also distribute working 1231 | documents as Internet-Drafts. The list of current Internet-Drafts is 1232 | at https://datatracker.ietf.org/drafts/current/.¶
1233 |1234 | Internet-Drafts are draft documents valid for a maximum of six months 1235 | and may be updated, replaced, or obsoleted by other documents at any 1236 | time. It is inappropriate to use Internet-Drafts as reference 1237 | material or to cite them other than as "work in progress."¶
1238 |1239 | This Internet-Draft will expire on 26 July 2021.¶
1240 |1248 | Copyright (c) 2021 IETF Trust and the persons identified as the 1249 | document authors. All rights reserved.¶
1250 |1251 | This document is subject to BCP 78 and the IETF Trust's Legal 1252 | Provisions Relating to IETF Documents 1253 | (https://trustee.ietf.org/license-info) in effect on the date of 1254 | publication of this document. Please review these documents 1255 | carefully, as they describe your rights and restrictions with 1256 | respect to this document. Code Components extracted from this 1257 | document must include Simplified BSD License text as described in 1258 | Section 4.e of the Trust Legal Provisions and are provided without 1259 | warranty as described in the Simplified BSD License.¶
1260 |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. 1363 | 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. 1364 | 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 in identity transactions, without relying on the general purpose artifacts on which current identity protocols depend on. 1365 | 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. 1366 | 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. 1367 | 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.¶
1368 |This document considers in scope scenarios and use cases for which all the following requirements apply: 1374 | - must be in common use, represent a common practice, a behavior of products in widespread adoption, etc. 1375 | - can be from any mainstream identity and authorization protocol specification, regardless of standard bodies affiliation: e.g. OAuth, OpenID Connect, SAML, etc. 1376 | - 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. 1377 | - can involve, but isn't limited to: establishing a user session, obtaining credentials and intermediate artifacts (e.g. OAuth2 authorization codes).¶
1378 |The following is considered out of scope: 1379 | - any scenario or protocol not currently in mainstream use, regardless of standardization status. 1380 | - any scenario not using a web broweser in any capacity. 1381 | - 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.¶
1382 |The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 1392 | "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 1393 | document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] 1394 | when, and only when, they appear in all capitals, as shown here.¶
1395 |Before submitting feedback and contributions, please familiarize yourself with our current issues list and review the working 1403 | group home page. If you're 1404 | new to this, you may also want to read the Tao of the 1405 | IETF.¶
1406 |Be aware that all contributions to the specification fall under the "NOTE WELL" 1407 | terms outlined here.¶
1408 |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. 1409 | This work originated in the IETF working group for OAuth, however we hope to gather contributions from the entire identity community, regardless of affiliation. 1410 | Most of the work will happen on https://github.com/IDBrowserUseCases/docs, a GitHub repository meant to facilitate contributions from the community as summarized below.¶
1411 |Each scenario is captured in a document following the template described in Section 4. 1417 | You can find all contributed scenarios in docs/src/scenarios. 1418 | If you want to contribute a new scenario: 1419 | 1. Please read the preamble in this section and ensure that you meet all requirements 1420 | 2. Verify that your scenario isn't already captured in any of the documents in docs/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. 1421 | 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 1422 | 4. Edit your local copy by filing the appropriate sections of the template, see Section 4 for details. 1423 | 5. Once you are ready, please submit a PR to add the new doc/reflect doc updates to the scenarios folder 1424 | 6. Monitor the mailing list for discussions and requests for clarification¶
1425 |All submissions will be discussed on the mailing list, possibly undergoing revisions according to the feedback. Once rough consensus is reached, the scenario will be included in this informational document.¶
1433 |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. 1443 | Here's a quick description of each template section. For more details, please refer to the scenarios already captured.¶
1444 |Scenario Name
1447 | Each scenario document opens with a concise description of the scenario.¶
Contributor
1451 | This section captures the individual(s) contributing this scenario document and their affiliation.¶
Protocol
1455 | 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.
1456 | 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.¶
Browser Features Required
1460 | This section provides a quick reference of the browser features that play a role in the correct execution of the scenario.
1461 | 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
1465 | Description of the intended user experience, with particular attention on the desired outcomes (eg no visible prompt in SSO scenarios)¶
Description Of The Flow
1469 | Description of the flow, including entities coming into play, begin state, end state, and sequence diagram when possible.¶
Privacy Considerations
1473 | 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
1477 | 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
1481 | If known or easy to assess, this session enumerates notable products, industries, vendors that rely on the scenario as described.¶
Miscellaneous
1485 | Anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes.¶
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..¶
1501 |Name: OpenID Connect¶
1532 |Grant/flow (if applicable): Implicit flow with form post¶
1535 |Reference: see the (OpenID Connect Implicit flow)[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].¶
1538 |Per legs of the flow:
1548 | RP1->IP1
1549 | - 1st party cookie (RP1 saves nonce)
1550 | - Redirect
1551 | - Decorated links
1552 | - 1st party cookie (IP1 saves its session cookie upon successful authentication)
1553 | IP1->RP1
1554 | - Form post
1555 | - 1st party cookie (nonce carrying cookie)
1556 | - Javascript (autopost)¶
This patters applies to every audience, across the board¶
1563 |TODO long form description of the flow, including start state, end state, and sequence diagram when possible¶
1583 |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.¶
1591 |An ID token does transit thru the browser, however 1599 | 1. It's not meant for the browser. Format might change. It might be encrypted. 1600 | 2. It might or might not contain profile user attributes¶
1601 |TODO anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes.¶
1609 |TODO Brief description of the scenario. This is the template source.¶
1619 |Name: TODO SAML|OIDC|OAUTH2|Other(specify)¶
1650 |Grant/flow (if applicable): TODO eg. Implicit|Hybrid|AuthCode|SAMLArtifact|etc¶
1653 |Reference: TODO aa https://linktospecandsection¶
1656 |todo: delete all the ones that don't apply, add anything not listed 1666 | - 1st party Cookie 1667 | - 3rd party cookies 1668 | - Redirect with link decoration 1669 | - Form post 1670 | - Local Storage 1671 | - IFrames 1672 | - JavaScript¶
1673 |todo: delete all the ones that don't apply, add anything not listed 1679 | - B2C 1680 | - B2E 1681 | - B2B 1682 | - G2C¶
1683 |TODO long form description of the flow, including start state, end state, and sequence diagram when possible¶
1703 |TODO long form description of the intended user experience, with particular attention on the desired outcomes (eg no visible prompt in SSO scenarios)¶
1711 |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).¶
1719 |TODO anything not fitting any of the sections above that is relevant for understanding how the scenario might be affected by browser changes.¶
1727 |This draft includes no request to IANA.¶
1746 |This document has no security considerations. Readers should refer to the security considerations of the specifications references by each of the individual use cases.¶
1754 |