+1, this encapsulation is much cleaner. > On Mar 2, 2020, at 2:25 AM, Filip Skokan <panva...@gmail.com> wrote: > > Perhaps we should consider leaving the root level JWT claims as-is per JWT > and push the introspection response unmodified as if it was regular json > response to a JWT claim called "introspection". Since regular introspection > uses the same claim names as JWT this would get around all the conflicts. > > Last time i brought it up the authors didn't want to consider it because of > existing implementations. > > S pozdravem, > Filip Skokan > > > On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki <t...@authlete.com > <mailto:t...@authlete.com>> wrote: > Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same > concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 > didn't exist then, though. > > Re: [OAUTH-WG] Question regarding > draft-ietf-oauth-jwt-introspection-response-05 > https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/ > <https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/> > > A JWT puts both (a) information about itself and (b) other data in its > payload part. When the "other data" have the same claim names as are used to > express information about the JWT itself, conflicts happen. > > Also, it should be noted that Ben pointed out in other thread that the > requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which > says "jti" is a unique identifier for the access token that MUST be stable > for all introspection calls, contradicts the definition of "jti", which > should be unique for each JWT. > > Re: [OAUTH-WG] Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT) > https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/ > <https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/> > > draft-ietf-oauth-jwt-introspection-response needs to be modified to solve the > conflicts. > > Taka > > On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki <t...@authlete..com > <mailto:t...@authlete.com>> wrote: > Hello, > > I'm wondering if the following conflicts in "JWT Response for OAuth Token > Introspection" (draft 8 > <https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08>) > have already been pointed out. > > RFC 8707 <https://tools.ietf.org/html/rfc8707> (Resource Indicators for OAuth > 2.0) requires that 'aud' in an introspection response hold the values of the > 'resource' request parameters, whereas "JWT Response for OAuth Token > Introspection" says that 'aud' MUST identify the resource server receiving > the token introspection response. The definitions conflict. > > RFC 7662 <https://tools.ietf.org/html/rfc7662> (OAuth 2.0 Token > Introspection) requires that 'iat' in an introspection response indicate when > the access/refresh token was issued, whereas "JWT Response for OAuth Token > Introspection" says that 'iat' indicates when the introspection response in > JWT format was issued. The definitions conflict. > > Best Regards, > Takahiko Kawasaki > Authlete, Inc. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
