[OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

["Schaar, R.M. (Remco) - Logius" <[e-mail]>]

Hello,

I would like to request the OAuth2 working group on a clarification for introspection, in particular regarding the semantics of the 'jti' and 'aud' claims. The draft 'JWT Response for OAuth Token Introspection' seems ambiguous in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 cause this ambiguity.

RFC7662 specifies the 'aud' and 'jti' parameters in relation to "for the token". Note that the wording in RFC7662 is somewhat implicit, we assume "the token" is the (access) token being introspected.
RFC7519 specifies the 'aud' and 'jti' parameters in relation to the JWT itself. The token in the context of RFC7519 is the JWT containing the parameters.

The draft (draft-ietf-oauth-jwt-introspection-response-05) now formulates the response to an introspection as a JWT. The content of the JWT "MAY furthermore contain all claims defined in RFC7662". Now this raises the question to the meaning of the 'aud' and 'jti' parameters.

In line with RFC7519 the parameters would define a value for the introspection response. On the other hand following RFC7662 for the definition would define the value of the parameters as those of the introspected token.

Now for the 'aud' parameter this will typically only be an issue with multiple values for the audience. In the case of a single intended audience the audience of the introspected (access) token will normally be the same principal as the audience of the introspection response JWT. Only for some use cases the value of 'aud' may end up ambiguous.
The 'jti' parameter however will always be ambiguous. As it is an identifier, it should differ for the introspected token and the introspection response by definition. Hence the semantics of 'jti' in a JWT introspection response is unclear. The same can apply to the 'iat', 'nbf' and 'exp' claims in a JWT introspection response.

Can someone clarify the semantics of claims in an introspection response JWT that are defined in both RFC7662 and RFC7519?

Furthermore, the introspection response should use the 'iss' and 'aud' claims to avoid cross-JWT confusion (section 6.1). The 'iss' and 'aud' of an introspected token will typically be the same as those of the introspection response. Hence a JWT access token cannot be distinguished from an introspection response using 'iss' and 'aud' as suggested in the draft.

Introspection refers to JWT best-current-practice. The draft BCP recommends using explicit typing of JWTs, however the draft JWT response for introspection does not apply this recommendation and uses the generic 'application/jwt' instead... The BCP has other recommendations in section 3.12, but these may be insufficient to distinguish a JWT access token from a JWT introspection response.

How would people suggest to best distinguish a JWT (access) token from a JWT introspection response?

Thank you in advance for your response.

Kind regards,
Remco Schaar
Logius
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.