Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Benjamin Kaduk]

k.ha...@gmail.com>> wrote:
> >>
> >> 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.
> >> ᐧ
> >>
> >> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  >> <mailto:jric...@mit.edu>> 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):
> >>
> >> 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
> >>>  >>> <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
> >>>
> >>> 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
> >>>>  >>>> <mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> 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  >>>> <mailto:oauth-boun...@ietf.org>> On Behalf Of Dick Hardt
> >>>> Sent: Wednesday, August 26, 2020 9:52 AM
> >>>> To: Torsten Lodderstedt
> >>>>  >>>> <mailto:torsten=40lodderstedt@dmarc.ietf.org>>
> >>>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; oauth
> >>>> mailto:oauth@ietf.org>>
> >>>> Subject: Re: [OAUTH-WG] Last Call:
> >>>>  (JWT
> >>>> Response for OAuth Token Introspection) to Proposed Standard
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt
> >>>>  >>>> <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
> >>>> Hi Denis,
> >>>>
> >>>>> On 25. Aug 2020, at 16:55, Denis  >>>>> <mailto:denis.i...@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
> >>>> ᐧ
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Neil Madden]

> On 31 Aug 2020, at 18:41, Jeff Craig  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  
>> 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.
>> 
>>>> On 26 Aug 2020, at 22:16, 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.
>>> 
>>>  
>>> 
>>> The downsides of using an Introspection Endpoint should be described in the 
>>> Privacy Considerations section.
>>> 
>>>  
>>> 
>>>-- Mike
>>> 
>>>  
>>> 
>>> From: OAuth  On Behalf Of Dick Hardt
>>> Sent: Wednesday, August 26, 2020 9:52 AM
>>> To: Torsten Lodderstedt 
>>> Cc: last-c...@ietf.org; oauth 
>>> Subject: Re: [OAUTH-WG] Last Call: 
>>>  (JWT Response for 
>>> OAuth Token Introspection) to Proposed Standard
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>>>  wrote:
>>> 
>>> Hi Denis,
>>> 
>>> > On 25. Aug 2020, at 16:55, Denis  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, th

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Dick Hardt]

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  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.
>
> 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 
> 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.
>>
>> On 26 Aug 2020, at 22:16, Mike Jones > 40microsoft@dmarc.ietf.org> 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  *On Behalf Of * Dick Hardt
>> *Sent:* Wednesday, August 26, 2020 9:52 AM
>> *To:* Torsten Lodderstedt 
>> *Cc:* last-c...@ietf.org; oauth 
>> *Subject:* Re: [OAUTH-WG] Last Call:
>>  (JWT Response for
>> OAuth Token Introspection) to Proposed Standard
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org <40lodderstedt@dmarc.ietf..org>>
>> wrote:
>>
>> Hi Denis,
>>
>> > On 25. Aug 2020, at 16:55, Denis > > 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
>>
>> ᐧ
>> ___
>> 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
>>
> ___
> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Neil Madden]

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 
>  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  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call: 
>  (JWT Response for OAuth 
> Token Introspection) to Proposed Standard
>  
>  
>  
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  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
> ᐧ
> ___
> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Denis]

r 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



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

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <mailto:jric...@mit.edu>> 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:

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 mailto:dick.ha...@gmail.com>> wrote:

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.
ᐧ

On Thu, Aug 27, 2020 at 7:19 AM Justin Richer mailto:jric...@mit.edu>> 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):

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
mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:

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
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> 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 mailto:oauth-boun...@ietf.org>> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt
mailto:torsten=40lodderstedt@dmarc.ietf.org>>
    Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; oauth
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Last Call:
 (JWT
Response for OAuth Token Introspection) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt
  

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Dick Hardt]

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

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer  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:
>
> 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  wrote:
>
> 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.
> ᐧ
>
> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  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):
>>
>> 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=40lodderstedt@dmarc.ietf.org> wrote:
>>
>> 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=40microsoft@dmarc.ietf.org> 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  On Behalf Of Dick Hardt
>> Sent: Wednesday, August 26, 2020 9:52 AM
>> To: Torsten Lodderstedt 
>> Cc: last-c...@ietf.org; oauth 
>> Subject: Re: [OAUTH-WG] Last Call:
>>  (JWT Response for
>> OAuth Token Introspection) to Proposed Standard
>>
>>
>>
>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <
>> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>> Hi Denis,
>>
>> On 25. Aug 2020, at 16:55, Denis  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
>> ᐧ
>>
>>
>> ___
>> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Justin Richer]

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  wrote:
> 
> 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.
> ᐧ
> 
> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  <mailto:jric...@mit.edu>> 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):
> 
> 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 
>> > <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
>> 
>> 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 
>>> >> <mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> 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 mailto:oauth-boun...@ietf.org>> On 
>>> Behalf Of Dick Hardt
>>> Sent: Wednesday, August 26, 2020 9:52 AM
>>> To: Torsten Lodderstedt >> <mailto:torsten=40lodderstedt@dmarc.ietf.org>>
>>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; oauth >> <mailto:oauth@ietf.org>>
>>> Subject: Re: [OAUTH-WG] Last Call: 
>>>  (JWT Response for 
>>> OAuth Token Introspection) to Proposed Standard
>>> 
>>> 
>>> 
>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>>> >> <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
>>> Hi Denis,
>>> 
>>>> On 25. Aug 2020, at 16:55, Denis >>> <mailto:denis.i...@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
>>> ᐧ
>> 
>> ___
>> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Dick Hardt]

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.
ᐧ

