From nobody Sat Aug 29 08:25:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FB13A0C67; Sat, 29 Aug 2020 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PylE4rlmuzm6; Sat, 29 Aug 2020 08:25:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356AE3A0C68; Sat, 29 Aug 2020 08:25:31 -0700 (PDT) Received: from [172.16.101.121] (50-245-27-6-static.hfc.comcastbusiness.net [50.245.27.6]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07TFPS3p012864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 Aug 2020 11:25:28 -0400 From: Justin Richer Message-Id: <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 29 Aug 2020 11:25:27 -0400 In-Reply-To: Cc: Torsten Lodderstedt , Mike Jones , "last-call@ietf.org" , oauth To: Dick Hardt References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 15:25:34 -0000 --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Dick. I agree with removing the excess parenthetical, but I = intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in the = middle of the text (in favor of =E2=80=9Ccan=E2=80=9D) to avoid = normative-sounding non-normative language, so I=E2=80=99d recommend that = change be kept: Implementers should be aware that a token introspection request lets the = AS know when the client=20 is accessing the RS, which can also indicate when the user is using=20= the client. If this implication is not acceptable, implementers can = use other means to carry=20 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: >=20 > Here is a crisper revision. >=20 > Implementers should be aware that a token introspection request lets = the AS know when the client=20 > is accessing the RS, which may indicate when the user is using=20 > the client. If this implication is not acceptable, implementers = can use other means to carry=20 > access token data, e.g. directly transferring the data needed by = the RS within the access token. > =E1=90=A7 >=20 > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer > wrote: > I would clarify that this doesn=E2=80=99t necessarily say that the = user=E2=80=99s there, and remove the normative requirement (which = doesn=E2=80=99t have enforceable teeth in this context): >=20 > Implementers should be aware that a token introspection request lets = the AS know when the client=20 > (and potentially the user) is accessing the RS, which can also = indicate when the user is using=20 > the client. If this implication is not acceptable, implementers = can use other means to carry=20 > access token data, e.g. directly transferring the data needed by = the RS within the access token. >=20 >=20 > =E2=80=94 Justin >=20 >> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt = > wrote: >>=20 >> Will the following text work for you? >>=20 >> Implementers should be aware that a token introspection request lets = the AS know when the client=20 >> (and potentially the user) is accessing the RS, which is also an = indication of when the user is using=20 >> the client. If this impliction is not accepatable, implementars = MUST use other means to carry=20 >> access token data, e.g. directly transferring the data needed by = the RS within the access token. >>=20 >>=20 >>> On 26. Aug 2020, at 23:12, Mike Jones = > wrote: >>>=20 >>> I agree with Dick=E2=80=99s observation about the privacy = implications of using an Introspection Endpoint. That=E2=80=99s why = it=E2=80=99s 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. >>>=20 >>> The downsides of using an Introspection Endpoint should be described = in the Privacy Considerations section. >>>=20 >>> -- Mike >>>=20 >>> From: OAuth > = On Behalf Of Dick Hardt >>> Sent: Wednesday, August 26, 2020 9:52 AM >>> To: Torsten Lodderstedt > >>> Cc: last-call@ietf.org ; oauth = > >>> Subject: Re: [OAUTH-WG] Last Call: = (JWT Response for = OAuth Token Introspection) to Proposed Standard >>>=20 >>>=20 >>>=20 >>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = > wrote: >>> Hi Denis, >>>=20 >>>> On 25. Aug 2020, at 16:55, Denis > wrote: >>>=20 >>>> The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 >>>> 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=20 >>>> its clients have indeed presented an issued access token. >>>=20 >>> That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications. >>>=20 >>> 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. >>>=20 >>> I think including this implication would be important to have in a = Privacy Considerations section. >>>=20 >>> /Dick >>> =E1=90=A7 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Dick. I agree with removing the excess parenthetical, = but I intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in = the middle of the text  (in favor of =E2=80=9Ccan=E2=80=9D) = ;to avoid normative-sounding non-normative language, so I=E2=80=99d = 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 <dick.hardt@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.
3D""=E1=90=A7

On Thu, Aug = 27, 2020 at 7:19 AM Justin Richer <jricher@mit.edu> wrote:
I would clarify that this doesn=E2=80=99t = necessarily say that the user=E2=80=99s there, and remove the normative = requirement (which doesn=E2=80=99t 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.


 =E2=80=94 Justin

On Aug = 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@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=3D40microsoft.com@dmarc.ietf.org> = wrote:

I agree with Dick=E2=80=99s = observation about the privacy implications of using an Introspection = Endpoint.  That=E2=80=99s why it=E2=80=99s 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.

=             &n= bsp;           &nbs= p;            =             &n= bsp;    -- Mike

From: = OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: = Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
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=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

On 25. Aug 2020, at 16:55, Denis <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=E2=80=99t 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
=E1=90=A7

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


= --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598--