Original text:
2.5. <del> The client presents the authorization grant it received from the 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 Authentication and Authorization Grants" RFC7521. </del>  2.5.1. <del> 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 RFC7523.  Otherwise, the client SHOULD request an access token using the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the </del>  purpose of this specification the following descriptions apply: The client MAY indicate the audience it is trying to access through

Reviewer comments:
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

Revised text:
2.5.  <ins> 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. </ins> 2.5.1.  <ins> The authorization grant is a JWT bearer token, which the client uses to request an access token as described in the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523.  For the </ins> purpose of this specification the following descriptions apply: The client MAY indicate the audience it is trying to access through