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

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 26 August 2020 11:37 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453543A0C3F for <last-call@ietfa.amsl.com>; Wed, 26 Aug 2020 04:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 Z1W2X21Eojra for <last-call@ietfa.amsl.com>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4BD3A0C3D for <last-call@ietf.org>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id e23so1601871ejb.4 for <last-call@ietf.org>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; 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; d=1e100.net; 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=DaWTbgTEEMC6nFxg0tW9qVgH336RPTcAImC0HmJnX7JwQ1Xrj9A4idyi2EJib4Jyx3 TNcN4ClGinbyHoQS4ZptmmFESrXa7ndlktUWoidFj+HDx6GhgAUU5gINpgWgVtHqs/jg yMN6j5ZANMm7IsO4jm5iwF5V5o6sXjMEA6j4wfJPGvCsXceHCXcpzFWE/I4Qw826KZfQ z5MVuZlh63HHx3LiRSKYcD+4NjSiQ57WfgziJCqZ7VO5rHctoQYSksBFjy5wfXRnF23B Kdkv1IEfYldGthrrrqkRZJH02bCwvyKqGUu0uEUx1Nj1iMWzDvdjc5+TT3KSHF+3QhyE Yl5w==
X-Gm-Message-State: AOAM5313p0DhYC/jbUO3q/HDHQj1l2blV4x2RaTOdceipadPca5PGmyp 09ENGwjvK1FSiQ6s1K/AkuG9vQ==
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 p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de (p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de. [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by smtp.gmail.com with ESMTPSA id r26sm1835614eds.79.2020.08.26.04.37.52 (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.120.23.2.1\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <b2871475-1959-06fd-a986-6be16deec4ce@free.fr>
Date: Wed, 26 Aug 2020 13:37:51 +0200
Cc: last-call@ietf.org, oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E96A0166-5121-4183-A57D-619DCF669434@lodderstedt.net>
References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> <b2871475-1959-06fd-a986-6be16deec4ce@free.fr>
To: Denis <denis.ietf@free.fr>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/ZdceEhKUiBSmrBfKm2Nqa2jYs4Q>
Subject: Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 11:37:57 -0000


> On 25. Aug 2020, at 18:26, Denis <denis.ietf@free.fr> 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
>>> 
>>> last-call@ietf.org
>>>  mailing lists by 2020-09-04. Exceptionally, comments may
>>> be sent to 
>>> iesg@ietf.org
>>>  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
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
>>> 
>>> 
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> 
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth