Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

"Manger, James" <James.H.Manger@team.telstra.com> Thu, 03 September 2020 01:14 UTC

Return-Path: <James.H.Manger@team.telstra.com>
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 CC6533A0C0E; Wed, 2 Sep 2020 18:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=team.telstra.com
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 4EK_KdBRXp8L; Wed, 2 Sep 2020 18:14:40 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4430A3A0C0D; Wed, 2 Sep 2020 18:14:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.76,384,1592834400"; d="scan'208,217";a="379544047"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 03 Sep 2020 11:14:34 +1000
Received: from wsapp5585.srv.dir.telstra.com ([10.75.3.67]) by ipcbni.tcif.telstra.com.au with ESMTP; 03 Sep 2020 11:14:34 +1000
Received: from wsapp5870.srv.dir.telstra.com (10.75.139.12) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Sep 2020 11:14:34 +1000
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5870.srv.dir.telstra.com (10.75.139.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Sep 2020 11:14:33 +1000
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by autodiscover.team.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 3 Sep 2020 11:14:33 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hOPw2XSe202nD7wrTXoXp7VRi9/1RBCSLhofBWX8wNgVXwJcifpvlW5O/1dOyRnKEaezKSi2KUikEJRc1W1QKCZfr/+VrXL5pxKZ9e9GUzWYmiRDZ4eyKtT8Yt64nNsiLgFQQ9g19QQalrxt7o31OBV2oz9kAZ8Bg7tYvpwynuYYlAhU5mEEcpWE7mYP/C454UI6HT/Dz5YR2JPh2iHAS/RmpF36qndI6/7/timgPbcrIEWit8X3cHjPQyluIt81grY6FeEEZJaAYTZtlXOgDRz8grX4oel21/H3hPQySDQh3Wm09cAMzP21GYwOD/6UJcRiOUjSANu9bj/6BSxqOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eAar6aHYpOznHAl1J4GZVKCVw+aj6YUH9U8kw+IXe8=; b=ai/DX/JK9UFIOKdscKRJgSnk6Hdj0ly1mSgkAf6mTGmTnLHIx9+RLv0CXKlu7kNUTwRnLMMJtXoKgjfWnYrxdUwckS017UhVhV+zYIh1LDYLV+IXE+w4fLkcCfhq3cODSCw2AfgRLE78f5lo5/bIvNt3d8c9U3J0c3ixb6kK7UOFFB6WO4WkMg7or8dRoL2lNsreDc+GBGQzV7JgVvtglkN8Z69QOX7i+CmG6379b9FdI9qbnjlI6tp7zRR1ZJPLawPHguMTqYyfJk6SzG6dN8BpWYG111WGkZJBxYPb+wpSGaHRvUXiCvZIkQiLEh9CM/zPu80dVXFX48teiad8og==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eAar6aHYpOznHAl1J4GZVKCVw+aj6YUH9U8kw+IXe8=; b=oGZY7PqifMtdh56kH5FcfES+leztnlwtKVtXlFSg5AEymf3POyuuhTXOwYXhbaE2QP8eFtaLspESaOtJHCpP5XS+BDL8n61JsJ/hekYTt5Jx8EauQ4iGD66WLekddUrmHi2DIDcQGIEh33Fe4zdIPsjvVzTNl5ZVvdLejrAR5Oo=
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by MEAPR01MB3014.ausprd01.prod.outlook.com (2603:10c6:201:d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Thu, 3 Sep 2020 01:14:32 +0000
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::5aa:6c1:56d6:5e93]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::5aa:6c1:56d6:5e93%6]) with mapi id 15.20.3348.015; Thu, 3 Sep 2020 01:14:32 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>
CC: "last-call@ietf.org" <last-call@ietf.org>, oauth <oauth@ietf.org>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Thread-Topic: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?
Thread-Index: AQHWgQTKZkr+sGm5SUygE4ugT4EwqqlWC8vw
Date: Thu, 3 Sep 2020 01:14:32 +0000
Message-ID: <ME2PR01MB3011FC3133369148CAA9D7E3E52C0@ME2PR01MB3011.ausprd01.prod.outlook.com>
References: <CH2PR00MB0678DA2BC7234C2AC1CE784DF5541@CH2PR00MB0678.namprd00.prod.outlook.com> <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <D68FCD40-7365-446A-9F64-2BB59C11B7AE@mit.edu> <CAD9ie-uqeM5jwQKuvO+X4NC5oXZkoLrRu1NWC2rrE4CD=ypa+g@mail.gmail.com> <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> <CAD9ie-s+MmtFHRNzym74cHBcBxu-yKCSH+r898TJ_dtmPDMK2Q@mail.gmail.com> <65a7f2c0-c7e3-5c67-1be6-1dfb2b77779e@free.fr> <20200831224753.GP16914@kduck.mit.edu> <34dcadf9-521f-60ba-a28c-3faab4428254@free.fr>
In-Reply-To: <34dcadf9-521f-60ba-a28c-3faab4428254@free.fr>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=team.telstra.com;
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c1eaf2d8-9a67-46d9-847f-08d84fa6b6d7
x-ms-traffictypediagnostic: MEAPR01MB3014:
x-microsoft-antispam-prvs: <MEAPR01MB3014C6734AFA80C09DC081EBE52C0@MEAPR01MB3014.ausprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rL0vDOGCh8o27mKRdVkiLZDiqeUOhVXce/k/6R2BB8b/8rI5G7lmKe1i6QEdlFETgCUO/GYcdJTOmNnS85Z0GnG+9yKFRK/w/MWdn0sz3mFD9fBv4QW/E6OUhl0YMrm0spr4Tuu+kOPC1+/6HZq/I2NjTDLyBxMMkyLbz6H1CSNQJzQ4aCwfLrDOmrUwwIm3ZXMf8JBmvHy8UZxl6vaBsnL/KwM3UdHHNLY3hBT2eDDiIuMzpJZpqVaBkVefFo/QetQ4foZpZJobBOSOcehzoaSoOfOTShTy5MDL6hGS3jvUqOHqn2RoxAnyy2GAtKFOmQN1rsigsrawGoReDsOkyA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(396003)(366004)(136003)(52536014)(5660300002)(76116006)(478600001)(66476007)(66946007)(64756008)(4326008)(66446008)(66556008)(86362001)(33656002)(9686003)(2906002)(54906003)(110136005)(83380400001)(8936002)(8676002)(316002)(55016002)(7696005)(186003)(26005)(71200400001)(6506007)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: GyHM/EUWXyMFWQ3v5sqG13LwQGQffqCHHkij2soCEnC8Wef2wmutTDRR/HvstwNLAl/bswmnUKFmZnNyYPsfUfgzlS21JnArfbaVU5DgSfW8UIl950PlsZ0DHqSdP7KTBRzrM4XuaND9a9RUGCU5yqhJzD/5lXscsOWE6Bxwr/S341mCN8yfxWNF92SSl6bIlPZ8tiE+S9oxpKiCZczYhMNODH6V5Us2lhJAA4wtLtDgDvvSg4gukG8TF6H+5xYDvtBWao/bmR3UYdftyQYnUtNFq3I2sJ1+uNFfUENy6O2nsAvU5fnssvXmeuNM/ooQRiVK8XiP8OfZya7Nn0Mj+PBoD1tpI7Kt7NryW8PDSGtwDldFvVZjBG7/UFIDImJVbdpjGNztFMLNE5gYguIGpHyafxX09lIHo7cKlBIPiLzp4ztiFHuUk9vNdm0gp9SZD7Xj1fXkyOdX8cGrQTH9WMPozwKAYA/qgyxspQ0AIfsOE043kP+wzDx9ZwhSJjVEtPGvdwxNk2DSZfQ4tqj2OI6d4P5+fztDk8Z0MxZg1KCHbVY/rC0Q06e5k8dGEEgG0I7BUAwPuA7WYjG9IgERZigwYIyPyBU4TcDw9X4CMlXexmBNcTiFPBsdb0Rho70uZXOfPjMOJEZ4t5GZWZWhkQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011FC3133369148CAA9D7E3E52C0ME2PR01MB3011ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: ME2PR01MB3011.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c1eaf2d8-9a67-46d9-847f-08d84fa6b6d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2020 01:14:32.2338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KBmX3gSuiGL80IPEmBcgi82Xg+ymaJ0tnVJzoDIILMlUp7b9DrreYe9tbI9Z19EKV3xKbw4kMelIiqSRdtZyhE70MGFT64PjEptat7hFmpI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB3014
X-OriginatorOrg: team.telstra.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BFJohucURLqTXF7qEvIdTjAOCvU>
Subject: Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?
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: Thu, 03 Sep 2020 01:14:42 -0000

