jiebi/TextFlow huggingface dataset:
Original text:
9.6.1. If the client and authorization server are using DPoP binding of <del> access tokens and/or authorization codes, then they SHOULD also require DPoP binding of the "auth_session" value as well. </del>  DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device. <del> This specification defines an additional claim in the DPoP Proof JWT Syntax defined in Section 4.2 of RFC9449: </del> 9.6.2. This specification makes no requirements or assumptions on the

Reviewer comments:
Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good

Revised text:
9.6.1. If the client and authorization server are using DPoP binding of  <ins> access tokens and/or authorization codes, then the "auth_session" value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device.  9.6.2. This specification makes no requirements or assumptions on the
Original text:
IANA has (TBD) registered the following Claims in the "JSON Web Token Claims" registry IANA.JWT established by RFC7519. <del> : "ash" : The base64url-encoded SHA-256 hash of the ASCII encoding of the "auth_session" value : IETF : Section 9.6.1 of this specification </del>

Reviewer comments:
Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good

Revised text:
IANA has (TBD) registered the following Claims in the "JSON Web Token Claims" registry IANA.JWT established by RFC7519.
Original text:
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response.  See auth-session-security for additional security considerations. 6.

Reviewer comments:
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)

Revised text:
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.
Original text:
IANA has (TBD) registered the following Claims in the "JSON Web Token Claims" registry IANA.JWT established by RFC7519. <del> : "ash" : The base64url-encoded SHA-256 hash of the ASCII encoding of the "auth_session" value : IETF : Section 9.6.1 of this specification </del>

Reviewer comments:
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)

Revised text:
IANA has (TBD) registered the following Claims in the "JSON Web Token Claims" registry IANA.JWT established by RFC7519.
Original text:
deployed in a tightly coupled environment since it is only applicable to first-party applications.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Addressing Issue I did not add anything explicit to the Security Considerations section and instead mentioned the potential security exposure in the text on User Experience
First item to add is guidance on limited input devices.
NAME I recall we discussed this, but unable to recall the details of the concern on what guidance we had in mind.
Notes from editor's call: "Not recommended to use this with challenges that require significant user experience challenges, for example entering a password on a TV screen with an on-screen keyboard." Security consideration around the differences between exposure of credentials on a TV screen in a room vs the risk of a cross-device flow We don't want to discourage the possibility of using this flow with a passkey on a TV remote control "If you're on a limited input device, and the authentication method the user must pass requires significant user interaction, e.g. entering a password, then you shouldn't use this method; use the device flow instead."
Completed in

Revised text:
deployed in a tightly coupled environment since it is only applicable to first-party applications. <ins> 1.3. It is important to consider the user experience implications of different authentication challenges as well as the device with which the user is attempting to authorize.  For example, requesting a user to enter a password on a limited input device (e.g.  TV) creates a lot of user friction while also exposing the user's password to anyone else in the room.  On the other hand, using a challenge method that involves say a fingerprint reader on the TV remote allowing for a FIDO2 passkey authentication would be a good experience.  The Authorization Server should consider the user's device when presenting authentication challenges and developers should consider whether the device implementing this specification can provide a good experience for the user.  If the combination of user device and authentiation challenge methods creates a lot of friction or security risk, consider using a specification like OAuth 2.0 Device Authorization Grant RFC8628.  If selecting OAuth 2.0 Device Authorization Grant RFC8628 which uses a cross-device authorization mechanism, please incorporate the security best practices identified in Cross-Device Flows: Security Best Current Practice I-D.ietf-oauth- cross-device-security. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
There are two ways using this specification increases the risk of phishing. <del> With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server.  If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </del>  Because of these risks, the authorization server MAY decide to require that the user go through a redirect-based flow at any stage

Reviewer comments:
Clarifying the text to make it clear that there are two ways in which phishing attacks may be facilitated by this specification. (see issue ) cc NAME
Maybe I misunderstand this section, but it sounds like only one way to do phishing is described, though the section starts by saying "there are two ways."
NAME Thank you for the new text.

Revised text:
There are two ways using this specification increases the risk of phishing.  <ins> Malicious application: With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. User education: In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </ins> Because of these risks, the authorization server MAY decide to require that the user go through a redirect-based flow at any stage
Original text:
defined in Section 5.1 with the additional parameter "auth_session", defined in auth-session. <del> The response MAY include an "auth_session" parameter which the client is expected to include on a subsequent request to the authorization challenge endpoint.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. </del> An example successful token response is below:  6.2. Upon any request to the token endpoint, including a request with a

Reviewer comments:
Sec. 6.1 (in particular the example), what is the meaning of a response with an access token, a refresh token as well as an authsession, what is the client expected to do? How should it use the authsession?
The auth_session should be cached by the client in case it is needed for the stepu-up authentication flow as described in the Appendix (section A.7).

