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

Torsten Lodderstedt <> Wed, 26 August 2020 11:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7A6F3A1053 for <>; Wed, 26 Aug 2020 04:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jvsg3TkuRMgy for <>; Wed, 26 Aug 2020 04:35:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6C503A1050 for <>; Wed, 26 Aug 2020 04:35:42 -0700 (PDT)
Received: by with SMTP id e23so1593588ejb.4 for <>; Wed, 26 Aug 2020 04:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hFqPKaGSsuvKI55VPZBL8+WVw0IlxfxWBQI6bODV++I=; b=55/3JGya8KyLUH1GgjV+0yvDkXSfUqWiaTd3c6hfux80Wash4Rt2CxE954txsYgAEa PdvxelzLFRc+xfZOsYTpuyrdNZJZ1ReZ06pksVMEsrwbyqwWs5YVtkdWSUrEp/Fq9Iuu A2BMm9BD0GnlogylDCXOs5RxC6AVrEvrTX3TcO66W1V0OT2wXjlze3NwLP+9n7BNnAKX WJBApLzSeAMAT5soRp4EBCEQJ957005Vinl9zpUxyEaLH3BUqR26VPSm3xNC4nSFK3iW JoTHXXHTxfmZb9JDNvQ7XX3Oge72ww/W8KOzDYQvrku1MOcTmCoBbqPHxfS5rlwRAfXT Tifg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hFqPKaGSsuvKI55VPZBL8+WVw0IlxfxWBQI6bODV++I=; b=pgTiAAikerUXD4C2K3ofFsIQ7qLfMR2ukQPi4SJWrrydFXDenLI4qrtE+ISfjVJujv uV7pwG/wv5XY7STI2jgw9OGoZs9TtS/hTPrPA1Q+9iZqFP/GUlTax6181W6CweScxbbx cqIj1POR9js4+zgU8Zs+KMNJUjU3y7RW/dZnhZXnd2fmSPlZYPm30UnfNFbHYPTJR9FN a/PHI/Y4dlBMW1wb0HN7aWjWYSuSjaMimQlrnrA0H9XFJZg2iZQfyI3KI2tuMSsEtYBF zWULrZbmMv32h/Ty8/EAuCQuLCXOdxbYA1QvEG4mdwxjlLtSZ2F8//egx6TQ6buRoOlN 9U0Q==
X-Gm-Message-State: AOAM531En4xAVHH9OdqlNI37OGH6MZLvvRwHTOx6fiieXyw0df0foiDP 2+Dr3NHdExXoSLHruDUHhxa145YrqPvHYIGN
X-Google-Smtp-Source: ABdhPJwZ1oBLldABYW/dbyWUpXkWa4MYgmGz5K7AJEREpf0FMmshSvQxyRCzFkbEpGU0K02gXELurQ==
X-Received: by 2002:a17:906:f1d4:: with SMTP id gx20mr15210843ejb.132.1598441741081; Wed, 26 Aug 2020 04:35:41 -0700 (PDT)
Received: from ( [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by with ESMTPSA id q15sm1820366edc.74.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 04:35:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Torsten Lodderstedt <>
In-Reply-To: <>
Date: Wed, 26 Aug 2020 13:35:38 +0200
Cc:, oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Denis <>
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 11:35:45 -0000

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 them encrypted with for a certain service. That would be complex and is not covered by current technical standards. Introspection, however, allows the AS issue a minimal access token (even without any id) and mint specific response for the different RSs. 

best regards,

> 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'
>>   <draft-ietf-oauth-jwt-introspection-response-09.txt> 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
>>  mailing lists by 2020-09-04. Exceptionally, comments may
>> be sent to 
>>  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
>> No IPR declarations have been submitted directly on this I-D.
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list