Subject: Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

From: Mike Jones <[email-masked]>
Date: Wed, 26 Aug 2020 21:12:27 +0000

I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint.  That’s why it’s preferable to not use one at all and instead directly have the Resource understand the Access Token.  One way of doing this is the JWT Access Token spec.  There are plenty of others.

The downsides of using an Introspection Endpoint should be described in the Privacy Considerations section.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=[email-masked]>
Cc: [email-masked]; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]..org>> wrote:
Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <[email-masked]<mailto:denis.ietf@free..fr>> wrote:

> The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don’t think it is an issue per se. Please explain the privacy implications.

As I see it, the privacy implication is that the AS knows when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client.

I think including this implication would be important to have in a Privacy Considerations section.

/Dick
ᐧ

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 27 Aug 2020 15:48:38 +0200

Will the following text work for you?

Implementers should be aware that a token introspection request lets the AS know when the client 
     (and potentially the user) is accessing the RS, which is also an indication of when the user is using 
     the client. If this impliction is not accepatable, implementars MUST use other means to carry 
     access token data, e.g. directly transferring the data needed by the RS within the access token.

> On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 27 Aug 2020 10:19:51 -0400

I would clarify that this doesn’t necessarily say that the user’s there, and remove the normative requirement (which doesn’t have enforceable teeth in this context):

Implementers should be aware that a token introspection request lets the AS know when the client 
    (and potentially the user) is accessing the RS, which can also indicate when the user is using 
    the client. If this implication is not acceptable, implementers can use other means to carry 
    access token data, e.g. directly transferring the data needed by the RS within the access token.

 — Justin

> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Thu, 27 Aug 2020 08:44:32 -0600

+1

On Thu, Aug 27, 2020 at 8:20 AM Justin Richer <[email-masked]> wrote:

> I would clarify that this doesn’t necessarily say that the user’s there,
> and remove the normative requirement (which doesn’t have enforceable teeth
> in this context):
>
>     (and potentially the user) is accessing the RS, which *can also
> indicate* when the user is using
>     the client. If this implication is not acceptable, *implementers can
> use other means* to carry
> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <
> torsten=[email-masked]> wrote:
>
> On 26. Aug 2020, at 23:12, Mike Jones <
> Michael.Jones=[email-masked]> wrote:
>
> I agree with Dick’s observation about the privacy implications of using an
> Introspection Endpoint.  That’s why it’s preferable to not use one at all
> and instead directly have the Resource understand the Access Token.  One
> way of doing this is the JWT Access Token spec.  There are plenty of others.
>
> Subject: Re: [OAUTH-WG] Last Call:
> <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for
> OAuth Token Introspection) to Proposed Standard
>
>
>
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <
> torsten=[email-masked]> wrote:
> Hi Denis,
>
> The fact that the AS will know exactly when the introspection call has
> been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time.
> The use of this call allows an AS to track where and when
> As I see it, the privacy implication is that the AS knows when the client
> (and potentially the user) is accessing the RS, which is also an indication
> of when the user is using the client.
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Dick Hardt <[email-masked]>
Date: Thu, 27 Aug 2020 09:15:53 -0700

Here is a crisper revision.

Implementers should be aware that a token introspection request lets the AS
know when the client
    is accessing the RS, which may indicate when the user is using
    the client. If this implication is not acceptable, implementers can use
other means to carry
    access token data, e.g. directly transferring the data needed by the RS
within the access token.
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Sat, 29 Aug 2020 11:25:27 -0400

Thanks, Dick. I agree with removing the excess parenthetical, but I intentionally avoided using a lowercase “may” in the middle of the text  (in favor of “can”) to avoid normative-sounding non-normative language, so I’d recommend that change be kept:

Implementers should be aware that a token introspection request lets the AS know when the client 
    is accessing the RS, which can also indicate when the user is using 
    the client. If this implication is not acceptable, implementers can use other means to carry 
    access token data, e.g. directly transferring the data needed by the RS within the access token.