> Token introspection is an optional feature primarily intended for clients

No.

The abstract of RFC 7662 (OAuth Introspection) starts:

   This specification defines a method for a protected resource to query
   an OAuth 2.0 authorization server to determine the active state of an
   OAuth 2.0 token and to determine meta-information about this token

Introspection is primarily for resource servers (RSs), not clients.

Denis, you are putting a lot of effort into improving privacy handling in OAuth. But by repeatedly using the wrong terms and attributing actions to the wrong entities your suggested text is not usable.

> If no Token introspection endpoint is published by an AS,
users and clients can be confident that such tracing cannot happen

Wow. That is a huge leap of faith. Any extra interactions between an RS & AS are somehow prevented (“cannot happen”) because AS metadata shown to another party (a client) is missing a URL?
The whole point of RFC 7662 (as discussed in its introduction) is that various “proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses)” have been developed to convey token info between AS & RS. So a standard could be helpful option for AS/RSs considering proprietary options. None of those proprietary mechanisms are mentioned in OAuth metadata published to clients.
--
James Manger

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Denis
Sent: Wednesday, 2 September 2020 6:39 PM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>rg>; Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>rg>; Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Subject: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

Hi Ben,

This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to discuss one of the topics raised in:
Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

Only the text relevant to this topic has been left.

The text that has been discussed and polished would perfectly fit into the Privacy Consideration section from RFC 7662.

Here it is again:

Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS,

which can also indicate when the user is using the client.  If this implication is not acceptable, implementers can use

other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token.

Privacy considerations sections do not change the protocol but only provide some warnings. Warning the implementers is fine,
but warning the users and the clients should also be considered.

Thanks to your observations, I noticed that the sentence "the call described in OAuth Introspection [RFC 7662] should be avoided"
is not appropriate. So I propose an additional text which is relevant for the users:

Token introspection is an optional feature primarily intended for clients that are unable to support structured access tokens, including their validation.

However, the use of this call allows an AS to track where and exactly when clients or users have indeed presented an issued access token to a RS.
Some users or clients may be concerned that such a feature allows the AS to accurately trace them. If no Token introspection endpoint is published by an AS,
users and clients can be confident that such tracing cannot happen. On the contrary, when an introspection_endpoint is published by an AS [RFC8414],
users and clients have no way to know whether the RS will be allowed to use it, nor whether it will effectively use it. If these implications are not acceptable,
users or clients should not use an AS that publishes an introspection_endpoint.

Denis