Required requested_token_type parameter

[arndt-s]

Issue to track email sent to the authors

Hello All,
I would like to propose below suggestion for https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining
Section 2.3.1 Token Exchange Request
As per my understanding the Token exchange request in this proposed RFC will always expect JWT token (urn:ietf:params:oauth:token-type:jwt) as clearly mentioned in the ‘section 2.3.4 Example’ with Figure 3: Token exchange response with claim ‘issued_token_type’ and also mentioned in section 2.4.1 Access Token Request (where only JWT token/assertion is sent to Authorization Server in Domain B as Authorization grant) .
Hence my suggestion is to enforce it in the Token exchange request itself (as REQUIRED) parameter by using the ‘requested_token_type’ parameter of OAuth 2.0 Token Exchange RFC 8693 section 2.1 with value ‘urn:ietf:params:oauth:token-type:jwt’ as per section 3 of RFC 8693 (OAuth 2.0 Token Exchange). This could prevent the Authorization server in Domain A to respond with another other type of tokens/assertions (like access_token , refresh_token , id_token , saml1 , saml2 as other possible values as per section 3 of RFC 8693 OAuth 2.0 Token Exchange) by mistake or other reasons, which could break this (draft) specification inadvertently.
Best Regards,
Randip Malakar
STMicroelectronics

[arndt-s]

Thank you for your email Randip!
I agree to talk more about the requested_token_type parameter of the token exchange request. I personally don't see a problem setting it as required, but will my co-authors chime in if they see something I don't.
Regarding the value, yes, "urn:ietf:params:oauth:token-type:jwt" seems the one at hand. Personally, I would also like to discuss to introduce a new type here to be able to differentiate ID chaining from other token exchange use cases on the authorization server. For example something like "urn:ietf:params:oauth:token-type:assertion+jwt"?
What do you think? (@RandiP and co-authors)
-Arndt

[PieterKas]

I think making the requested_token_type REQUIRED makes sense (we already restrict it to JWT in any event).

Although JWT is pretty generic (access and ID tokens can be JWTs as well, but they do have their own identifiers), restricting it further may cause adoption issues for existing token Exchange implementations, who do not support a new type like "urn:ietf:params:oauth:token-type:assertion+jwt".

Looking at section 2 of RFC 7523 (https://datatracker.ietf.org/doc/html/rfc7523#section-2.1), it does define a "urn:ietf:params:oauth:grant-type:jwt-bearer", which we could possibly use.

@bc-pi would love your thoughts on this.

[randipmalakar]

I think making the requested_token_type REQUIRED makes sense (we already restrict it to JWT in any event).

Although JWT is pretty generic (access and ID tokens can be JWTs as well, but they do have their own identifiers), restricting it further may cause adoption issues for existing token Exchange implementations, who do not support a new type like "urn:ietf:params:oauth:token-type:assertion+jwt".

Looking at section 2 of RFC 7523 (https://datatracker.ietf.org/doc/html/rfc7523#section-2.1), it does define a "urn:ietf:params:oauth:grant-type:jwt-bearer", which we could possibly use.

@bc-pi would love your thoughts on this.

Dear @PieterKas Just a feedback on your proposal (unless it's a typo or a copy/paste error), my understanding is that "urn:ietf:params:oauth:grant-type:jwt-bearer" is defined to be used for grant type and in Token exchange request (in the proposed identity-chaining flow) we would use the grant type "urn:ietf:params:oauth:grant-type:token-exchange" and if so, we are left to use "urn:ietf:params:oauth:token-type:jwt" in requested_token_type parameter (unless we define a new token type like "urn:ietf:params:oauth:token-type:assertion+jwt" )

[PieterKas]

Good catch @randipmalakar. I was looking at RFC 7523 to see if a token type was defined there that might be more specific that we can use, but you are right, it's a grant type, not a token type.

Reading a bit on, there is section 8 which defines urn:ietf:params:oauth:client-assertion-type:jwt-bearer - not a token type, but to be used when presenting the assertion https://datatracker.ietf.org/doc/html/rfc7523#section-8.2

So, it may well be that our best option here is urn:ietf:params:oauth:token-type:jwt unless we define a new token type. Immediate pros that come to mind is it would be more specific and less overloaded. The con would be that it is a new token type and would delay or impede adoption. I would like to hear from others on whether urn:ietf:params:oauth:token-type:jwt is a sufficient restriction, or if we need to be more specific.

[bc-pi]

requested_token_type can be used now but making it required is IMHO a non starter