> On Aug 27, 2020, at 12:15 PM, Dick Hardt <[email-masked]> wrote:
> 
> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=[email-masked] <mailto:torsten=[email-masked]>> wrote:
>> 
>>> On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>> wrote:
>>> 
>>> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Dick Hardt
>>> To: Torsten Lodderstedt <torsten=[email-masked] <mailto:torsten=[email-masked]>>
>>> Cc: [email-masked] <mailto:[email-masked]>; oauth <[email-masked] <mailto:[email-masked]>>
>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=[email-masked] <mailto:torsten=[email-masked]>> wrote:
>>> Hi Denis,
>>> 
>>>> On 25. Aug 2020, at 16:55, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 29 Aug 2020 15:25:57 -0700

The "can" works better, agreed. Thanks!
ᐧ

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <[email-masked]> wrote:

> Thanks, Dick. I agree with removing the excess parenthetical, but I
> intentionally avoided using a lowercase “may” in the middle of the
> text  (in favor of “can”) to avoid normative-sounding non-normative
> language, so I’d recommend that change be kept:
>
>> I agree with Dick’s observation about the privacy implications of using
>> an Introspection Endpoint.  That’s why it’s preferable to not use one at
>> all and instead directly have the Resource understand the Access Token.
>> One way of doing this is the JWT Access Token spec.  There are plenty of
>> others.
>>

---

From: Denis <[email-masked]>
Date: Mon, 31 Aug 2020 09:58:11 +0200

The last text that has been proposed on the list about this thread is 
the following:

Implementers should be aware that a token introspection request lets the 
AS know when the client is accessing the RS,
       which can also indicate when the user is using the client. If 
this implication is not acceptable, implementers can use other means
       to carry access token data, e.g. directly transferring the data 
needed by the RS within the access token.

The concerns of the implementers have nothing to do with the concerns of 
the Users. Such a text proposal has nothing to do with a "User consent".

*Towards an RFC Errata to RFC 7662*

Mike Jones wrote:

I agree with Dick’s observation about the privacy implications of using 
an Introspection Endpoint. That’s why it’s preferable to not use one at all
       and instead directly have the Resource understand the Access 
Token. One way of doing this is the JWT Access Token spec. There are 
plenty of others.

I fully agree.

RFC 7662 should have incorporated a more detailed content such as:

      In OAuth 2.0 [RFC6749], the contents of tokens are opaque to 
clients. However, the contents of tokens is not intended to be opaque to 
RSs.
      Token introspection is an OPTIONAL feature of an AS described in 
OAuth Introspection [RFC 7662] intended for clients that are unable
      to support structured access tokens including their validation. 
The use of this call allows an AS to track where and when its clients 
have indeed
      presented an issued access token. As soon as the RS knows the 
format of the access token, e.g. using structured token formats such as
      JWT [RFC7519], and is able to validate its security features, the 
call described in OAuth Introspection [RFC 7662] should be avoided, 
otherwise
      the AS will know exactly when the introspection call has been made 
and thus be able to make sure which client has attempted perform an access
      to that RS and at which instant of time. As soon as this call is 
supported by an AS, the client or the user have no way to prevent the RS 
to use it.

It might be useful to add it, e.g. using an RFC Errata.

*Differences with RFC 7662*

RFC 7662 defines a protocol that allows authorized protected resources 
to query the authorization server to determine
the set of metadata for a given token that was presented to them by an 
OAuth 2.0 client.

At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems 
to be simply a JWT Response for OAuth Token Introspection
instead of a JSON document representing the meta information surrounding 
the token.

However, this is not the case since major differences can be identified.

RFC 7662 describes an OPTIONAL call able to return a JSON object with 
the following top-level members: active (REQUIRED), scope (OPTIONAL),
client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp 
(OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL),
aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON 
Web Token Claims" registry (OPTIONAL).

draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT 
as the introspection response. However, the request and the returned 
information
are not the same.

Section 4 (Requesting a JWT Response) only provides an example and does 
not describe the mandatory and optional parameters from the request.
Are they identical to those described in RFC 7662 ? No one is able to say.