On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  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):
>
> 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=40lodderstedt@dmarc.ietf.org> wrote:
>
> 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=40microsoft@dmarc.ietf.org> 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  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call:
>  (JWT Response for
> OAuth Token Introspection) to Proposed Standard
>
>
>
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
> Hi Denis,
>
> On 25. Aug 2020, at 16:55, Denis  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
> ᐧ
>
>
> ___
> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Justin Richer]

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 
>  wrote:
> 
> 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 
>>  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  On Behalf Of Dick Hardt
>> Sent: Wednesday, August 26, 2020 9:52 AM
>> To: Torsten Lodderstedt 
>> Cc: last-c...@ietf.org; oauth 
>> Subject: Re: [OAUTH-WG] Last Call: 
>>  (JWT Response for OAuth 
>> Token Introspection) to Proposed Standard
>> 
>> 
>> 
>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>>  wrote:
>> Hi Denis,
>> 
>>> On 25. Aug 2020, at 16:55, Denis  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
>> ᐧ
> 
> ___
> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

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 
>  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  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call: 
>  (JWT Response for OAuth 
> Token Introspection) to Proposed Standard
>  
>  
>  
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  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
> ᐧ

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Mike Jones]

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  On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt 
Cc: last-c...@ietf.org; oauth 
Subject: Re: [OAUTH-WG] Last Call: 
 (JWT Response for OAuth 
Token Introspection) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf..org>>
 wrote:
Hi Denis,

> On 25. Aug 2020, at 16:55, Denis 
> mailto:denis.i...@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
ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Justin Richer]

I would argue that by the nature of OAuth tokens not being bound to user 
presence or sessions, it’s not an indication that the user is present 
necessarily, unless you know something additional about the nature of the 
client. But it does tell the AS when the client is active for a particular AS, 
which in some cases is a privacy concern and in others it’s a signal into the 
AS for keeping an eye out for aberrant behavior that a single RS couldn’t 
detect.

This is all a general implication of the introspection process, and not unique 
to this draft. That said, it’s an aspect of privacy that we did not cover in 
the considerations for RFC7662, but I don’t know if it’s appropriate to add 
such a general consideration here.

 — Justin

> On Aug 26, 2020, at 12:52 PM, Dick Hardt  wrote:
> 
> 
> 
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  > wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  > > 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
> ᐧ
> ___
> 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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Dick Hardt]

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt  wrote:

> Hi Denis,
>
> > On 25. Aug 2020, at 16:55, Denis  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
ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

> On 25. Aug 2020, at 18:26, Denis  wrote:
> 
> Here is an additional comment:
> 
> The text mentions in the Introduction: 
> 
>In example is a resource server using verified person data
>to create certificates, which in turn are used to create qualified
>electronic signatures.
> 
> The problem is the following: the AS has no way to verify that the User has 
> effectively authorized the RS 
> to use the JWT Response for such a purpose. A "User Consent" phase for such a 
> usage has not been addressed.  

Why not? The AS can easily ask the resource owner/user in the authorization 
process for consent to transfer certain end user claims to the RS. As a 
pre-requisite, the AS needs to determine what data is transmitted to an RS for 
a certain scope. 

> 
> 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.
> 
> The progression of this draft is really questionable. The User has currently 
> no way to allow or to disallow this protocol 
> which is between a RS and an AS.  It would not be reasonable to say that this 
> concern is outside the scope of this draft.
> Denis

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


