OAuth 2.0 for Browser-Based Applications
draft-ietf-oauth-browser-based-apps-27

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-oauth-browser-based-apps-24
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Discuss

Many thanks to authors and working group for putting this document together.
And thanks to all the reviewers who have provided very good feedback.

### Update RFC 9700

166        Many of these recommendations are derived from the Best Current
167        Practice for OAuth 2.0 Security [RFC9700], as browser-based
168        applications are expected to follow those recommendations as well.
169        This document expands on and further restricts various
170        recommendations given in [RFC9700].

Given the above text which states that it further restricts RFC 9700,
should this document be listed as updating RFC 9700?

UPDATE: based on the conversation of the telechat on 24 April this is no
longer a discuss item. This document does not need to update RFC 9700.

### Consistency of Terms

188        "Browser-based application":  An application that is dynamically
189          downloaded and executed in a web browser, usually written in
190          JavaScript.  Also sometimes referred to as a "single-page
191          application", or "SPA".

This draft introduces the term "Browser-based application" which is used
in some places, but it also uses the term "Javascript application" in
many more places. Here is an example where the two terms are used
together and to mean the same thing (I think).

1436      The token-mediating backend counters the first two attack scenarios
1437      by not exposing the refresh token to the browser-based application.
1438      Even when the attacker gains full control over the JavaScript
1439      application, there are simply no refresh tokens to be stolen.

Is a JavaScript application the same thing as a browser-based application
in this document? I also noticed a few places where the term SPA or single
page application were used. If these are all the same term, can one term
be used instead of many? And if they are separate terms, can their definitions
all be given even if quoting from a reference?

1737      In this scenario, the application sends JavaScript-based requests to
1738      the authorization server and the resource server.  Given the nature

What is a Javascript-based request? Is this a request for data in JSON format
or is it a request being made by code of the JavaScript application (or
browser-based application)?

### BFF as an HTTP Proxy

From the description of the BFF with respect to the browser-based application
and the resource server, it appears to act as an HTTP proxy as defined in
Section 3.7 of RFC 9110. Should this document make note of this
and reference the message forwarding requirements of Section 7.6 in RFC 9110?

[Ballot comment]
Thank you for a solid and well-written document. Definitely a pleasure to read such a thorough analysis.

The document states, "Given the popularity of this scenario, this document uses the term "JavaScript" to refer to all mechanisms that allow code to execute in the application's runtime in the browser. The recommendations and considerations in this document are not exclusively linked to the JavaScript language or its runtime, but also apply to other languages and runtime environments in the browser." I understand the temptation because of how we often speak about browser code, but that seems like a recipe for confusion -- how about not doing that? Use JavaScript when you actually mean JavaScript itself, and use "browser-based apps" when you're more general (which is most of the time).

Please also be consistent in your usage of JavaScript versus JS. We can afford the extra characters unless you're referring to the standard file extension.

Nit:

- Why is "The first part (Section 5.1)" not simply "Section 5.1"? Same with second/5.2.

[Ballot comment]
This was an awesome read of OAUTH browser based issues. Thanks for the extensive analyses and advise listed in the document.

Thanks to Watson Ladd for the SECDIR review.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-oauth-browser-based-apps-24
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Marc Blanchet for the ART review.

### 1.  Introduction

The ordering of the introduction feels a bit awkward, you might consider starting with:

```
This document focuses on JavaScript frontend applications acting as the OAuth client,...
```

Then relate to "OAuth 2.0 for Native Apps" and then end with the comment about OpenID Connect:

```
Such a scenario, (which only uses OAuth 2.0 as the underlying specification of OpenID Connect), is not within scope of this specification.
```

I was not familiar with the term "first-party frontend" before.

Having read the full document, I might try to more clearly distinguish this case from BFF up front.

### Revoking of refresh tokens

```
530   The attack is only stopped when the authorization server refuses a
531   refresh token because it has expired or rotated, or when the refresh
532   token is revoked.  In a typical browser-based OAuth client, it is not
533   uncommon for a refresh token to remain valid for multiple hours, or
534   even days.
```

Given the comments about refresh token reuse, is it common to automatically revoke a refresh token where reuse is detected or attempted?

### Reference for session fixation

```
576   sending requests to backend systems.  Alternatively, the attacker can
577   also abuse their access to the application to launch additional
578   attacks, such as tricking the client into acting on behalf of the
579   attacker using an attack such as session fixation.
```

Consider a reference for session fixation, possibly OWASP.

### confidential client

Consider a reference or definition for "confidential client".

```
861   The main benefit of using a BFF is the BFF's ability to act as a
862   confidential client.  Therefore, the BFF MUST act as a confidential
863   client.  Furthermore, the BFF MUST use the OAuth 2.0 Authorization
864   Code grant as described in Section 2.1.1 of [RFC9700] to initiate a
865   request for an access token.
```

Making it easier to implement this MUST, I'm not sure what is required to act as a confidential client.


### Cookie security, why NOT MUST

```
867 6.1.3.2.  Cookie Security
```

This section contains several SHOULDs and SHOULD NOTs.

While it is nice that the guidance is so compact, it raises the question of why these are not MUSTs, and under which conditions they ought to be required.

Consider providing a reference if the answer lies elsewhere, or a brief comment after the compact list.


## Nits

### refresh tokens and correlation of requests

```
367   reduce the scope and lifetime of the token.  For refresh tokens, the
368   use of refresh token rotation offers a detection and correction
369   mechanism.  Sender-constrained tokens (Section 9.2) offer an
```

A few extra words here, or a pointer might make it clearer what recommendation is being made wrt refresh tokens.

Are you recommending a specific refresh token rotation policy here ?

Later you have:

```
410   is not sufficient to prevent abuse of a refresh token.  An attacker
411   can easily wait until the user closes the application or their
412   browser goes offline before using the latest refresh token, thereby
413   ensuring that the latest refresh token is not reused.
```

Consider forshadowing this comment.


### Confused Deputy

```
921   Site Request Forgery (CSRF) attacks.  A successful CSRF attack could
922   transform the BFF into a confused deputy, allowing the attacker's
923   request to the BFF to trigger outgoing calls to a protected resource
924   on behalf of the user.
```

Consider providing a reference for this term.


### Extracting CryptoKeyPair


```
1851   extractable [CryptoKeyPair] is stored using [W3C.IndexedDB]).  As a
1852   result, the use of DPoP effectively prevents scenarios where the
1853   attacker exfiltrates the application's tokens (See Section 5.1.1 and
1854   Section 5.1.2).
```

IIRC, the non extractable crypto key pair could potentially still be extracted by other processes running on the same machine.
The context makes it clear you are referring to attackers with the ability to execute javascript in the browser, but there are other kinds of attackers.

I see you comment on this later in Section 8.6 & 9.2, consider if you want to make the text here a little more narrowly focused on attackers with XSS capabilities.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-oauth-browser-based-apps-24
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Marc Blanchet for the ART review.

### 1.  Introduction

The ordering of the introduction feels a bit awkward, you also consider starting with:

```
This document focuses on JavaScript frontend applications acting as the OAuth client,...
```

Then relate to "OAuth 2.0 for Native Apps" and then end with the comment about OpenID Connect:

```
Such a scenario, (which only uses OAuth 2.0 as the underlying specification of OpenID Connect), is not within scope of this specification.
```

I was not familiar with the term "first-party frontend" before, consider if this might be made clearer with:

Having read the full document, I might try to more clearly distinguish this case from BFF up front.


### refresh tokens and correlation of requests

```
367   reduce the scope and lifetime of the token.  For refresh tokens, the
368   use of refresh token rotation offers a detection and correction
369   mechanism.  Sender-constrained tokens (Section 9.2) offer an
```

A few extra words here, or a pointer might make it clearer what recommendation is being made wrt refresh tokens.

Are you recommending a specific refresh token rotation policy here ?

Later you have:

