Subject: Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 2 Mar 2020 15:52:41 +0900

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-masked]> 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.
>
>
>
>

---

From: Filip Skokan <[email-masked]>
Date: Mon, 2 Mar 2020 08:25:22 +0100

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-masked]> wrote:

> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki <taka@authlete..com
> <[email-masked]>> wrote:
>
>> Hello,
>>
>> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 2 Mar 2020 14:54:26 +0100

Hi Taka, 

> On 1. Mar 2020, at 08:10, Takahiko Kawasaki <[email-masked]> 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 8707 states 

The authorization server may use
   the exact "resource" value as the audience or it may map from that
   value to a more general URI or abstract identifier for the given
   resource.

draft-ietf-oauth-jwt-introspection-response-08 states

The value of the "aud" claims MUST identify the resource server
   receiving the token introspection response.

So RFC 8707 gives choices of how the resource server might be identified and draft-ietf-oauth-jwt-introspection-response-08 says the AS must identify the RS without prescribing any particular way. So basically you can use the advice given by  RFC 8707 to implement the requirement stated by draft-ietf-oauth-jwt-introspection-response-08.

I don’t see a 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.

I will come back to this issue in an answer to Filip’s post.

best regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 2 Mar 2020 15:04:51 +0100

Hi Filip, Hi Taka,

iat: We might add a structure (e.g. "underlying_access_token") to be able to convey “iat" for both the underlying access token as well as the JWT-formatted introspection response to the RS. I’m not really convinced we need to add this additional complexity since, in my experience, applications use “exp” for validity checks. I consequently would argue that overloading “iat” for the AS attesting the instant when it created the JWT formatted introspection response is acceptable. No strong argument, just an explanation, why we didn't change it so far.

jti: This is getting more difficult for the “jti”. If the “jti” of the JWT-formatted introspection response is in the root level, and the “jti" of the underlying access token goes into a container, the RS developer need to dig into this container to implement replay detection with respect to the underlying access tokens. 

I’m concerned RS developers will just use the top level “jti" for replay detection, which does not make any sense as this “jti" is freshly assigned with every introspection response. 

I look forward to getting your advice. 

best regards,
Torsten. 

> On 2. Mar 2020, at 08:25, Filip Skokan <[email-masked]> 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
> 
> 
> 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
> 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)
> 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 <taka@authlete..com> wrote:
> Hello,
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 3 Mar 2020 01:31:45 +0900

Hi Torsten,

For example, if an authorization request includes two "resource" request
parameters like below,

resource=https://host1.example.com/resource1
resource=https://host2.example.com/resource2

RFC 8707 expects that the value of "aud" in an introspection response look
like the following.

"aud" : [
  "https://host1.example.com/resource1",
  "https://host2.example.com/resource2",
]

How does the implementation of the introspection endpoint insert the
identifier of the resource server (the API caller?) into the "aud" array
above? In other words, what is the expected resultant value of the "aud"
array in this case?

Taka

On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt <[email-masked]>
wrote:

> > 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 8707 states
>
> So RFC 8707 gives choices of how the resource server might be identified
> and draft-ietf-oauth-jwt-introspection-response-08 says the AS must
> identify the RS without prescribing any particular way. So basically you
> can use the advice given by  RFC 8707 to implement the requirement stated
> by draft-ietf-oauth-jwt-introspection-response-08.
>
> I don’t see a 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.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 2 Mar 2020 17:43:57 +0100

Hi Taka,

I see, the audience is multi value. In my impression both specs assume a single value audience. 

But I think we can handle this as follows: Since the caller of the introspection respect is a single RS, the AS first needs to map & check the resources associated with the underlying access token against that caller. The RS is authenticated at the introspection endpoint using a client_id (and some credential), so the AS needs to map the client_id to resource identifier. If the result is in the set of the resources associated with the underlying access token, the AS can create an Introspection Response, which only contains this particular resource. 