> 
> 
> 
>> This draft contains a "Privacy considerations" section (Section 9).
>> .
>> The content of this section is as follows:
>> 
>>The token introspection response can be used to transfer personal
>>identifiable information from the AS to the RS.  The AS MUST ensure a
>>legal basis exists for the data transfer before any data is released
>>to a particular RS.  The way the legal basis is established might
>>vary among jurisdictions and MUST consider the legal entities
>>involved.
>> 
>>For example, the classical way to establish the legal basis is by
>>explicit user consent gathered from the resource owner by the AS
>>during the authorization flow.
>> 
>>It is also possible that the legal basis is established out of band,
>>e.g. in an explicit contract or by the client gathering the resource
>>owner’s consent.
>> 
>>If the AS and the RS belong to the same legal entity (1st party
>>scenario), there is potentially no need for an explicit user consent
>>but the terms of service and policy of the respective service
>>provider MUST be enforced at all times.
>> 
>>In any case, the AS MUST ensure that the scope of the legal basis is
>>enforced throughout the whole process.  The AS MUST retain the scope
>>of the legal basis with the access token, e.g. in the scope value,
>>and the AS MUST determine the data a resource server is allowed to
>>receive based on the resource server’s identity and suitable token
>>data, e.g. the scope value.
>> 
>> It is not believed that these explanations are useful, nor sufficient.
>> 
>> Talking a "legal basis" without translating legal constraints into technical 
>> constraints is not useful.
>> Since sensitive information may be returned, the text should say that AS 
>> should/must make sure that the requesting RS is indeed 
>> authenticated and allowed to perform this operation.
>> 
>> However, section 4 is only using the verb "SHOULD" whereas it should use the 
>> verb "SHALL" :
>> The AS SHOULD authenticate the caller at the token introspection endpoint.
>> Talking of "an explicit user consent gathered from the resource owner by the 
>> AS" does not make sense.
>> Either the operation is allowed or is not allowed by the RO, but there is no 
>> "RO consent".
>> 
>> About RFC 7662 (OAuth 2.0 Token Introspection)
>> 
>> One might think that the important considerations have already been provided 
>> when issuing RFC 7662 (OAuth 2.0 Token Introspection) 
>> which contains a Privacy considerations section (section 5).
>> 
>> The third sentence states:
>> One method is to transmit user identifiers as opaque service-specific 
>> strings, potentially returning different identifiers to each protected 
>> resource.
>> This would mean that the response would not reflect the content of the 
>> token. Furthermore, the RS would not even be informed of such a 
>> transformation.
>> 
>> The last sentence even states:
>> Omitting privacy-sensitive information from an introspection response is the 
>> simplest way of minimizing privacy issues.
>> In such a case, the introspection query becomes more or less useless.
>> 
>> What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?
>> 
>> The fact that using

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis  wrote:

thanks for the review and your feedback. 

> 
> 
> This draft contains a "Privacy considerations" section (Section 9).
> .
> The content of this section is as follows:
> 
>The token introspection response can be used to transfer personal
>identifiable information from the AS to the RS.  The AS MUST ensure a
>legal basis exists for the data transfer before any data is released
>to a particular RS.  The way the legal basis is established might
>vary among jurisdictions and MUST consider the legal entities
>involved.
> 
>For example, the classical way to establish the legal basis is by
>explicit user consent gathered from the resource owner by the AS
>during the authorization flow.
> 
>It is also possible that the legal basis is established out of band,
>e.g. in an explicit contract or by the client gathering the resource
>owner’s consent.
> 
>If the AS and the RS belong to the same legal entity (1st party
>scenario), there is potentially no need for an explicit user consent
>but the terms of service and policy of the respective service
>provider MUST be enforced at all times.
> 
>In any case, the AS MUST ensure that the scope of the legal basis is
>enforced throughout the whole process.  The AS MUST retain the scope
>of the legal basis with the access token, e.g. in the scope value,
>and the AS MUST determine the data a resource server is allowed to
>receive based on the resource server’s identity and suitable token
>data, e.g. the scope value.
> 
> It is not believed that these explanations are useful, nor sufficient.
> 
> Talking a "legal basis" without translating legal constraints into technical 
> constraints is not useful.
> Since sensitive information may be returned, the text should say that AS 
> should/must make sure that the requesting RS is indeed 
> authenticated and allowed to perform this operation.
> 
> However, section 4 is only using the verb "SHOULD" whereas it should use the 
> verb "SHALL" :
> The AS SHOULD authenticate the caller at the token introspection endpoint.

Good point. I added the requirement to authenticate the RS if privacy sensitive 
data is released to section 9. I’m reluctant to make it a general requirement 
since RFC 7662 also does not require all RSs to authenticate. 