draft-ietf-oauth-jwt-introspection-response-09 describes a response 
structure which is different from RFC 7662 where a single top-level 
member is required,
i.e. active. The text from 
draft-ietf-oauth-jwt-introspection-response-09 requires three (in fact 
four) top-level members. The text states:

The JWT MUST include the following top-level claims:

  * issMUST be set to the issuer URL of the authorization server.
  * audMUST identify the resource server receiving the token
    introspection response.
  * iatMUST be set to the time when the introspection response was
    created by the authorization server.

Note that the text about "active" (i.e. the fourth top-level member) is 
misplaced in the middle of the token_introspection claim and does not allow
to easily understand that the top-level claim "active" MUST be set to 
either true or false.

The text states:

The AS determines based on its RS-specific policy what claims about the 
resource owner to return in the token introspection response.

Such a sentence (which does not exist in RFC 7662) is a door wide-opened 
to return claims that are NOT included into the access token.
This protocol should NOT be a protocol that allows authorized RSs to 
query the AS to obtain metadata that was NOT included into an access token
that was presented to them.

Torsten wrote:

Token introspection has several advantages over structured access 
tokens, also when it comes to privacy. If one uses a structured access 
token
       in conjunction with different *services*, then this access token 
needs to contain ALL data required to call ALL these services. This 
effectively means
       the services learn more data than required. One could try to 
mitigate this by carrying encrypted compartments in the same token, each 
of them
       encrypted with for a certain service. That would be complex and 
is not covered by current technical standards. Introspection, however, 
allows the AS
       issue a minimal access token (even without any id) and mint 
specific response for the different RSs.

Instead of attempting to imagine complex mechanisms like "encrypted 
compartments in the same token", it is much simpler to use different 
access tokens.
AFAIK, in addition, there is no notion of "services" in OAuth in RFC 
6749, but only a notion of "server". A "server" is not a "service".

resource server

The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.

RFC 6750 is using the wording "audience restriction" to restrict the use 
of a token to "the intended relying party or set of relying parties"
(i.e. to one or more RSs).

So if the access token is targeted to one or more RSs, it should only 
contain what is necessary to accomplish the call on these RSs.
This means the RS(s) learn(s) exactly the data that it required. If it 
is not the case, several access tokens should be used.

The principle of "data minimization" implies that an access token should 
only contain what is necessary to accomplish a call to a given RS.

Since this new call is meant to be OPTIONAL, there should be no 
difference whether the RS decodes and validates the access token by itself
or sub-contracts the same operations to the AS.

The explanations from Torsten imply that there can be a difference .... 
which furthermore is left at the full discretion of the AS.

*About the secondary use*

I wrote:

This concern is identified in RFC 6973 as:

5.2.3.Secondary Use

Secondary use is the use of collected information about an individual
without the individual’s consent for a purpose different from that
for which the information was collected.Secondary use may violate
people’s expectations or desires.The potential for secondary use
can generate uncertainty as to how one’s information will be used in
the future, potentially discouraging information exchange in the
first place.Secondary use encompasses any use of data, including
disclosure.

Torsten replied:

       This is no secondary use, it’s the primary use *the user 
consented with*.

No "user consent" phase is ever mentioned in order to allow a RS to ask 
and receive a jwt-introspection-response.

The text states:

The AS MUST ensure the release of any privacy-sensitive data is legally 
based.

Such a statement does not make sense in practice. A different legal 
system applies depending upon three factors:
the location of the client, the location of the AS and the location of 
the RS.

Unless these three entities are located within the same country (e.g. 
Switzerland), the same state (e.g. Maryland) or
the same union (e.g. the European Union), the AS will be unable to know 
how to enforce such a statement.

The release of any privacy-sensitive data must be under the control of 
the user who must consent to the release
of that privacy-sensitive data. This makes it independent from any legal 
system.

*About the token introspection endpoint
*
The token introspection endpoint is advertised in RFC 8414 in the 
following way:

