jiebi/CodeConvo huggingface dataset:
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: 2.2. <del> The Identity Chaining flow outlined below describes how these specifications are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used when the resource server acts as the client an another that describes what happens when the authorization server acts as the client. </del> <ins> The Identity Chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client. </ins> The flow illustrated in Figure 1 shows the steps the client in trust <del> domain A needs to perform to access a protected resource in trust </del> <ins> Domain A needs to perform to access a protected resource in trust </ins> domain B.  In this flow, the client has a way to discover the <del> authroization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g. through federation).  It includes the following: </del> <ins> authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation).  It includes the following: </ins> (A) The client of Domain A needs to discover the authorization server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of its own domain (Domain A) for an authorization grant that can be <del> used with the authorization server in Domain B.  See token- exchange. </del> <ins> used at the authorization server in Domain B.  See token-exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with Domain B.  This requires a trust relationship between Domain A and Domain B (e.g. through federation). </del> <ins> returns an authorization grant that the client can use with the authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation). </ins> (D) The client presents the authorization grant to the <del> authorization server of Domain B.  See present-authorization- grant. </del> <ins> authorization server of Domain B.  See authorization-grant. </ins> (E) Authorization server of Domain B validates the authorization grant and returns an access token.
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: 2.3. This specification does not define authorization server discovery.  A <del> 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> <ins> client MAY contact the resource server 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. The client performs token exchange as defined in RFC8693 with the <del> authorization server for its own domain (e.g.  Domain A), in order to </del> <ins> authorization server for its own domain (e.g., Domain A) in order to </ins> obtain an authorization grant that can be used with the authorization <del> server of a different domain (e.g.  Domain B) as specified in section </del> <ins> server of a different domain (e.g., Domain B) as specified in section </ins> 1.3 of RFC6749. 2.4.1.
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT <del> require a certain format or parse the authorization grant (for instance in caes of JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </del> <ins> require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </ins> Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: 2.4.4. All of section 2.2 of RFC8693 applies.  In addition, the following <del> applies to specification that conform to this specification. </del> <ins> applies to implementations that conform to this specification. </ins> <del> Returned authorization grant MUST be audienced to the requested </del> <ins> Returned authorization grants MUST be audienced to the requested </ins> authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients <del> from presenting their access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> The returned authorization grant MAY be audienced to multiple authorization servers, provided that trust relationships exist with them (e.g. through federation).  It is RECOMMENDED that only one audience is used to prevent an authorization server in one <del> domain from presenting the client's authorization grant to another authorization in another trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </del> <ins> domain from presenting the client's authorization grant to an authorization server in a different trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </ins> 2.4.5.
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client <del> Authentication and Auhorization Grants" RFC7521. </del> <ins> Authentication and Authorization Grants" RFC7521. </ins> 2.5.1.
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: <del> The request MUST be denied presented authorization grant is not audienced to the authorization server that processes the request </del> <ins> The request MUST be denied if the presented authorization grant is not audienced to the authorization server that processes the request </ins> The authorization server SHOULD deny the request if it is not able to identify the subject
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: 2.6. Authorization servers MAY transcribe claims when either producing <del> authorization grant at the token exchange flow or access tokens at </del> <ins> authorization grants in the token exchange flow or access tokens in </ins> the assertion flow. : Subject identifier can differ between the parties involved.  For instance: A user is known at domain A by "johndoe@a.org" but in <del> domain B by "doe.john".  The mapping from one identifier to the other MAY either happen in the token exchange step and updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>
Code change:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Related discussion:
text: : The authorization server performing the assertion flow MAY leverage claims from the presented authorization grant and include <del> it in the access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del> <ins> them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.
Code change:
Removes a duplicated section from the introduction
Feedback from Brian Campbell: Section 2 repeats itself with the text "A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange. The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B. The client in domain A may be a resource server, or it may be the authorization server itself." occurring twice.

Related discussion:
text: authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. <del> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> 2.1.
Code change:
Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc

Related discussion:
text: The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). </del> <ins> domain A (https://as.a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://as.b.org/ auth). </ins> 2.5.
Code change:
Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc

Related discussion:
text: The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B <del> (https://b.org/auth) to receive an access token for a protected </del> <ins> (https://as.b.org/auth) to receive an access token for a protected </ins> resource in trust domain B. 2.6.
Code change:
Fixes RFC7523 reference (was RFC7521)
Feedback from Brian Campbell The reference in the first sentence of [URL] would be 7523 rather than 7521 (I got rather confused reading that paragraph :-) ).

Related discussion:
text: 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 Client Authentication and Authorization Grants" as defined in <del> RFC7521.  Otherwise, the client SHOULD request an access token using </del> <ins> RFC7523.  Otherwise, the client SHOULD request an access token using </ins> the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the purpose of this specification the following descriptions apply:
Code change:
See
Feedback from Brian Campbell This requirement for the audience [URL] is already a requirement of [URL] (3rd bullet) and also [URL] (also 3rd bullet). But the way it's listed here makes it sound like an additional thing. It might be worthwhile to use the bullet here to be more specific about the aud value (it's been a bit of an interop pain point w/ JWT client auth fwiw) and say that it has to be the token endpoint or AS issuer identifier.

Related discussion:
text: 2.5.2. <del> All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: </del> <ins> All of Section 5.2 RFC7521 applies, in addition to the following processing rules: </ins> <del> The request MUST be denied if the presented authorization grant does not include an "aud" claim identifying the authorization server that processes the request. </del> <ins> The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 RFC7523 or the issuer identifier as defined in Section 2 of RFC8414. </ins> The authorization server SHOULD deny the request if it is not able to identify the subject.
Code change:
and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT

Related discussion:
text: presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. <del> 2.4.5. </del> <ins> 2.4.4. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: trust domains. A client in trust domain A that needs to access a resource server in <del> trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> <ins> trust domain B requests a JWT authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </ins> 2.1.
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of <del> its own domain (Domain A) for an authorization grant that can be used at the authorization server in Domain B.  See token-exchange. </del> <ins> its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B.  See token- exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with the </del> <ins> returns a JWT authorization grant that the client can use with the </ins> authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation).
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: (D) The client presents the authorization grant to the authorization server of Domain B.  See access-token-request. <del> (E) Authorization server of Domain B validates the authorization grant and returns an access token. </del> <ins> (E) Authorization server of Domain B validates the JWT authorization grant and returns an access token. </ins> (F) The client now possesses an access token to access the protected resource in Domain B.
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: The client performs token exchange as defined in RFC8693 with the authorization server for its own domain (e.g., Domain A) in order to <del> obtain an authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </del> <ins> obtain a JWT authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </ins> 2.4.1.
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification. <del> The "aud" claim in the returned authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> The "aud" claim in the returned JWT authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> <del> The "aud" claim included in the returned authorization grant MAY identify multiple authorization servers, provided that trust </del> <ins> The "aud" claim included in the returned JWT authorization grant MAY identify multiple authorization servers, provided that trust </ins> relationships exist with them (e.g. through federation).  It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://as.a.org/auth) to receive an authorization grant </del> <ins> domain A (https://as.a.org/auth) to receive a JWT authorization grant </ins> for the authorization server in trust domain B (https://as.b.org/ auth). 2.5. <del> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </del> <ins> The client presents the JWT authorization grant it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1.
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: 2.6. <del> Authorization servers MAY transcribe claims when either producing </del> <ins> Authorization servers MAY transcribe claims when either producing JWT </ins> authorization grants in the token exchange flow or access tokens in the assertion flow.