What do you think?

best regards,
Torsten. 

> On 2. Mar 2020, at 17:31, Takahiko Kawasaki <[email-masked]> wrote:
> 
> Hi Torsten,
> 
> For example, if an authorization request includes two "resource" request parameters like below,
> 
> RFC 8707 expects that the value of "aud" in an introspection response look like the following.
> 
> "aud" : [
> How does the implementation of the introspection endpoint insert the identifier of the resource server (the API caller?) into the "aud" array above? In other words, what is the expected resultant value of the "aud" array in this case?
> 
> Taka
> 
> 
> On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt <[email-masked]> wrote:
> Hi Taka, 
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 3 Mar 2020 02:27:36 +0900

>From RFC 7662, Section 2.1

*To prevent token scanning attacks, the endpoint MUST also require some
form of authorization to access this endpoint, such as client
authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0
access token such as the bearer token described in OAuth 2.0 Bearer Token
Usage [RFC6750].  The methods of managing and validating these
authentication credentials are out of scope of this specification.*

"Some form of authorization" may not be able to distinguish API callers.
For example, if one pair of API key and API secret is shared by multiple
resource servers.

Even if the number of "resource" request parameters is one, its value is
not necessarily the identifier of a resource server. What if "
https://rs.example.com/resource1" is given as "resource"? Which value
should "aud" hold, "https://rs.example.com/resource1" or "
https://rs.example.com"?

If the format of access tokens is JWT, when an authorization request
includes "resource=https://host1.example.com/resource1" and "resource=
https://host2.example.com/resource2", the resultant access token will have
"aud" like below.

"aud" : [
  "https://host1.example.com/resource1",
  "https://host2.example.com/resource2"
]

However, if your logic applies, the introspection response for the access
token will include a different value for "aud". This behavior is confusing.
Because "some form of authorization" is performed when an introspection
call is made, I don't think it's necessary to modify the value of "aud" per
API caller.

Anyway, the root cause is that (a) "aud" in RFC 8707 and (b) "aud"
in draft-ietf-oauth-jwt-introspection-response (in general "aud" in JWT)
are different concepts but they share the same name. Any workaround without
solving the root cause will bring about unhappy future.

Taka

On Tue, Mar 3, 2020 at 1:44 AM Torsten Lodderstedt <[email-masked]>
wrote:

> But I think we can handle this as follows: Since the caller of the
> introspection respect is a single RS, the AS first needs to map & check the
> resources associated with the underlying access token against that caller.
> The RS is authenticated at the introspection endpoint using a client_id
> (and some credential), so the AS needs to map the client_id to resource
> identifier. If the result is in the set of the resources associated with
> the underlying access token, the AS can create an Introspection Response,
> which only contains this particular resource.
>
> What do you think?
>
> best regards,
> Torsten.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 2 Mar 2020 18:42:15 +0100

> On 2. Mar 2020, at 18:27, Takahiko Kawasaki <[email-masked]> wrote:
> 
> To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750].  The methods of managing and validating these authentication credentials are out of scope of this specification.
> 
> "Some form of authorization" may not be able to distinguish API callers. For example, if one pair of API key and API secret is shared by multiple resource servers.

Good point. If the AS would not authenticate the RS, it would need to put the whole aud array into the introspection response. 

However, draft-ietf-oauth-jwt-introspection-response states 

 In order to process the introspection requests in a secure and
   privacy-preserving manner, the authorization server MUST be able to
   identify, authenticate and authorize resource servers.

So this draft is more restrictive regarding RS authentication, mainly because of WG and IESG feedback.