introspection_endpoint
OPTIONAL.URL of the authorization server’s OAuth 2.0 introspection 
endpoint [RFC7662].

This endpoint is intended to explicitly support RFC 7662, but not 
anything else. This draft is intended to support a new functionality 
that is different
from RFC 7662. This means that the AS should not use the same token 
introspection endpoint. If supported, this new functionality should be 
supported
using a new endpoint, e.g. an introspection_JWT_endpoint.

When this new functionality is advertised by an AS by the disclosure of 
an access point, this does not necessarily mean that it is supported for 
all the RSs
with which that AS has a relationship.

The current situation is that the User and his client have no way to 
know whether or not this new call will indeed be supported by the AS for 
a given RS.
Even the RS can't know it directly, since the only way to know it is to 
use a "trial and error" mechanism.

*A proposal on how to solve the issue*

Hereafter is one way on how to solve the issue.

The User is the entity that is the best placed to give the User Consent. 
It would be simpler if the user could ask to the AS to provide to his 
client
a JWT for a given RS that could be used to issue certificates usable for 
creating qualified electronic signatures. A specific scope could be defined
for such a purpose which would detail the claims to be incorporated into 
the access token and say that these claims shall be verified according to
sections 6.2.2 (Initial identity validation) of both ETSI EN 319 411-1 
and ETSI EN 319 411-2.

The client supporting the user would then communicate that JWT to the RS 
of its choice. The scope placed into the access token would testify
that the claims have indeed been verified according to sections 6.2.2 of 
both ETSI EN 319 411-1 and ETSI EN 319 411-2.

Such a functionality cannot be supported using 
draft-ietf-oauth-jwt-introspection-response.

In case the RS would be unable to decode the access token and/or to 
validate it, it might make attempt to make a call to the AS according to 
RFC 7662,
if this service is available (but the user has no way to indicate that 
he consents for making such a call).

As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms 
the user's privacy and fully by-passes the User consent,
this draft should not be progressed to the RFC level.

Denis

> On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thanks, Dick. I agree with removing the excess parenthetical, but
>     I intentionally avoided using a lowercase “may” in the middle of
>     the text  (in favor of “can”) to avoid normative-sounding
>     non-normative language, so I’d recommend that change be kept:
>
>         the client. If this implication is not acceptable,
>     implementers can use other means to carry
>>     On Aug 27, 2020, at 12:15 PM, Dick Hardt <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         the client. If this implication is not acceptable,
>>     implementers can use other means to carry
>>         I would clarify that this doesn’t necessarily say that the
>>         user’s there, and remove the normative requirement (which
>>         doesn’t have enforceable teeth in this context):
>>
>>             (and potentially the user) is accessing the RS, which
>>         *can also indicate* when the user is using
>>             the client. If this implication is not acceptable,
>>         *implementers can use other means* to carry
>>             access token data, e.g. directly transferring the data
>>         needed by the RS within the access token.
>>
>>
>>          — Justin
>>
>>>         On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt
>>>         <torsten=[email-masked]
>>>         <mailto:torsten=[email-masked]>> wrote:
>>>
>>>             (and potentially the user) is accessing the RS, which is
>>>         also an indication of when the user is using
>>>             the client. If this impliction is not accepatable,
>>>         implementars MUST use other means to carry
>>>             access token data, e.g. directly transferring the data
>>>         needed by the RS within the access token.
>>>
>>>
>>>>         On 26. Aug 2020, at 23:12, Mike Jones
>>>>         <Michael.Jones=[email-masked]
>>>>         <mailto:Michael.Jones=[email-masked]>> wrote:
>>>>
>>>>         I agree with Dick’s observation about the privacy
>>>>         implications of using an Introspection Endpoint. That’s why
>>>>         it’s preferable to not use one at all and instead directly
>>>>         have the Resource understand the Access Token.  One way of
>>>>         doing this is the JWT Access Token spec.  There are plenty
>>>>         of others.
>>>>
>>>>         The downsides of using an Introspection Endpoint should be
>>>>         described in the Privacy Considerations section.
>>>>
>>>>                                                               -- Mike
>>>>
>>>>         From: OAuth <[email-masked]
>>>>         <mailto:[email-masked]>> On Behalf Of Dick Hardt
>>>>         To: Torsten Lodderstedt
>>>>         <torsten=[email-masked]
>>>>         <mailto:torsten=[email-masked]>>
>>>>         <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT
>>>>         Response for OAuth Token Introspection) to Proposed Standard
>>>>
>>>>
>>>>
>>>>         On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt
>>>>         <torsten=[email-masked]
>>>>         <mailto:torsten=[email-masked]>> wrote:
>>>>         Hi Denis,
>>>>
>>>>>         The fact that the AS will know exactly when the
>>>>>         introspection call has been made and thus be able to make
>>>>>         sure which client
>>>>>         has attempted perform an access to that RS and at which
>>>>>         instant of time. The use of this call allows an AS to
>>>>>         track where and when
>>>>         As I see it, the privacy implication is that the AS knows
>>>>         when the client (and potentially the user) is accessing the
>>>>         RS, which is also an indication of when the user is using
>>>>         the client.
>>>>
>>>>         I think including this implication would be important to
>>>>         have in a Privacy Considerations section.
>>>>
>>>>         /Dick
>>>>         ᐧ
>>>

