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: =?utf-8?B?NVd0NmZIRFZwYXRBenBmVHR2OWh3QmtJdUs0OXJncUhVQzluRDZjdldqcEVH?= =?utf-8?B?MVRVcmtoMGlzNVEvVWcrc1lDcVdrNmliZDdBVTJ5K0dlUUpwb0dFVEhvMEE4?= =?utf-8?B?RXg5NEt2cDZWVjZpeXhNQzA5RUx2bUpWRncvcTltbGExR0Qrbis2a1N0ZXBJ?= =?utf-8?B?YzU3TUZSa1RUaUVIRGxxS1FNRkE2Z0hlWmdWQTc0QytPcGJSMnZKKy9BNUNm?= =?utf-8?B?Rk9Ka0lHRFBMcG9NRmo5NXNIUHdMdVErbnd4cXVXNkxQRk5GM0RZYnJiaWw0?= =?utf-8?B?ME5wSEh1NzNXTDhPV3BEYUp2QlZnbG9mV254eW5Nb0JMajRhK0lPQm1RMkNC?= =?utf-8?B?ZVRSeXJ6cmU3RTZab1g1Z1hoeGxldURrK1hBb2d3eHJwZXFqZ0txaEdHM093?= =?utf-8?B?TTVKaE1yWk1DUG9LMC9INm5vbVlNRm13dWpxSXZPVXdEZEg5R01nZi9SbUd6?= =?utf-8?B?dlc5ZG51RHNxK1ZlVmQ3ODdVTkNFbmREamtzVFdtcWx6Z21XRkhmWXRYekFw?= =?utf-8?B?NGdRaUxSK01UMmwxODE2VjAvN1hyckwwcGVDb0lWeW1jZkRPM0E2WWkzS3BJ?= =?utf-8?B?c1RZUmJIbHlIYkI1UHZ0QUlIRzd3YndLZktvV2Q5M1l2SHpnOC91TlpGb3FM?= =?utf-8?B?Tyt0clhvTDRlaVNBQkN5eUkxMXNKRlpibURRSmcvT0RLU0YzVW15R3E4aWtY?= =?utf-8?B?NVZSMGJ0clpmN0d4ZjhWQjE3SDAxS0JVWVU5UjdENzE2QWpiUzJ5VHMrTFIw?= =?utf-8?B?UHJ1ZXNhTkhrNVh5eTIrY01rZ2s0Z1RNWDY1M1pVQng0Z2lCTm5LMnU0RXJu?= =?utf-8?B?b1orTWtuc0pxMm8rbVI4ZFAzMjJ4Zy9lUDZxbGp1aElnNkdpVXZ1TFo5KzNI?= =?utf-8?B?T0lIcW5EdkdxSGs5SjRVd0xEd3B2eXlKOWdhaVBadyt6cW42UjBGMkJUR0p2?= =?utf-8?B?MnhUVXBiUEtVNVZYcTZWNEE4UlJjZmkxa3NmWWpJMTZiak52cW40b0N4OXNa?= =?utf-8?B?VWkvSmNqSnpSVlJGaHFqS25OV2h3SHdobW9MdW1EVHlqVnNNOFFxRDBYZ3JF?= =?utf-8?B?Zm8wUUlxa2ZuaHA3ZmNmaEN6YUtqdE5DYUVQSWxZOC9WajYyb1NDYnp6TUNy?= =?utf-8?B?ZFdTVGZCVmdBTFNNZnVpS01oS2RxTmI4ZHZyNVMrRW1LTjNZNjFkWU5YTFNp?= =?utf-8?B?WkRXbVhVM3FKRVpQdUljaWdnRFdEQlNXUUJTRi9YdDluQXRUN2pHMTExV1Vj?= =?utf-8?B?dzNIUm5XT1R3Z2JWK0llSUFIamttZ1BkS0pHL0tXeEVZZDdaUT09?=
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>om>; Benjamin Kaduk <kaduk@mit.edu>
Cc: oauth <oauth@ietf.org>rg>; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>rg>; 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>rg>:
>>>
>>>> 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&amp;data=02%7C01
>> %7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7
>> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sd
>> ata=6ZSWckU9w8S1oDEUz%2BgKPguV2UFjyfzKrOIt9V4qXRQ%3D&amp;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&amp;data=02%
>>>> 7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a659
>>>> 6612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63716077521867674
>>>> 0&amp;sdata=eaeSN%2BgKTCDiy502GPNm459JjYuOj5o77Tp%2B6QAw3HY%3D&amp;
>>>> 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&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sdata=L2bwEdfW4tbnTI5FSJTCC%2BkI3EA6CqNNqZ5FzT0JnRs%3D&amp;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&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sdata=XBvLTF0JuNuz7I3c7pBel0GNSN0lcYqvoHCNagAwrSU%3D&amp;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&amp;data=02%7C01%7CMichael.Jones%40microsoft.com
>>>> %7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d
>>>> b47%7C1%7C0%7C637160775218676740&amp;sdata=L2bwEdfW4tbnTI5FSJTCC%2B
>>>> kI3EA6CqNNqZ5FzT0JnRs%3D&amp;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&amp;data=02%7C01%7CMichael.Jones%40microsof
>>>> t.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7c
>>>> d011db47%7C1%7C0%7C637160775218676740&amp;sdata=XBvLTF0JuNuz7I3c7pB
>>>> el0GNSN0lcYqvoHCNagAwrSU%3D&amp;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&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sdata=QtofXDXbUc2U2ieJYh0wFHXGivLFuU64GhsxCW9pD9M%3D&amp;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&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sdata=55Hdt6W1uELCC%2BhFrFvOcPDN%2F5zpcSNQmJFogxAoi9g%3D&amp;reserved=0