Hi all, based on the recent feedback, Vladimir and I propose the following changes to draft-ietf-oauth-jwt-introspection-response:
- the token data are encapsulated in a container element “_token_data”
- beyond this, the top-level container only contains meta data pertinent to the
JWT representing the signed (encrypted) introspection response
- we need to add text to the spec to point out that replay detection must be
based on the jti in the “_token_data” container not the top level claim
That’s example of how it would look like:
{
"iss":"https://as.example-bank.com";,
"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
"iat":1532452100,
"_token_data":{
"active":true,
"iss":"https://as.example-bank.com";,
"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
"jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
"iat":1532452084,
"exp":1532453100,
"client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
"cnf":{
"x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
},
"sub":"123456789087632345678"
}
}
The response for inactive tokens would look like this:
{
"iss":"https://as.example-bank.com";,
"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
"iat":1532452100,
"_token_data":{
"active":false
}
}
What do you think?
best regards,
Torsten.
> On 4. Mar 2020, at 16:37, Justin Richer <[email protected]> wrote:
>
> +1, this encapsulation is much cleaner.
>
>> On Mar 2, 2020, at 2:25 AM, Filip Skokan <[email protected]> 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 <[email protected]> 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/
>>
>> 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/
>>
>> 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 <[email protected]> wrote:
>> Hello,
>>
>> I'm wondering if the following conflicts in "JWT Response for OAuth Token
>> Introspection" (draft 8) have already been pointed out.
>>
>> RFC 8707 (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 (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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
