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

Related discussion:
text: 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?