Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
Denis <denis.ietf@free.fr> Tue, 25 August 2020 16:26 UTC
Return-Path: <denis.ietf@free.fr>
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 28F533A0F32 for <last-call@ietfa.amsl.com>; Tue, 25 Aug 2020 09:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.545
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad7pmq6ghOzk for <last-call@ietfa.amsl.com>; Tue, 25 Aug 2020 09:26:52 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FE83A0F36 for <last-call@ietf.org>; Tue, 25 Aug 2020 09:26:51 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d22 with ME id KsSp230012bcEcA03sSpHH; Tue, 25 Aug 2020 18:26:49 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 25 Aug 2020 18:26:49 +0200
X-ME-IP: 90.79.51.120
To: last-call@ietf.org
References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr>
From: Denis <denis.ietf@free.fr>
Cc: oauth@ietf.org
Message-ID: <b2871475-1959-06fd-a986-6be16deec4ce@free.fr>
Date: Tue, 25 Aug 2020 18:26:50 +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: <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr>
Content-Type: multipart/alternative; boundary="------------43C05610DF15704654E67A2C"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/JWSgzPotrmqHKLoC501hJFQw0Q8>
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: Tue, 25 Aug 2020 16:26:54 -0000
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. 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 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 toiesg@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
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Torsten Lodderstedt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Torsten Lodderstedt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Denis
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Denis
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Dick Hardt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Justin Richer
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Mike Jones
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Torsten Lodderstedt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Justin Richer
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Brian Campbell
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Dick Hardt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Justin Richer
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Dick Hardt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Denis
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Neil Madden
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Jeff Craig
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Dick Hardt
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Neil Madden
- Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf… Benjamin Kaduk
- [Last-Call] Towards an RFC Errata to RFC 7662 ? Denis
- Re: [Last-Call] [OAUTH-WG] Towards an RFC Errata … Manger, James