---

From: Neil Madden <[email-masked]>
Date: Mon, 31 Aug 2020 09:33:22 +0100

But if you want to handle revocation (and you do), then the alternative is short-lived access tokens with frequent refreshing, which also informs the AS of activity. So is this any better?

If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) then there are privacy implications to that arrangement, regardless of the specific technology used for token validation.

> On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
>

---

From: Jeff Craig <[email-masked]>
Date: Mon, 31 Aug 2020 12:40:50 -0500

I think that the argument is that token refreshing isn't as strong a signal
about usage patterns as introspection calls would be, which I agree with. I
also think that if a RS knows it's using an external AS, they've generally
accepted this information leakage. This is not to say it's not worth
mentioning in the document, but rather that I doubt it will significantly
move implementations one way or the other.

Generally speaking, I don't like JWTs as Access Tokens. They're verbose,
they leak information to clients that clients don't need, and if the RS
makes a mistake in their JWT validation, they can create security
vulnerabilities.  That said, I do think they are preferable to
Introspection at request time, and the RS's that I've worked with generally
don't want the overhead of Introspection on every usage of the token. I
generally argue a shared secret between the RS and the AS is a better
solution, but in my experience most cloud-hosted ASes don't offer that
option.

For this cloud AS situation, I have been
tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a
Token Endpoint to convert the AS access token into a access token (w/o
Refresh) that the RS can accept, thus limiting Introspection to the Refresh
flow, but I don't currently have a RS interested in trying to try this
flow, but I think that it's a reasonable approach to limiting introspection
on every request to the RS, though it does add an additional point of
failure during the Token Refresh. This has the same leakage problem that is
under discussion here, obviously.

On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <[email-masked]>
wrote:

> But if you want to handle revocation (and you do), then the alternative is
> short-lived access tokens with frequent refreshing, which also informs the
> AS of activity. So is this any better?
>
> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted)
> then there are privacy implications to that arrangement, regardless of the
> specific technology used for token validation.
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Dick Hardt
> *Sent:* Wednesday, August 26, 2020 9:52 AM
> *To:* Torsten Lodderstedt <torsten=[email-masked]>
> *Cc:* [email-masked]; oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Last Call:
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=
> [email-masked] <[email-masked]..org>>
> wrote:
>
> Hi Denis,
>
> > On 25. Aug 2020, at 16:55, Denis <[email-masked]
> <denis.ietf@free..fr>> wrote:
>
> As I see it, the privacy implication is that the AS knows * when* the
> client (and potentially the user) is accessing the RS, which is also an
> indication of *when* the user is using the client.
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 31 Aug 2020 11:09:19 -0700

