OAuth2 Opaque token [to and from] JWT profiled OAuth2 token

[identitymonk]

As discussed during IETF 120, I had to deal with customers that used Opaque Token on the public leg of the communication (Client to API) while it might be better to possess a JWT profiled token for the transaction on the private leg (API to backend services).

The reverse translation might be interesting for privacy purposes if communications have to cross zone of trusts / realm, as the communication might be a public leg again, which would require a JWT profiled token to be translated into an Opaque Token.

[deansaxe]

Do you have a proposal for how this would work @identitymonk? Is this a token exchange RFC compliant exchange or something we would need to profile for translation?

[identitymonk]

This usage for WIMSE falls into the description of the side note of RFC 8693 section 3 Token Type Identifiers

urn:ietf:params:oauth:token-type:jwt is to indicate specifically that a JWT is being requested or sent (perhaps in a cross-domain use case where the JWT is used as an authorization grant to obtain an access token from a different authorization server as is facilitated by [RFC7523])

Still RFC 8693 fell short of supporting this specific use case as there are no way to signal which issuer is related to the OAuth2 Opaque Token provided or requested to be issued. As WIMSE may have to deal with multiple trust

Therefore a WIMSE profile for translation needs to be written to guide and guardrail its usage.

I will formalize a proposal as part of this issue for this use case.