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

Justin Richer <jricher@mit.edu> Thu, 27 August 2020 14:19 UTC

Return-Path: <jricher@mit.edu>
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 3E56E3A0CD7; Thu, 27 Aug 2020 07:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uohW2p17y9nc; Thu, 27 Aug 2020 07:19:54 -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 B3BCF3A0CC5; Thu, 27 Aug 2020 07:19:54 -0700 (PDT)
Received: from [192.168.1.11] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07REJpgk029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 10:19:52 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <D68FCD40-7365-446A-9F64-2BB59C11B7AE@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8AB5B518-8B9A-44E8-81EA-0DDDD1B8CE01"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 27 Aug 2020 10:19:51 -0400
In-Reply-To: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "dick.hardt" <dick.hardt@gmail.com>, "last-call@ietf.org" <last-call@ietf.org>, oauth <oauth@ietf.org>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
References: <CH2PR00MB0678DA2BC7234C2AC1CE784DF5541@CH2PR00MB0678.namprd00.prod.outlook.com> <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ePe_mAnwoYVa3zoS6ONiDCA1tBY>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2020 14:19:56 -0000

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.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=40microsoft.com@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 <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>> Sent: Wednesday, August 26, 2020 9:52 AM
>> To: Torsten Lodderstedt <torsten=40lodderstedt.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=40lodderstedt.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’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