> 
> Even if the number of "resource" request parameters is one, its value is not necessarily the identifier of a resource server. What if "https://rs.example.com/resource1" is given as "resource"? Which value should "aud" hold, "https://rs.example.com/resource1" or "https://rs.example.com"?
> 
> If the format of access tokens is JWT, when an authorization request includes "resource=https://host1.example.com/resource1" and "resource=https://host2.example.com/resource2", the resultant access token will have "aud" like below.
> 
> "aud" : [
> However, if your logic applies, the introspection response for the access token will include a different value for "aud". This behavior is confusing.

That’s completely inline with RFC 8707 that states 

"The authorization server may use the exact "resource" value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource.”

Mapping a client_id to a resource identifier (or vise versa) is just that “a mapping”.

> Because "some form of authorization" is performed when an introspection call is made, I don't think it's necessary to modify the value of "aud" per API caller.

Not necessarily but possible. I find it reasonable to have an external identifier for a RS (the value used for the resource parameter) and to have internal identifier used to identify & authenticate the RS (e.g. the client_id). 

> 
> Anyway, the root cause is that (a) "aud" in RFC 8707 and (b) "aud" in draft-ietf-oauth-jwt-introspection-response (in general "aud" in JWT) are different concepts but they share the same name. Any workaround without solving the root cause will bring about unhappy future.

My proposal is not a workaround but the logic an AS could apply that fits with RFC 8707 as well as draft-ietf-oauth-jwt-introspection-response.

best regards,
Torsten. 

> 
> Taka
> 
> 
> On Tue, Mar 3, 2020 at 1:44 AM Torsten Lodderstedt <[email-masked]> wrote:
> Hi Taka,
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 10:37:52 -0500

+1, this encapsulation is much cleaner.

> On Mar 2, 2020, at 2:25 AM, Filip Skokan <[email-masked]> wrote:
> 
> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki <[email-masked] <mailto:[email-masked]>> wrote:
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/ <https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/>
> 
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/ <https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/>
> 
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki <taka@authlete..com <mailto:[email-masked]>> 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.
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Mar 2020 17:19:13 +0100

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-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 11:28:56 -0500

Why the leading underscore in the name? Why not just “token_data”?

 — Justin

> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all, 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Mar 2020 17:49:46 +0100

no particular reason, just indicating special meaning. I can live without it.

> Am 04.03.2020 um 17:29 schrieb Justin Richer <[email-masked]>:
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 12:22:19 -0500

Gotcha, thanks. I’d prefer without it, I don’t think the meaning is any more “special” than another container field would be. I like this kind of encapsulation, though.

And to be honest, I wish we’d done that structure with dynamic registration as well. A software statement runs into similar issues but we got lucky that there weren’t the same kind of conflicts that we see here.

 — Justin

> On Mar 4, 2020, at 11:49 AM, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: Filip Skokan <[email-masked]>
Date: Wed, 4 Mar 2020 19:15:17 +0100

Torsten, let's make sure we call out the required top level JWT claims -
iss, iat, aud, what else? is top level iat required as well?

S pozdravem,
*Filip Skokan*

On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt <[email-masked]>
wrote:

> Hi all,
>
> based on the recent feedback, Vladimir and I propose the following changes
> to draft-ietf-oauth-jwt-introspection-response:
>
> - 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
>
> >> 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.
> >>
> >> Re: [OAUTH-WG] Question regarding
> draft-ietf-oauth-jwt-introspection-response-05
> >>
> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> >>

---

From: Filip Skokan <[email-masked]>
Date: Wed, 4 Mar 2020 19:17:40 +0100

Sorry, i meant - is top level jti required as well?

S pozdravem,
*Filip Skokan*

On Wed, 4 Mar 2020 at 19:15, Filip Skokan <[email-masked]> wrote:

>> based on the recent feedback, Vladimir and I propose the following
>> changes to draft-ietf-oauth-jwt-introspection-response:
>>
>> >> 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.
>> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Mar 2020 19:28:50 +0100

> Am 04.03.2020 um 19:18 schrieb Filip Skokan <[email-masked]>:
> 
> 

I don’t see any use case for it, but that might be due to lack of creativity :-)

