jiebi/CodeConvo huggingface dataset:
Code change:
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)

Related discussion:
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>
Code change:
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

Related discussion:
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",
Code change:
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.

Related discussion:
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> <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
Code change:
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).

Related discussion:
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: <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
Code change:
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 .

Related discussion:
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> <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
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
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
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: (F) The client now possesses an access token to access the protected resource in Domain B. <del> 2.2. </del> <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. <del> 2.3. </del> <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. <del> 2.3.1. </del> <ins> 2.4.1. </ins> The parameters described in section 2.1 of RFC8693 apply here with the following restrictions: <del> 2.3.2. </del> <ins> 2.4.2. </ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.3. </del> <ins> 2.4.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: "urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.4. </del> <ins> 2.4.4. </ins> Authorization servers MAY choose to:
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.5. </del> <ins> 2.4.5. </ins> All of section 2.2 of RFC8693 applies.  In addition, the following applies to specification that conform to this specification.
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.6. </del> <ins> 2.4.6. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). <del> 2.4. </del> <ins> 2.5. </ins> The client uses the received authorization grant from steps B and C as an asseration towards authorization server of domain B. <del> 2.4.1. </del> <ins> 2.5.1. </ins> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: The client MAY indicate the audience it is trying to access through the "scope" parameter or the "resource" parameter defined in RFC8707. <del> 2.4.2. </del> <ins> 2.5.2. </ins> All of RFC7521 (Section 5.2 in specific) applies.  In context of this specification the following rules apply in addition:
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed) <del> 2.4.3. </del> <ins> 2.5.3. </ins> The authorization server MAY leverage claims from the present authorization grant for claim population of the access token.  The
Code change:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Related discussion:
text: The specifics (such as the format) of returned access token is not part of this specification. <del> 2.4.4. </del> <ins> 2.5.4. </ins> The authorization server responds with an access token as described in section 5.1 of RFC6749. <del> 2.4.5. </del> <ins> 2.5.5. </ins> The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B
Code change:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Related discussion:
text: 2.3.2. <del> Either one of resource or audience is required to indicate for what authorization server the authorization grant should be audienced. The authorization server MUST deny the request if neither is set.  An authorization server SHOULD deny the request on an unknown resource/ audience.  In cases where federation to any authorization server is deliberate unknown resource or scope identifiers MAY be allowed. 2.3.3. </del> <ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any authorization server is deliberate unknown resource or audience identifiers MAY be allowed. </ins> The authorization server MAY deny the request due to policy.  For instance if federation to the requested domain/authorization
Code change:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Related discussion:
text: The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.4. </del> <ins> 2.3.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and
Code change:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Related discussion:
text: "urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.5. </del> <ins> 2.3.4. </ins> Authorization servers MAY choose to:
Code change:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Related discussion:
text: verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.6. </del> <ins> 2.3.5. </ins> All of section 2.2 of RFC8693 applies.  In context of this specification the following applies in addtion:
Code change:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Related discussion:
text: only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.7. </del> <ins> 2.3.6. </ins> The example belows shows a command the client invokes to perform token exchange at authorization server of domain A (https://a.org/
Code change:
Added a section in the security considerations to address topic raised by
Comment from Kelly: A.2.(D) I think AS in domain A at least SHOULD authenticate to AS in domain B. We have it as a MUST.
Perhaps this can be done in the security considerations.

Related discussion:
text: 4. <del> To be added. </del> <ins> 4.1. Authorization Servers SHOULD follow the OAuth 2.0 Security Best Current Practice OAUTH2-BCP for client authentication. </ins> 5.  References