Another approach to address the privacy implications of a token refresh
is a client can obfuscate usage by the user by doing regular token
refreshes independent of user activity.

ᐧ

On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig <jeffcraig=
[email-masked]> wrote:

> I think that the argument is that token refreshing isn't as strong a
> signal about usage patterns as introspection calls would be, which I agree
> with. I also think that if a RS knows it's using an external AS, they've
> generally accepted this information leakage. This is not to say it's not
> worth mentioning in the document, but rather that I doubt it will
> significantly move implementations one way or the other.
>
>> But if you want to handle revocation (and you do), then the alternative
>> is short-lived access tokens with frequent refreshing, which also informs
>> the AS of activity. So is this any better?
>>
>> > has attempted perform an access to that RS and at which instant of
>> time. The use of this call allows an AS to track where and when

---

From: Neil Madden <[email-masked]>
Date: Mon, 31 Aug 2020 19:51:06 +0100

> On 31 Aug 2020, at 18:41, Jeff Craig <[email-masked]> wrote:
> 
> 
> I think that the argument is that token refreshing isn't as strong a signal about usage patterns as introspection calls would be, which I agree with.

It’s usually pretty similar in my experience (see below).  

> I also think that if a RS knows it's using an external AS, they've generally accepted this information leakage. This is not to say it's not worth mentioning in the document, but rather that I doubt it will significantly move implementations one way or the other.

Right. 

> 
> Generally speaking, I don't like JWTs as Access Tokens. They're verbose, they leak information to clients that clients don't need, and if the RS makes a mistake in their JWT validation, they can create security vulnerabilities.  That said, I do think they are preferable to Introspection at request time, and the RS's that I've worked with generally don't want the overhead of Introspection on every usage of the token.

Generally you’d cache the result of the introspection call to mitigate this overhead. (Eg some reverse proxies or API gateways can do this). The two approaches are pretty similar: either you have 10 second access tokens and refresh, or you introspect and cache the response for 10 seconds. 

I much prefer introspection because there are far fewer ways to mess it up, but the JWT approach can be useful if you have clients accessing a lot of different RSes. 

> I generally argue a shared secret between the RS and the AS is a better solution, but in my experience most cloud-hosted ASes don't offer that option.
> 
> For this cloud AS situation, I have been tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a Token Endpoint to convert the AS access token into a access token (w/o Refresh) that the RS can accept, thus limiting Introspection to the Refresh flow, but I don't currently have a RS interested in trying to try this flow, but I think that it's a reasonable approach to limiting introspection on every request to the RS, though it does add an additional point of failure during the Token Refresh. This has the same leakage problem that is under discussion here, obviously.
> 
>> On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <[email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 31 Aug 2020 15:47:53 -0700

Hi all,

> It might be useful to add it, e.g. using an RFC Errata.

I do not believe this would be an appropriate usage of an Errata Report --
it changes the meaning of the RFC away from what the WG intended at the
time of publication.

Use of tokens that are just opaque DB handles (along with some form of
introspection) is desirable when a prominent threat is leakage of token
contents from the browser.  We have had numerous discussions over the years
of various ways in which information can leak from the browser, including
history APIs, malicious javascript, and more.  While these threats are not
always applicable in all deployment models, they are still present, just as
the threats that you propose we defend against are not always of concern in
all deployment models.  AFAICT, given the technologies currently available,
there is not one universal solution that will address all concerns, and
deployments will have to make a trade-off.  I think we need to acknowledge
that there are different deployment models and that (for example) giving
the user visibility into the token contents is not always desired, given
the other risks that the current mechanisms for providing that visibility
open up.

-Ben

P.S. your usage of the phrase "the User and his client" (below) suggests
that you are still picturing the client as being local to the user, as is
the case for, e.g., a TLS client or an IMAP client.  This is not the
original model for an OAuth, where the client can just as well be a
headless server in a cloud somewhere.

> >>>>>         <mailto:[email-masked]>> wrote:
> >>>>