```
410   is not sufficient to prevent abuse of a refresh token.  An attacker
411   can easily wait until the user closes the application or their
412   browser goes offline before using the latest refresh token, thereby
413   ensuring that the latest refresh token is not reused.
```

Consider forshadowing this comment.


### Revoking of refresh tokens

```
530   The attack is only stopped when the authorization server refuses a
531   refresh token because it has expired or rotated, or when the refresh
532   token is revoked.  In a typical browser-based OAuth client, it is not
533   uncommon for a refresh token to remain valid for multiple hours, or
534   even days.
```

Given the comments about refresh token reuse, is it common to automatically revoke a refresh token where reuse is detected or attempted?

### Reference for session fixation

```
576   sending requests to backend systems.  Alternatively, the attacker can
577   also abuse their access to the application to launch additional
578   attacks, such as tricking the client into acting on behalf of the
579   attacker using an attack such as session fixation.
```

Consider a reference for session fixation, possibly OWASP.

### confidential client

Consider a reference or definition for "confidential client".

```
861   The main benefit of using a BFF is the BFF's ability to act as a
862   confidential client.  Therefore, the BFF MUST act as a confidential
863   client.  Furthermore, the BFF MUST use the OAuth 2.0 Authorization
864   Code grant as described in Section 2.1.1 of [RFC9700] to initiate a
865   request for an access token.
```

Making it easier to implement this MUST.


### Cookie security, why NOT MUST

```
867 6.1.3.2.  Cookie Security
```

This section contains several SHOULDs and SHOULD NOTs.

While it is nice that the guidance is so compact, it raises the question of why these are not MUSTs, and under which conditions they ought to be required.

Consider providing a reference if the answer lies elsewhere, or a brief comment after the compact list.


### Confused Deputy

```
921   Site Request Forgery (CSRF) attacks.  A successful CSRF attack could
922   transform the BFF into a confused deputy, allowing the attacker's
923   request to the BFF to trigger outgoing calls to a protected resource
924   on behalf of the user.
```

Consider providing a reference for this term.


### Extracting CryptoKeyPair


```
1851   extractable [CryptoKeyPair] is stored using [W3C.IndexedDB]).  As a
1852   result, the use of DPoP effectively prevents scenarios where the
1853   attacker exfiltrates the application's tokens (See Section 5.1.1 and
1854   Section 5.1.2).
```

IIRC, the non extractable crypto key pair could potentially still be extracted by other processes running on the same machine.
The context makes it clear you are referring to attackers with the ability to execute javascript in the browser, but there are other kinds of attackers.

I see you comment on this later in Section 8.6 & 9.2, consider if you want to make the text here a little more narrowly focused on attackers with XSS capabilities.

[Ballot comment]
Thank you to Thomas Fossati for the GENART review.  Per his feedback, has the WG decided on whether to add this document to BCP212?

** Section 6.1.2.4.
  The OAuth flow used by this application architecture can be combined
  with OpenID Connect by including the necessary OpenID Connect scopes
  in the authorization request (C).

Is “OpenID Connect scopes” something can get a reference?

** Section 6.1.3.4.  This section has a number of clauses prescribing behavior with a “SHOULD”, but doesn’t provide much context on when or why this behavior might need to be ignore.

** Section 7.
  As a result, previous recommendations are often no longer recommended
  and proposed solutions often fall short of meeting the expected
  security requirements.

Whose “recommendations” is this referencing?

** Section 7.2.3.4.  Editorial.
  It is relatively common to use third-party scripts in browser-based
  applications, such as analytics tools, crash reporting, and even
  things like a Facebook or Twitter "like" button

Consider if the explicit reference to “Facebook or Twitter” will age well, since “Twitter” doesn’t exist by that name anymore.  Perhaps “social media ‘like’ button” instead?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-oauth-browser-based-apps-24

CC @evyncke

Thank you for the work put into this document. The text is interesting and quite educational. Thanks also for using SVG graphics, so nicer figures!

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Rifaat Shekh-Yusef for the shepherd's write-up including the WG consensus and some justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### As curious as Erik Kline

