Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Mike Jones <Michael.Jones@microsoft.com> Fri, 31 January 2020 14:31 UTC
Return-Path: <Michael.Jones@microsoft.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 625B6120104; Fri, 31 Jan 2020 06:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 YU1OgGawmbEX; Fri, 31 Jan 2020 06:31:06 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06hn0209.outbound.protection.outlook.com [104.47.54.209]) (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 CFB8512007C; Fri, 31 Jan 2020 06:31:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l42hS/quv3GYuAtgEsU8L1yyDFIB+0ynYNMInwO9BZoS8OhOUCaGQ6lqpW+peHP6gNuX/0weQGE8HSNU7LH/JTN9FsnZUiKtTsF7q1CF04Zqu11+FxltlXu9kBRkW4ZoGNCFUuSZziMsWkW7bG1t80b5fcwblz6pd9QMy+Aii/moSG3vI5S0IHxl3AGJ+wp+yF6eK0rH+/suS3Jjz5SsmkwVHPQo00OtDA9T+FdmSTq096VGpJ1dKjIX5D6LNPmxBzUAq7+Chqplsu41exndQpLtv6jTyF3iec7v4ZymnqLt2iBHDHdscKI8QxpPmokXpXpUq4aFQOmBj4zoRyNawQ==
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=d6CvkrwJQzp0C/x7ZK5DQIa3iRZcFDo/n3VOeCOfT7w=; b=TdEDiP6AUDSeAtXJJux3lSy7AUeaQcvRwGBEgJ/gKc9XJUC2jbcEmLalgvUCIYT1c9pePUWcnrO/h1ZWV0kX9ywm0/98Mj93zq3RP3m09usK7kxHIHgPea4ut7w+t6SmbBpeGtMs3R//GxxA1QCYeZ1RqkClGxrUt6fZfWtpSSyD8yiFedfTww6zfNZ2VIu6b0MvCIbUdE7gKqDim4lrTm7FzjdowpshalyEmHD89fiN653Ms06hQhdCD/UWZVLddzrQiSWiWlzocpAEcN86+8tBsWuujWDe2nhRn2NxMc2OAIr9qTp0UNTJhfCoWH/dZgclCjW3vMDpksmoJJWwTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d6CvkrwJQzp0C/x7ZK5DQIa3iRZcFDo/n3VOeCOfT7w=; b=aePDZT4m2Q6f+g5vuX9/rMWKd4tPnvzdi3IknK/rO2VS/DvrOhwEMWvHLLK9ixIDUCrqLCAzNfuUpBWEF+uOnEBdR5e6jlxBfYQZqUnnpDJ59imHkChSZSlpDYgLGjkw5OfD8Ke/01UhGRxBE0DRoUNwlh5nQuG8CO6Ajn4JNN4=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) by CH2PR00MB0795.namprd00.prod.outlook.com (10.186.139.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2731.0; Fri, 31 Jan 2020 14:30:54 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::1963:3ecd:52ea:4c5d]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::1963:3ecd:52ea:4c5d%6]) with mapi id 15.20.2731.000; Fri, 31 Jan 2020 14:30:54 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Nat Sakimura <sakimura@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: oauth <oauth@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-oauth-jwsreq@ietf.org" <draft-ietf-oauth-jwsreq@ietf.org>
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Thread-Index: AQHVMROxsVto7/ZDoUm6lxkAeRl7u6du60EAgJSn6QCAAdGhgIAAvX+AgAABVDA=
Date: Fri, 31 Jan 2020 14:30:54 +0000
Message-ID: <CH2PR00MB06786F235896AB63594D11FAF5070@CH2PR00MB0678.namprd00.prod.outlook.com>
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> <CABzCy2BWV6+gyaSNkjJjWHMk-xx0iB2A2aDxEssf9EuaEjXR8w@mail.gmail.com> <20200129232014.GN48797@kduck.mit.edu> <CABzCy2CVSdb7ALw7-6tP3Pnw5jwOxAGx1UM81BjeyhugZ8BsvA@mail.gmail.com> <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
In-Reply-To: <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6b705dff-0494-400f-932a-0000cd7113aa; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-31T14:29:47Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [83.219.75.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: dabe22bd-2c2e-46ae-7894-08d7a65a2dff
x-ms-traffictypediagnostic: CH2PR00MB0795:
x-microsoft-antispam-prvs: <CH2PR00MB07951AA00D05CC23EB446A5FF5070@CH2PR00MB0795.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:SPM; SFS:(10001)(10019020)(4636009)(366004)(199004)(189003)(66446008)(64756008)(66556008)(66476007)(55016002)(52536014)(71200400001)(30864003)(4326008)(33656002)(8676002)(9686003)(81166006)(81156014)(10290500003)(86362001)(498600001)(2906002)(53546011)(8936002)(6506007)(7696005)(966005)(66946007)(76116006)(5660300002)(8990500004)(26005)(66574012)(110136005)(54906003)(186003)(61000200002); DIR:OUT; SFP:1501; SCL:5; SRVR:CH2PR00MB0795; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5Wt6fHDVpatAzpfTtv9hwBkIuK49rgqHUC9nD6cvWjpEG1TUrkh0is5Q/Ug+sYCqWk6ibd7AU2y+GeQJpoGETHo0A8Ex94Kvp6VV6iyxMC09ELvmJVFw/q9mla1GD+n+6kStepIc57MFRkTTiEHDlqKQMFA6gHeZgVA74C+OpbR2vJ+/A5CfFOJkIGDPLpoMFj95sHPwLuQ+nwxquW6LPFNF3DYbrbil40NpHHu73WL8OWpDaJvBVglofWnxynMoBLj4a+IOBmQ2CBeTRyrzre7E6ZoX5gXhxleuDk+XAogwxrpeqjgKqhGG3OwM5JhMrZMCPoK0/H6nomYMFmwujqIvOUwDdH9GMgf/RmGzvW9dnuDsq+VeVd787UNCEndDjksTWmqlzgmWFHfYtXzAp4gQiLR+MT2l1816V0/7XrrL0peCoIVymcfDO3A6Yi3KpIsTYRbHlyHbB5PvtAIHG7wbwKfKoWd93YvHzg8/uNZFoqLO+trXoL4eiSABCyyI11sJFZbmDQJg/ODKSF3UmyGq8ikX5VR0btrZf7Gxf8VB17H01KBUYU9R7D716AjbS2yTs+LR0PruesaNHk5Xyy2+cMkgk4gTMX653ZUBx4giBNnK2u4ErnoZ+MknsJq2o+mR8dP322xg/eP6qljuhIg6GiUvuLZ9+3HOIHqnDvGqHk9J4UwLDwpvyyJ9gaiPZw+zqn6R0F2BTGJv2xTUpbPKU5VXq6V4A8RRcfi1ksfYjI16bjNvqn4oCx9sZUi/JcjJzRVRFhqjKnNWhwHwhmoLumDTyjVsM8QqD0XgrEfo0QIqkfnhp7fcfhCzaKjtNCaEPIlY8/Vj62oSCbzzMCrdWSTfBVgALSMfuiKMhKdqNb8dvr5S+EmKN3Y61dYNXLSiZDWmXU3qJEZPuIciggDWDBSWQBSF/Xt9nAtT7jG111WUcw3HRnWOTwgbV+IeIAHjkmgPdKJG/KWxEYd7ZQ==
x-ms-exchange-antispam-messagedata: bIrssrrXn7LgJRu7njGv2f11VFhii/zUbrr1DIUqjgYawGYhQe5It9hKmuIEWmh/aFHN2lBh7LQTNiZntguPIFnHjjJgcIgp/8gSRMbOovJrEysmKV3F+MgB92pXdeAYuGcLwf/GJnpoDOqqoSIVlw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dabe22bd-2c2e-46ae-7894-08d7a65a2dff
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 14:30:54.3496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 96NdQ49S4LAOkFSjAApOBApss5I7MdVQIJPffZIQXC2iPd8ubbyuBwNhsWPXGwI1/Hb+CSTMEZc6NpcUHMFzGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0795
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GxF-puewvag-oydtkm5OIKUwtkM>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
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: Fri, 31 Jan 2020 14:31:09 -0000
I also agree that we must allow client_id to be expressed outside of the signed request, as described by Nat. -- Mike -----Original Message----- From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley Sent: Friday, January 31, 2020 6:25 AM To: Nat Sakimura <sakimura@gmail.com>; Benjamin Kaduk <kaduk@mit.edu> Cc: oauth <oauth@ietf.org>; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>; draft-ietf-oauth-jwsreq@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT) >From the discussions I have had, I agree with Nat's assment. John B. On 1/31/2020 12:06 AM, Nat Sakimura wrote: > Hi > > Re: JWT > I understand your concern and we can put some explanatory notes. > Having said that, JAR is still a valid JWT, I think :-) > > Re: client_id > We actually discussed client_id issues with OpenID Connect WG Call > yesterday as well. > I hear a pretty strong voice from the developer community that they > want client_id as a query parameter and it should not pose a security > issue as long as it is required to match what is in the JWT. In fact, > that was the position taken in the WG last call. So, in effect, WG is > actually pushing back the change IESG wanted. > > As I understand it, there are two points to be made: > (1) If client_id is not in the query parameter, then it MUST be in the > JWT header OR MUST be supplied as a query parameter in some encrypted > JAR case > (2) To check if requst_uri is a registered and valid URI, not having > client_id in the query parameter will have performance impacts in a > large AS. > > The encryption case (1) can be solved by adding client_id in the JWT > Header but it will not solve (2). > So, IMHO, putting client_id back to the query parameter (and MUST > match the value in JWT) is a way to go. > Since that was the position by the WG at the WG Last Call, I do not > feel that it needs to be brought back to the WG last call, but that is > your call. > > Best, > > Nat Sakimura > > On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk <kaduk@mit.edu> wrote: > >> Hi Nat, >> >> Now it is my turn to apologize for taking a long time. >> >> I think I see the general direction these changes are going in, and >> it's a reasonable approach to the unfortunate situation we find >> ourselves in with respect to JWT claims vs. OAuth parameters. In >> effect, what we're doing is making a "profile" (for lack of a better >> term) of JWT, that leverages the mechanisms and algorithms of JWT but >> uses a different registry for interpreting the claims in the token >> (that is, OAuth Parameters vs. JWT Claims). We can tell that this >> "profile" of JWT is being used because of the context in which the JWT is transferred/received: if it's the "request" >> parameter, that's part of the definition of the OAuth Parameter, and >> if it's the result of dereferencing a "request_uri", the >> application/oauth.authz.req+jwt media-type clearly indicates how the >> contents should be interpreted. >> >> However, the changes in the -20 do not give the reader much of any >> hint as to this being what's expected to happen, and that stock RFC >> 7519 JWT is >> *not* what's in use. So I'd request that we take a close look at how >> the document uses "JWT" vs. "JWT encoding" (etc.); add an explicit >> statement that while the JWT encoding is in use, the contents are to >> be interpreted by interpreting the JWT claims as OAuth Parameters >> (and not as per the IANA registry of JWT claims); and add some >> discussion (similar to the above) about how the application context >> makes it unambiguous whether the JWT-encoded claims are standard JWT >> claims or OAuth Parmaters as per this document. >> >> With respect to my second ("discuss discuss") point, Nat and I did >> have a discussion in-person and I accept that there may be some >> scenarios in which skipping the authorization dialogue is >> appropriate, so the example can remain. >> >> >> Moving on from my Discuss position, I do get the sense from the >> ongoing discussion on the list that there's not clear agreement about >> the current formulation that requires all parameters (but "request" >> and "request_uri") to be in the JAR, especially with respect to >> "client_id" that might be needed to unpack the JAR in some cases! So >> I'm not sure whether the WG wants to bring the document back to the >> WG to iron out those issues before it returns to the IESG. I'm a >> little reluctant to switch my position to "No Objection" until we >> have a clearer picture of what the WG wants to do on this front -- in >> my understanding, we can't really publish the document without at >> least some solution ("client_id") for the encrypted-request key-lookup case. >> >> Thanks, >> >> Ben >> >> >> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote: >>> Hi >>> >>> Took a long time but finally all the changes needed to resolve the >> DISCUSS >>> comments are (hopefully) applied as -20. >>> >>> There is one change that impacts the process: the draft now has IANA >>> request so it needs to be referred back to IANA. >>> >>> The IETF datatracker status page for this draft is: >>> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >>> >>> Best, >>> >>> Nat Sakimura >>> >>> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker <noreply@ietf.org>: >>> >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-oauth-jwsreq-19: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to >>>> all email addresses included in the To and CC lines. (Feel free to >>>> cut this introductory paragraph, however.) >>>> >>>> >>>> Please refer to >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01 >> %7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7 >> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sd >> ata=6ZSWckU9w8S1oDEUz%2BgKPguV2UFjyfzKrOIt9V4qXRQ%3D&reserved=0 >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-jwsreq%2F&data=02% >>>> 7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a659 >>>> 6612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63716077521867674 >>>> 0&sdata=eaeSN%2BgKTCDiy502GPNm459JjYuOj5o77Tp%2B6QAw3HY%3D& >>>> reserved=0 >>>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> --- >>>> DISCUSS: >>>> ------------------------------------------------------------------- >>>> --- >>>> >>>> This is a "discuss discuss" -- it's an important question and I'd >>>> like to talk about it, but it's not clear that any change to the >>>> document will be needed. >>>> >>>> Once this (and some of the more substantive items in the Comment >>>> section) is resolved, I'd be happy to ballot Yes. >>>> >>>> The introduction notes as an advantage of JWT that: >>>> >>>> (d) (collection minimization) The request can be signed by a third >>>> party attesting that the authorization request is compliant >> with >>>> a certain policy. For example, a request can be >>>> pre-examined >> by >>>> a third party that all the personal data requested is strictly >>>> necessary to perform the process that the end-user asked for, >>>> and statically signed by that third party. The authorization >>>> server then examines the signature and shows the conformance >>>> status to the end-user, who would have some assurance as to the >>>> legitimacy of the request when authorizing it. In some cases, >>>> it may even be desirable to skip the authorization dialogue >>>> under such circumstances. >>>> >>>> I'm pretty uncomfortable about suggesting that the authorization >>>> dialogue can/should be skipped; do we need to keep this example? >>>> Maybe just talking about what an expected use case could be would >>>> help alleviate my unease. >>>> >>>> >>>> ------------------------------------------------------------------- >>>> --- >>>> COMMENT: >>>> ------------------------------------------------------------------- >>>> --- >>>> >>>> Section 1 >>>> >>>> While it is easy to implement, the encoding in the URI does not >> allow >>>> application layer security with confidentiality and integrity >>>> protection to be used. While TLS is used to offer communication >>>> >>>> nit: this wording is a little hard to read; it might be easier to >>>> reorder to "does not allow application layer security to be used to >>>> provide confidentiality and integrity protection". >>>> >>>> The use of application layer security allows requests to be prepared >>>> by a third party so that a client application cannot request more >>>> permissions than previously agreed. This offers an additional >> degree >>>> of privacy protection. >>>> >>>> (side note) what would an example of such a third party be. (We >> already >>>> have the resource owner, the client, and the authorization server ... >>>> maybe it's a fourth party?) >>>> >>>> Furthermore, the request by reference allows the reduction of over- >>>> the-wire overhead. >>>> >>>> We only barely mentioned by-reference at this point (one line in >>>> the Abstract), so I'd suggest "passing the request by reference". >>>> >>>> (4) its development status that it is an RFC and so is its >>>> associated signing and encryption methods as [RFC7515] and >>>> [RFC7516] >>>> >>>> nit: I'd suggest "its development status as a Proposed Standard, >>>> along with the associated signing and encryption methods [RFC7515] >> [RFC7516]." >>>> (c) (confidentiality protection) The request can be encrypted so >>>> that end-to-end confidentiality can be provided even if the TLS >>>> connection is terminated at one point or another. >>>> >>>> nit: TLS is always terminated at or before the user-agent, though. >>>> So maybe the user agent needs to get called out here as well (there >>>> could of course be TLS termination earlier than the user-agent in >>>> some cases, too). >>>> >>>> 2. When the client does not want to do the crypto. The >>>> Authorization Server may provide an endpoint to accept the >>>> Authorization Request through direct communication with the >>>> Client so that the Client is authenticated and the channel >>>> is >> TLS >>>> protected. >>>> >>>> How can you "not want to do [the] crypto" but still be doing TLS >>>> (with crypto)? Perhaps we're looking for "not want to pay the >>>> additional overhead of JWS/JWE cryptography on top of TLS"? >>>> >>>> Section 1.1 >>>> >>>> RFC 8174 has updated BCP 14 boilerplate text to use. >>>> >>>> Section 3 >>>> >>>> nit: should this section be 2.3 to get wrapped into "terminology"? >>>> >>>> It might also be worth putting references in for the terms, though >>>> they are largely common knowledge at this point. >>>> >>>> Section 4 >>>> >>>> A Request Object (Section 2.1) is used to provide authorization >>>> request parameters for an OAuth 2.0 authorization request. It MUST >>>> contains all the OAuth 2.0 [RFC6749] authorization request >> parameters >>>> including extension parameters. The parameters are represented >>>> as >>>> >>>> nit: "all the parameters" kind of sounds like "all that are defined". >>>> But I think the intent here is "any parameter used to process the >>>> request must come from the request object and URL query parameters >>>> are ignored", so maybe "MUST contain all the parameters (including >> extension >>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization >>>> request; parameters from other sources MUST NOT be used", akin to >>>> what we say down in Sections 5 and 6.3. >>>> But we need to be careful about the wording to not exclude the >>>> usage of the "request" and "request_uri" query parameters to find >>>> the Request Object! >>>> >>>> the JWT claims. Parameter names and string values MUST be >>>> included >>>> >>>> nit: maybe "the JWT claims of the object"? >>>> >>>> any extension parameters. This JSON [RFC7159] constitutes the JWT >>>> Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then >>>> signed or signed and encrypted. >>>> >>>> nit: I think we want "This JSON [RFC7159] object". >>>> >>>> (Long quote incoming) >>>> >>>> The following is an example of the Claims in a Request Object before >>>> base64url encoding and signing. Note that it includes extension >>>> variables such as "nonce" and "max_age". >>>> >>>> { >>>> "iss": "s6BhdRkqt3", >>>> "aud": "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=L2bwEdfW4tbnTI5FSJTCC%2BkI3EA6CqNNqZ5FzT0JnRs%3D&reserved=0", >>>> "response_type": "code id_token", >>>> "client_id": "s6BhdRkqt3", >>>> "redirect_uri": "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclient.example.org%2Fcb&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=XBvLTF0JuNuz7I3c7pBel0GNSN0lcYqvoHCNagAwrSU%3D&reserved=0", >>>> "scope": "openid", >>>> "state": "af0ifjsldkj", >>>> "nonce": "n-0S6_WzA2Mj", >>>> "max_age": 86400 >>>> } >>>> >>>> Signing it with the "RS256" algorithm results in this Request Object >>>> value (with line wraps within values for display purposes only): >>>> >>>> eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 >>>> F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl >>>> c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk >>>> JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w >>>> bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW >>>> Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog >>>> ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ >>>> ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p >>>> Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS >>>> wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg >>>> ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH >>>> sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu >>>> dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm >>>> luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs >>>> F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF >>>> KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx >>>> 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K >>>> ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG >>>> iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw >>>> >>>> Decoding the base64 of the body, we see: >>>> { >>>> "iss": "s6BhdRkqt3", >>>> "aud": >>>> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> server.example.com&data=02%7C01%7CMichael.Jones%40microsoft.com >>>> %7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d >>>> b47%7C1%7C0%7C637160775218676740&sdata=L2bwEdfW4tbnTI5FSJTCC%2B >>>> kI3EA6CqNNqZ5FzT0JnRs%3D&reserved=0", >>>> "response_type": "code id_token", >>>> "client_id": "s6BhdRkqt3", >>>> "redirect_uri": >>>> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> client.example.org%2Fcb&data=02%7C01%7CMichael.Jones%40microsof >>>> t.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7c >>>> d011db47%7C1%7C0%7C637160775218676740&sdata=XBvLTF0JuNuz7I3c7pB >>>> el0GNSN0lcYqvoHCNagAwrSU%3D&reserved=0", >>>> "scope": "openid", >>>> "state": "af0ifjsldkj", >>>> "nonce": "n-0S6_WzA2Mj", >>>> "max_age": 86400, >>>> "claims": >>>> { >>>> "userinfo": >>>> { >>>> "given_name": {"essential": true}, >>>> "nickname": null, >>>> "email": {"essential": true}, >>>> "email_verified": {"essential": true}, >>>> "picture": null >>>> }, >>>> "id_token": >>>> { >>>> "gender": null, >>>> "birthdate": {"essential": true}, >>>> "acr": {"values": ["urn:mace:incommon:iap:silver"]} >>>> } >>>> } >>>> } >>>> >>>> I'm not sure where the "claims" claim is coming from -- 6749 >>>> doesn't seem to talk about it. (Note that this example is used >>>> later on as >>>> well.) >>>> >>>> Section 5.2.1 >>>> >>>> It is possible for the Request Object to include values that are to >>>> be revealed only to the Authorization Server. As such, the >>>> "request_uri" MUST have appropriate entropy for its lifetime. For >>>> the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED >>>> that it be removed after a reasonable timeout unless access control >>>> measures are taken. >>>> >>>> It sounds like a link to >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcapability-urls%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=QtofXDXbUc2U2ieJYh0wFHXGivLFuU64GhsxCW9pD9M%3D&reserved=0 might also be useful. >>>> >>>> Section 5.2.2 >>>> >>>> Do we want to remind the reader that the other query parameters are >> just >>>> for backwards compatibility? >>>> >>>> Section 5.2.3 >>>> >>>> The following is an example of this fetch process: >>>> >>>> GET /request.jwt HTTP/1.1 >>>> Host: tfp.example.org >>>> >>>> It's useful to show good hygeine in examples; can we get the extra >>>> entropy in this request that we have in the previous example(s)? >>>> >>>> Section 6.2 >>>> >>>> The Authorization Server MUST perform the signature validation >>>> of >> the >>>> JSON Web Signature [RFC7515] signed request object. For this, the >>>> "alg" Header Parameter in its JOSE Header MUST match the value >>>> of >> the >>>> pre-registered algorithm. The signature MUST be validated against >>>> the appropriate key for that "client_id" and algorithm. >>>> >>>> Does "the pre-registered algorithm" concept exist in the specs >>>> outside of draft-ietf-oauth-jwt-bcp? >>>> >>>> Section 9 >>>> >>>> The error codes we list in Section 7 are already registered, for the >>>> OIDC usage. Do we want to say anything about that? (I guess it would >>>> be disallowed by process to try to update the existing registration >>>> to also point at this document.) >>>> >>>> Section 10 >>>> >>>> We probably also want to reference draft-ietf-oauth-jwt-bcp. >>>> >>>> Section 10.1 >>>> >>>> When sending the authorization request object through "request" >>>> parameter, it MUST either be signed using JWS [RFC7515] or encrypted >>>> using JWE [RFC7516] with then considered appropriate algorithm. >>>> >>>> Up in Section 5 we only allow (a) signed and (b) signed then >>>> encrypted; similarly, in Section 4 we reiterate "signed then >>>> encrypted". Why is >> it >>>> okay to talk about just "signed or encrypted" here? >>>> >>>> Section 10.2 >>>> >>>> (b) Verifying that the symmetric key for the JWE encryption is the >>>> correct one if the JWE is using symmetric encryption. >>>> >>>> Similarly to the previous point, you also need to check the >>>> signature, which will always be there. >>>> >>>> (d) Authorization Server is providing an endpoint that provides a >>>> Request Object URI in exchange for a Request Object. In >>>> this >>>> >>>> I don't think this is a complete sentence (and it's definitely not >>>> a parallel construction with (a)-(c)!). I think perhaps a crisp >>>> one-line summary of this method would be "Delegating the >>>> authorization check to >> a >>>> separate "Request Object to Request Object URI" endpoint on the >>>> Authorization Server". (The writing in the rest of this paragraph >> could >>>> also use an editing pass.) >>>> >>>> (e) A third party, such as a Trust Framework Provider, provides an >>>> endpoint that provides a Request Object URI in exchange for a >>>> Request Object. The same requirements as (b) above apply. In >>>> addition, the Authorization Server MUST know out-of-band that >>>> the Client utilizes the Trust Framework Operator. >>>> >>>> The Authorization Server also has to trust the third-party provider >>>> to actually do its job and not misbehave, right? >>>> >>>> Section 10.3 >>>> >>>> I'm not entirely sure what "[t]he endpoints ithat come into >>>> question in this specification" is supposed to mean -- is it just >>>> "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"? >>>> >>>> In [RFC6749], while Redirection URI is included, others are not >>>> included in the Authorization Request. As the result, the same >>>> applies to Authorization Request Object. >>>> >>>> nit: included in what? >>>> >>>> Section 10.4 >>>> >>>> It's probably also worth citing the generic URI security >>>> considerations from RFC 3986, here. >>>> >>>> Section 10.4.1 >>>> >>>> "request_uri", and (d) do not perform recursive GET on the >>>> "request_uri". >>>> >>>> nit: remove the "do" in order to make the construction parallel. >>>> >>>> Section 12.1 >>>> >>>> It is often hard for the user to find out if the personal data asked >>>> for is strictly necessary. A Trust Framework Provider can help the >>>> user by examining the Client request and comparing to the proposed >>>> processing by the Client and certifying the request. After the >>>> certification, the Client, when making an Authorization Request, can >>>> submit Authorization Request to the Trust Framework Provider to >>>> obtain the Request Object URI. >>>> >>>> side note: In my head the act of certification was the act of >>>> making >> the >>>> translation to a Request Object URI, so I'm kind of curious where >>>> my vision differs from reality. >>>> >>>> The third paragraph seems to mostly just be describing the >>>> procedure of how this flow works, which would not necessarily be >>>> specific to the privacy considerations section. >>>> >>>> Section 12.2.2 >>>> >>>> Even if the protected resource does not include a personally >>>> identifiable information, it is sometimes possible to identify the >>>> user through the Request Object URI if persistent per-user Request >>>> Object URI is used. A third party may observe it through >>>> browser >>>> >>>> nit: need an article for "persistent per-user Request Object URI" >>>> (or make it plural, as "URIs are used"). >>>> >>>> Therefore, per-user Request Object URI should be avoided. >>>> >>>> nit: I think this is better as "static per-user Requeste Object URIs" _______________________________________________ OAuth mailing list OAuth@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=55Hdt6W1uELCC%2BhFrFvOcPDN%2F5zpcSNQmJFogxAoi9g%3D&reserved=0
- [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Nat Sakimura
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Benjamin Kaduk
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Nat Sakimura
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Di… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Di… Filip Skokan