> Talking of "an explicit user consent gathered from the resource owner by the 
> AS" does not make sense.
> Either the operation is allowed or is not allowed by the RO, but there is no 
> "RO consent".

I don’t understand your argument. The OAuth authorization flow is conducted 
with the resource owner and it is the resource owner who gives consent to the 
requested scopes to the AS. What do you mean by there is no "RO consent”?

> 
> About RFC 7662 (OAuth 2.0 Token Introspection)
> 
> One might think that the important considerations have already been provided 
> when issuing RFC 7662 (OAuth 2.0 Token Introspection) 
> which contains a Privacy considerations section (section 5).
> 
> The third sentence states:
> One method is to transmit user identifiers as opaque service-specific 
> strings, potentially returning different identifiers to each protected 
> resource.
> This would mean that the response would not reflect the content of the token. 
> Furthermore, the RS would not even be informed of such a transformation.
> 
> The last sentence even states:
> Omitting privacy-sensitive information from an introspection response is the 
> simplest way of minimizing privacy issues.
> In such a case, the introspection query becomes more or less useless.
> 
> What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?
> 
> The fact that using an introspection call can be avoided and should be 
> avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], 
> the contents of tokens are opaque to clients", it is not opaque to RSs. As 
> soon as the RS knows the format of the access token and is able 
> to validate its security features, this call should be avoided.
> 
> So what should be mentioned in section 9 ?
> 
> 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. 

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 t

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Denis]

Here is an additional comment:

The text mentions in the Introduction:

   In example is a resource server using verified person data
   to create certificates, which in turn are used to create qualified
   electronic signatures.

The problem is the following: the AS has no way to verify that the User 
has effectively authorized the RS
to use the JWT Response for such a purpose. A "User Consent" phase for 
such a usage has not been addressed.


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.

The progression of this draft is really questionable. The User has 
currently no way to allow or to disallow this protocol
which is between a RS and an AS.  It would not be reasonable to say that 
this concern is outside the scope of this draft.


Denis



This draft contains a "Privacy considerations" section (Section 9).
.
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into 
technical constraints is not useful.
Since sensitive information may be returned, the text should say that 
AS should/must make sure that the requesting RS is indeed

authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should 
use the verb "SHALL" :


The AS SHOULD authenticate the caller at the token introspection
endpoint.

Talking of "an explicit user consent gathered from the resource owner 
by the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there 
is no "RO consent".


*About **RFC 7662 (OAuth 2.0 Token Introspection)*

One might think that the important considerations have already been 
provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)

which contains a Privacy considerations section (section 5).

The third sentence states:

One method is to transmit user identifiers as opaque
service-specific strings, potentially returning different
identifiers to each protected resource.

This would mean that the response would not reflect the content of the 
token. Furthermore, the RS would not even be informed of such a 
transformation.


The last sentence even states:

Omitting privacy-sensitive information from an introspection
response is the simplest way of minimizing privacy issues.

In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be 
avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to 
RSs. As soon as the RS knows the format of the access token and is able

to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

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 a

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Denis]

This draft contains a "Privacy considerations" section (Section 9).
..
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into 
technical constraints is not useful.
Since sensitive information may be returned, the text should say that AS 
should/must make sure that the requesting RS is indeed

authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should use 
the verb "SHALL" :


   The AS SHOULD authenticate the caller at the token introspection
   endpoint.

Talking of "an explicit user consent gathered from the resource owner by 
the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there 
is no "RO consent".


*About **RFC 7662 (OAuth 2.0 Token Introspection)*

One might think that the important considerations have already been 
provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)

which contains a Privacy considerations section (section 5).

The third sentence states:

   One method is to transmit user identifiers as opaque
   service-specific strings, potentially returning different
   identifiers to each protected resource.

This would mean that the response would not reflect the content of the 
token. Furthermore, the RS would not even be informed of such a 
transformation.


The last sentence even states:

   Omitting privacy-sensitive information from an introspection
   response is the simplest way of minimizing privacy issues.

In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be 
avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to RSs. 
As soon as the RS knows the format of the access token and is able

to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

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.

Denis


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

This specification proposes an additional JSON Web Token (JWT)
secured response for OAuth 2.0 Token Introspection.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/


No IPR declarations have been submitted directly on this I-D.

___
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

[OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[The IESG]

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/



No IPR declarations have been submitted directly on this I-D.





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[The IESG]

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-08-07. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This draft proposes an additional JSON Web Token (JWT) based response
   for OAuth 2.0 Token Introspection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ballot/


No IPR declarations have been submitted directly on this I-D.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth