Re: [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: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EEC3A0C3D for <oauth@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=unavailable 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 V-kEg_7XibTN for <oauth@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 2AC543A0C3B for <oauth@ietf.org>; Wed, 26 Aug 2020 04:37:55 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id md23so2369239ejb.6 for <oauth@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=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 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/oauth/slkKouGjKqdQ4wMzPj-ZXjRbNrA>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 11:37:58 -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
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-intro… The IESG
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Mike Jones
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] [Last-Call] Last Call: <draft-ietf… Brian Campbell
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Neil Madden
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Jeff Craig
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Neil Madden
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Benjamin Kaduk
- [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Denis
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Justin Richer
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Manger, James
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Benjamin Kaduk