>> Torsten, let's make sure we call out the required top level JWT claims - iss, iat, aud, what else? is top level iat required as well?
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>>> On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt <[email-masked]> wrote:
>>> Hi all, 
>>>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Sat, 7 Mar 2020 10:33:02 +0900

Regarding the name of the JSON property in the payload of the introspection
response JWT.

If we choose a more generic name (e.g. "content") than "token_data", the
approach discussed here can be used as a generic way to wrap a JSON
response in JWT. If we are ambitious, we can even add "content_type".

Example 1:
{
  "iss": "...",
  "content_type": "application/json",
  "content": {
    "key0": "value0",
    "key1": "value1"
  }
}

Example 2:
{
  "iss": "...",
  "content_type": "application/x-www-form-urlencoded",
  "content": "key0=value0&key1=value1"
}

Taka

On Thu, Mar 5, 2020 at 3:28 AM Torsten Lodderstedt <[email-masked]>
wrote:

>>> - 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
>>>
>>> >> 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
>>> >> 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.
>>> >>
>>> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in
>>> an introspection response hold the values of the 'resource' request

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 7 Mar 2020 15:39:15 +0200

Hi Taka,

I like the idea. I suppose there are tonnes of use cases where some data
needs to be embedded into a JWT claims set, which could benefit from
having its own container and content type, instead of doing what tried
at first. I suppose this could merit a spec of its own (?). For the JWT
introspection response I find this outside the spec scope. In a
conversion with Torsten we settled on the "token_introspection" name for
the container, to make it consistent with the content type
(application/token-introspection+jwt) and the JWT "typ" header
(token-introspection+jwt).

The JWT claim will also need to be registered with
https://www.iana.org/assignments/jwt/jwt.xhtml , so the name also better
be self-evident and avoid potential conflicts with future specs.

Vladimir

On 07/03/2020 03:33, Takahiko Kawasaki wrote:
> Regarding the name of the JSON property in the payload of the
> introspection response JWT.
>
> If we choose a more generic name (e.g. "content") than "token_data",
> the approach discussed here can be used as a generic way to wrap a
> JSON response in JWT. If we are ambitious, we can even add "content_type".
>
> Example 1:
> {
>   "iss": "...",
> On Thu, Mar 5, 2020 at 3:28 AM Torsten Lodderstedt
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>>     Am 04.03.2020 um 19:18 schrieb Filip Skokan <[email-masked]
>>     <mailto:[email-masked]>>:
>>
>>     
>>     On Wed, 4 Mar 2020 at 19:15, Filip Skokan <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Torsten, let's make sure we call out the required top level
>>         JWT claims - iss, iat, aud, what else? is top level iat
>>         required as well?
>>
>>         S pozdravem,
>>         *Filip Skokan*
>>
>>
>>         On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             Hi all,
>>
>>             based on the recent feedback, Vladimir and I propose the
>>             following changes to
>>             draft-ietf-oauth-jwt-introspection-response:
>>
>>             - 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
>>
>>             > On 4. Mar 2020, at 16:37, Justin Richer
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>             >
>>             >> On Mar 2, 2020, at 2:25 AM, Filip Skokan
>>             <[email-masked] <mailto:[email-masked]>> 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
>>             >> 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-masked] <mailto:[email-masked]>> 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.
>>             >>
>>             >> 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.
>>             >>
>>             >> 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.
>>             >>
>>             >>
>>             >>
-- 
Vladimir Dzhuvinov

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 8 Mar 2020 20:12:23 -0700

Hi Torsten,

Sorry for the delayed response, but since I was explicitly listed in the
"To:" field I expect the response is still of interest.
> - 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

I think this sort of thing will resolve the fundamental issues quite well.
(I want to say I had listed it as a potential option some months ago, but
don't have the time to go look in the archives and check.)

I see there's still some discussion ongoing about specifics, which is fine;
I expect we will still end up in a good place.

-Ben