I am eager to read the authors/WG reply to Erik Kline's comment on section 6.2 as indeed the IP address*ES* can change a lot: multi-interfaces, multiple IPv6 addresses per interface, happy eyeball switching from v4 to v6, ...

### Section 3

`this document uses the term "JavaScript" to refer to all mechanisms ` is rather an abuse of language... Anyway, if I am the only one to complain, then ignore this comment.

### Section 5

While interesting, aren't this section lead paragraphs applicable to any "Javascript" page ?

### Section 6.1

It seems that this section goes in way more details/depth than sections 6.2 and 6.3. Is there a reason for this ? e.g., more complex or more deployed ? (just curious)

### Section 6.1.3.2

Should there be more explanation about __Host ? I.e., w/o referring to the normative reference, it is unclear whether it is the fixed constant string or a FQDN ;-)

[Ballot comment]
# Internet AD comments for draft-ietf-oauth-browser-based-apps-24
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.2.*

* n00b question: does the possibility of a differing apparent source IP
  address for the (D,J) vs F requests imply that any attempt at using the
  source IP address (or range) for some security check cannot (or, indeed,
  MUST NOT) be used?

  Past experience with such tricks showed their limitations when adding
  IPv6 addresses to servers -- clients could connect from IPv4 in one
  request and use IPv6 in a subsequent one.

  Just curious.  Not anything that need be addressed by text here.

## Nits

### S6.1.3.2

* "___Host" vs "__Host"

  (three leading underscores versus two)

[Ballot comment]
Hi Aaron, Philippe, and David,

Thank you for the effort put into this specification.

Thanks to Qin Wu for the opsdir review and to the authors for addressing that review in -23.

I support Andy’s DISCUSS points on (1) the need to better clarify the relationship vs. 9700 and also “BFF as an HTTP Proxy”. Likewise, I strongly support Andy’s comment on “BFF Operational Considerations”.

Please find below some comments, fwiw:

# Which BCP Umbrella?
 
Do we plan to include this document under the BCP 212 or BCP 240 umbrella? Else?

I guess it is natural to list under BCP240 as the document currently says:

“This document expands on and further restricts various
  recommendations given in [RFC9700].”

# Heavy use of field specific concept without introducing them

It was difficult to got through the text as I had check other OAUTH specifications to find and understand some statements and also digest some concepts. The text does not provide pointers to help readers find where to look at. A non-exhaustive list of points that require companion citations are: OAuth 2.0  clients, first-party context, third-party context, resource servers, Implicit flow, public clients, private clients, and so on. Please consider fixing that.

Also, enigmatic statements such as the following are not helpful. Please list these explicitly.

CURRENT:
  In addition to the terms defined in referenced specifications, this
  document uses the following terms:

# Recommendations/Guidance “lost” in the analysis

The document includes implementation guidance but that guidance is lost in the mass of attack analysis. This may be a matter of taste, but I’m afraid that if we want the guidance to be followed, we need an effort to make that guidance easily identified at the first place. Separating (or even offloading) the attack analysis vs actual recommendations would be cleaner.

# Provisioning and management-related matters

CURRENT:
  As stated in Section 10.2 of [RFC6749], the authorization server
  SHOULD NOT process authorization requests automatically without user
  consent or interaction, except when the authorization server can
  assure the the identity of the client application.

Do we have some reco about how we can seek for user consent?

More generally, do we expect any knobs for users to interact with the clients and provide some policies? Maybe the same considerations apply also for native clients? If so, can we say that in the text.

As I’m there, can we have a discussion about how to help with diagnostic/troubleshooting when problems are encountered? For example, are there same (levels of) logs? How these are accessed by each app?

Thank you.

Cheers,
Med

[Ballot comment]
Hi Aaron, Philippe, and David,

Thank you for the effort put into this specification.

Thanks to Qin Wu for the opsdir review and to the authors for addressing that review in -22.

