Hi Remco, > On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius > <remco.sch...@logius.nl> wrote: > > 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.
RFC 7519 and RFC 7662 “just” define different representations for token data. In RFC 7519 the data is carried in the token itself (which also means the format of the token is well-defined and know to the RS) whereas RFC 7662 defines a way to inspect tokens via an API provided by the AS. The latter is typically used in conjunction with opaque tokens, i.e. the RS does not have a clue how to parse and interpret the token. The token might just be a handle to a database entry at the AS in this case. This also means a JWT (RFC 7662) and the Introspection Response are conceptually the same from a RSs perspective. > > 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. It should not. At most the RS must turn up in the list of the legit recipient. At best the aud value is always the RS only (see https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.8.1.3) . > 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. I don’t understand the difference you are making. All before mentioned claims are related to the (abstract) access token. You may think of the Introspection Response as _the_ JWT representation of the access token produced by the AS for the RS. > > 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. Good point. The reason why the BCP recommends explicit typing is to prevent replay in other contexts. In the end typing is a compelling concept unfortunately not broadly used in the wild. So the JWT Introspection Response draft copes with that attack angle by making iss and aud mandatory. > > How would people suggest to best distinguish a JWT (access) token from a JWT > introspection response? Why should you? One reason why we extended the Introspection Response was to eliminate the difference between JWTs directly used as access tokens and Introspection Responses. best regards, Torsten. > > 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. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
