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

[Dick Hardt <[e-mail]>]

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

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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=[e-mail]> 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=[e-mail]> 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 <[e-mail]> On Behalf Of Dick Hardt
>> Sent: Wednesday, August 26, 2020 9:52 AM
>> To: Torsten Lodderstedt <torsten=[e-mail]>
>> Cc: [e-mail]; oauth <[e-mail]>
>> 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=[e-mail]> wrote:
>> Hi Denis,
>>
>> On 25. Aug 2020, at 16:55, Denis <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>