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:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4EEC3A0C3D for <>; Wed, 26 Aug 2020 04:37:57 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V-kEg_7XibTN for <>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AC543A0C3B for <>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
Received: by with SMTP id md23so2369239ejb.6 for <>; Wed, 26 Aug 2020 04:37:55 -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=yjltArgugF0P5pcCCisLKkTe4qTmiUzaUMriy8HPlwI=; b=nP/rKyBXc/5J28/VZdRYMJDvXZdrhPSr2cBEyghJimOTFVviV24EH+/XbCk6EofJRy 5cxqiA3i6mD0q7TRhMZfsJEEBTg1aENhhZ1f0oBZdNS5I7gNqQJgBb4cDJOlLGM/7jWm ADuclgnMtADdKJgWfgAnlssRUv1KdXsMRC5yMSlO2+auYXEJc6Z8sFfPYPRB44LlAPlx 8EYJp6GvC1m5Nd8c8F2k6J9r1OXvJ6HKddjyPheoMVoP1BD4YxiNEjz/0mqycmQHcEXm Hvz6xCdvPWZX/DDjaD2IQCR/wsSCpb5oFTw/5KP8xWmsZVvP0KxaTdtaWSyNcCLrg7Df 1aFQ==
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=yjltArgugF0P5pcCCisLKkTe4qTmiUzaUMriy8HPlwI=; b=sZTWrBXgMQhN7i409hIR3/5LmIa1ndcbZrOWdhQ9AyBvQdvBZMhv5WAo609iZyGd8F UU+tbJy9h25f+2mZwSFQ+jbRIN19e39vUZUukDcQGvZyoUgqbKW1DvKuUbepfpiZ9vTC fRvUooTJwGIr+xrIm7Fb4sPmT69Sj/jUK4PWYv8ivsF7T94kNun7Lxuo0ILNuGLBgLRv UXsgDoXQAR3+A8OWt/f0S6Qu99LVFvHVnTNDsf+yFIK5+cVq5tqeturZueQZy1NOv1v/ lE9Cec/RAoQ6t1D8SKfaltLY50fkzzMfCHN3jHYJ95wetSJ6RPdwSJXXtc2SP7hgy3BD 2sWQ==
X-Gm-Message-State: AOAM533SmqTSMA+dSdwxQeu3P5Z8yMa8MollZmIaLwsTUzGjLSYk9HNV dt5K4Rcj0ieJJMW/hHoZxS46xXzBpDTMXW17
X-Google-Smtp-Source: ABdhPJx629zTOuRkPW472OGSg3SWnjpP2dn4qMID6nUGcMvdVfGQ6GQ5yDII9BKB+RsqfmgaVC6c/A==
X-Received: by 2002:a17:907:693:: with SMTP id wn19mr5988880ejb.121.1598441873379; Wed, 26 Aug 2020 04:37:53 -0700 (PDT)
Received: from ( [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by with ESMTPSA id r26sm1835614eds.79.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 04:37:52 -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:37:51 +0200
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:37:58 -0000

> On 25. Aug 2020, at 18:26, Denis <> wrote:
> Here is an additional comment:
> The text mentions in the Introduction: 
>    In example is a resource server using verified person data
>    to create certificates, which in turn are used to create qualified
>    electronic signatures.
> The problem is the following: the AS has no way to verify that the User has effectively authorized the RS 
> to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed.  

Why not? The AS can easily ask the resource owner/user in the authorization process for consent to transfer certain end user claims to the RS. As a pre-requisite, the AS needs to determine what data is transmitted to an RS for a certain scope. 

> This concern is identified in RFC 6973 as:
> 5.2.3.  Secondary Use
>    Secondary use is the use of collected information about an individual
>    without the individual’s consent for a purpose different from that
>    for which the information was collected.  Secondary use may violate
>    people’s expectations or desires.  The potential for secondary use
>    can generate uncertainty as to how one’s information will be used in
>    the future, potentially discouraging information exchange in the
>    first place.  Secondary use encompasses any use of data, including
>    disclosure.
> The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol 
> which is between a RS and an AS.  It would not be reasonable to say that this concern is outside the scope of this draft.
> Denis

This is no secondary use, it’s the primary use the user consented with. 

>> 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.
>> 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 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.
>> 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
> _______________________________________________
> OAuth mailing list