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

Denis <> Tue, 25 August 2020 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0034C3A0DD7 for <>; Tue, 25 Aug 2020 07:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.545
X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GhZrnQF3VjlZ for <>; Tue, 25 Aug 2020 07:56:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DA9F3A0DDC for <>; Tue, 25 Aug 2020 07:55:59 -0700 (PDT)
Received: from [] ([]) by mwinf5d50 with ME id Kqvu2300E2bcEcA03qvvpC; Tue, 25 Aug 2020 16:55:57 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 25 Aug 2020 16:55:57 +0200
References: <>
From: Denis <>
Message-ID: <>
Date: Tue, 25 Aug 2020 16:55:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------A69E85CBE657632DD095C38F"
Content-Language: en-GB
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: Tue, 25 Aug 2020 14:56:03 -0000

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

    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

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".

*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 

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.


> 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