Revised text:
defined in Section 5.1 with the additional parameter "auth_session", defined in auth-session.  An example successful token response is below: <ins> The response MAY include an "auth_session" parameter which the client is expected to include on any subsequent requests to the authorization challenge endpoint, as described in auth-session.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. Including the "auth_session" parameter in the token response enables flows such as step-up authentication RFC9470, so that the authorization server can restore the context of a previous session and prompt only for the needed step-up factors.  See step-up-sms- example for an example application. </ins> 6.2. Upon any request to the token endpoint, including a request with a
Original text:
If the client and authorization server are using DPoP binding of access tokens and/or authorization codes, then the "auth_session" <del> value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </del>  DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by

Reviewer comments:
Clarify that the binding is not done through cryptographic means but rather through association by the authorization server since the binding is only between the client and the authorizations server. See issue cc NAME , NAME
Since RFC 9449 does not specify how "additional" parameters can be bound, please say explicitly that (presumably) this is a claim within the DPoP proof JWT named "auth_session".
It is not a new claim in the DPoP proof, because that would imply the binding happens from the client, not the AS. Brian's suggestion was to require the AS to do the binding, in which case it's internal and not part of the spec.
So can you please fine tune the language in 9.6.1. At least this reader understands the word "binding" when used in this context as cryptographic binding, and this is obviously not what you want. Maybe use "associate" instead.
Fixed by .

Revised text:
If the client and authorization server are using DPoP binding of access tokens and/or authorization codes, then the "auth_session"  <ins> value SHOULD be protected as well.  The authorization server SHOULD associate the "auth_session" value with the DPoP public key.  This removes the need for the authorization server to include additional claims in the DPoP proof, while still benefitting from the assurance that the client presenting the proof has control over the DPoP key. To associate the "auth_session" value with the DPoP public key, the authorization server: MUST check that the same DPoP public key is being used when the client presents the DPoP proof. MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by
Original text:
2.1.  The Identity Chaining flow outlined below describes how these specification are used and work together.  Two examples in the suffix give more concrete examples.  One where a resource server acts as the

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
2.1. <ins> 2.1.1. A US state official in State A needs to access the database of State B to retrieve information about a customer who is a citizen of State B.  The official first gains access to the State A gateway by logging in and authenticating to their local front-end system.  The gateway then passes the official's request and identity to a central information sharing system that all states use to share data. Finally, the central system obtains credentials to access the State B gateway and routes the request from the official, along with the officials identity, to the State B gateway to access the customer's information in the State B database. 2.1.2. A home devices company provides a "Camera API" to enable access to home cameras.  Partner companies use this Camera API to integrate the camera feeds into their security dashboards.  Using 2-legged OAuth between the partner and the Camera API, a partner can request the feed from a home camera to be displayed in their dashboard.  The user has an account with the camera provider.  The user may be logged in to view the partner provided dashboard, or they may authorize emergency access to the camera.  The home devices company must be able to independently verify that the request originated and was authorized by a user who is authorized to view the feed of the requested home camera. 2.1.3. A user attempts to access a service that is implemented as a number of on-prem and cloud-based microservices.  Both the on-premise and cloud-based services are segmented by multiple trust boundaries that span one or more on-premise or cloud service environments.  Every microservice can apply an authorization policy that takes the context of the original user, as well as intermediary microservices into account, irrespective of where the microservices are running and even when a microservice in one trust domain calls another service in another trust domain. 2.1.4. A client requests a report from a "local" resource that incorporates data from one or more associated sources.  Each source is in a separate trust domain.  Trust domains have a federated identity framework (e.g.  PKI) and authorization framework, but may have varied and asymmetric specific trust relationships (e.g. transitive trust is not guaranteed).  Trust relationships are established between authorization servers in each trust domain, and exercised through messages passed between the authorization servers that assert identity and authorization claims.  The identity of requesters is chained throughout, but authorization claims are limited to what is necessary to each request. 2.2. </ins> The Identity Chaining flow outlined below describes how these specification are used and work together.  Two examples in the suffix give more concrete examples.  One where a resource server acts as the
Original text:
(F) The client now possesses an access token to access the protected resource in Domain B. <del> 2.2. </del>  This specification does not define authorization server discovery.  A client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. <del> 2.3. </del>  Once the authorization server is identified the client performs token exchange as defined in RFC8693 with its own authorization server in order to obtain an authorization grant as specified in section 1.3 of RFC6749. <del> 2.3.1. </del>  The parameters described in section 2.1 of RFC8693 apply here with the following restrictions: <del> 2.3.2. </del>  An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
(F) The client now possesses an access token to access the protected resource in Domain B.  <ins> 2.3. </ins> This specification does not define authorization server discovery.  A client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server.  <ins> 2.4. </ins> Once the authorization server is identified the client performs token exchange as defined in RFC8693 with its own authorization server in order to obtain an authorization grant as specified in section 1.3 of RFC6749.  <ins> 2.4.1. </ins> The parameters described in section 2.1 of RFC8693 apply here with the following restrictions:  <ins> 2.4.2. </ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any