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

Justin Richer <> Wed, 26 August 2020 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08F153A0763; Wed, 26 Aug 2020 12:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AjKK-0K6Hfcm; Wed, 26 Aug 2020 12:06:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D93E3A0766; Wed, 26 Aug 2020 12:06:27 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 07QJ6OEu027978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Aug 2020 15:06:24 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_212EF0BE-FC34-4AAF-835A-5E90539B21CA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 26 Aug 2020 15:06:23 -0400
In-Reply-To: <>
Cc: Torsten Lodderstedt <>,, oauth <>
To: Dick Hardt <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
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: Wed, 26 Aug 2020 19:06:29 -0000

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