I support Andy’s DISCUSS points on (1) the need to better clarify the relationship vs. 9700 and also “BFF as an HTTP Proxy”. Likewise, I strongly support Andy’s comment on “BFF Operational Considerations”.

Please find below some comments, fwiw:

# Which BCP Umbrella?
 
Do we plan to include this document under the BCP 212 or BCP 240 umbrella? Else?

I guess it is natural to list under BCP240 as the document currently says:

“This document expands on and further restricts various
  recommendations given in [RFC9700].”

# Heavy use of field specific concept without introducing them

It was difficult to got through the text as I had check other OAUTH specifications to find and understand some statements and also digest some concepts. The text does not provide pointers to help readers find where to look at. A non-exhaustive list of points that require companion citations are: OAuth 2.0  clients, first-party context, third-party context, resource servers, Implicit flow, public clients, private clients, and so on. Please consider fixing that.

Also, enigmatic statements such as the following are not helpful. Please list these explicitly.

CURRENT:
  In addition to the terms defined in referenced specifications, this
  document uses the following terms:

# Recommendations/Guidance “lost” in the analysis

The document includes implementation guidance but that guidance is lost in the mass of attack analysis. This may be a matter of taste, but I’m afraid that if we want the guidance to be followed, we need an effort to make that guidance easily identified at the first place. Separating (or even offloading) the attack analysis vs actual recommendations would be cleaner.

# Provisioning and management-related matters

CURRENT:
  As stated in Section 10.2 of [RFC6749], the authorization server
  SHOULD NOT process authorization requests automatically without user
  consent or interaction, except when the authorization server can
  assure the the identity of the client application.

Do we have some reco about how we can seek for user consent?

More generally, do we expect any knobs for users to interact with the clients and provide some policies? Maybe the same considerations apply also for native clients? If so, can we say that in the text.

As I’m there, can we have a discussion about how to help with diagnostic/troubleshooting when problems are encountered? For example, are there same (levels of) logs? How these are accessed by each app?

Thank you.

Cheers,
Med

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-oauth-browser-based-apps-24
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Discuss

Many thanks to authors and working group for putting this document together.
And thanks to all the reviewers who have provided very good feedback.

### Update RFC 9700

166        Many of these recommendations are derived from the Best Current
167        Practice for OAuth 2.0 Security [RFC9700], as browser-based
168        applications are expected to follow those recommendations as well.
169        This document expands on and further restricts various
170        recommendations given in [RFC9700].

Given the above text which states that it further restricts RFC 9700,
should this document be listed as updating RFC 9700?

### Consistency of Terms

188        "Browser-based application":  An application that is dynamically
189          downloaded and executed in a web browser, usually written in
190          JavaScript.  Also sometimes referred to as a "single-page
191          application", or "SPA".

This draft introduces the term "Browser-based application" which is used
in some places, but it also uses the term "Javascript application" in
many more places. Here is an example where the two terms are used
together and to mean the same thing (I think).

1436      The token-mediating backend counters the first two attack scenarios
1437      by not exposing the refresh token to the browser-based application.
1438      Even when the attacker gains full control over the JavaScript
1439      application, there are simply no refresh tokens to be stolen.

Is a JavaScript application the same thing as a browser-based application
in this document? I also noticed a few places where the term SPA or single
page application were used. If these are all the same term, can one term
be used instead of many? And if they are separate terms, can their definitions
all be given even if quoting from a reference?

1737      In this scenario, the application sends JavaScript-based requests to
1738      the authorization server and the resource server.  Given the nature

What is a Javascript-based request? Is this a request for data in JSON format
or is it a request being made by code of the JavaScript application (or
browser-based application)?

### BFF as an HTTP Proxy

From the description of the BFF with respect to the browser-based application
and the resource server, it appears to act as an HTTP proxy as defined in
Section 3.7 of RFC 9110. Should this document make note of this
and reference the message forwarding requirements of Section 7.6 in RFC 9110?

[Ballot comment]
## Comments

### BFF Operational Considerations

As the BFF is forwarding/proxying all requests to the resource server,
I wonder if there are any operational issues to consider. If a resource
server is rate limiting requests based on IP addresses, might it start
blocking requests as it would appear many users are originating from
one or a few sources?


## Nits

### hard drive

905        cookies are never written to the user's hard drive in plaintext

Most users today probably do not use equipment with hard drives.
This is probably better said as "local, persistent storage".

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-oauth-browser-based-apps-22, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for Last Call review by HTTPDIR Completed: Ready with Nits. Reviewer: Martin Thomson. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-02-04):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-oauth-browser-based-apps@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OAuth 2.0 for Browser-Based Applications) to Best Current Practice


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 for Browser-Based
Applications'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification details the threats, attack consequences, security
  considerations and best practices that must be taken into account
  when developing browser-based applications that use OAuth 2.0.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Discussion of this document takes place on the Web Authorization
  Protocol Working Group mailing list (oauth@ietf.org), which is
  archived at https://mailarchive.ietf.org/arch/browse/oauth/.

  Source for this draft and an issue tracker can be found at
  https://github.com/oauth-wg/oauth-browser-based-apps.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  Yes, there was a strong support for this document from the WG.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  I would not call it a controversy, but at some point, there was some lively
  discussions on the best way to protect tokens in browsers, with different
  people offering different perspectives. All these perspectives were captured
  in the document with their pros and cons.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not applicable. This is a BCP document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  Philippe De Ryck, a web security expert, reviewed the document and provided
  lots of great feedback. He later joined as a co-author for this document
  and significantly improved the quality of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No applicable.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No applicable.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  No applicable.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is well written and covers a number of patterns used in
  the industry with their pros and cons.

  I raised a number of issues during the review of v19 and v20 of this document,
  which were addressed in v20 and v21 versions of the document.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No applicable, since this is a BCP which does not introduce any new concepts.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The requested RFC type is BCP. This document does not define any new
    mechanism. It describes existing mechanisms and their pros and cons.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Aaron
    https://mailarchive.ietf.org/arch/msg/oauth/yXnZdfC75T6FOqvWvOcWUJyr2uk/

    Philippe
    https://mailarchive.ietf.org/arch/msg/oauth/i7M9uy5QSLNIlTvHprmz05b-oJE/

    David
    https://mailarchive.ietf.org/arch/msg/oauth/HJYd85u6HZAaSPAx2aU40Zmk508/   


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I raised few nits during my review of v19 which were addressed in v20.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    These were addressed in v21 version of the document


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    No such references.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No chage of status of any existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    Not applicable.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    Not applicable.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  Yes, there was a strong support for this document from the WG.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  I would not call it a controversy, but at some point, there was some lively
  discussions on the best way to protect tokens in browsers, with different
  people offering different perspectives. All these perspectives were captured
  in the document with their pros and cons.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not applicable. This is a BCP document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  Philippe De Ryck, a web security expert, reviewed the document and provided
  lots of great feedback. He later joined as a co-author for this document
  and significantly improved the quality of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No applicable.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No applicable.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  No applicable.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is well written and covers a number of patterns used in
  the industry with their pros and cons.

  I raised a number of issues during the review of v19 and v20 of this document,
  which were addressed in v20 and v21 versions of the document.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No applicable, since this is a BCP which does not introduce any new concepts.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The requested RFC type is BCP. This document does not define any new
    mechanism. It describes existing mechanisms and their pros and cons.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Aaron
    https://mailarchive.ietf.org/arch/msg/oauth/yXnZdfC75T6FOqvWvOcWUJyr2uk/

    Philippe
    https://mailarchive.ietf.org/arch/msg/oauth/i7M9uy5QSLNIlTvHprmz05b-oJE/

    David
    https://mailarchive.ietf.org/arch/msg/oauth/HJYd85u6HZAaSPAx2aU40Zmk508/   


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I raised few nits during my review of v19 which were addressed in v20.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    These were addressed in v21 version of the document


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    No such references.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No chage of status of any existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    Not applicable.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    Not applicable.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/