Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
Mike Jones <Michael.Jones@microsoft.com> Thu, 09 February 2023 03:35 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 963E3C14CE27 for <oauth@ietfa.amsl.com>; Wed, 8 Feb 2023 19:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEm5doTuYXUv for <oauth@ietfa.amsl.com>; Wed, 8 Feb 2023 19:35:52 -0800 (PST)
Received: from BN3PR00CU001-vft-obe.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [IPv6:2a01:111:f403:c110::1]) (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 414F0C14F724 for <oauth@ietf.org>; Wed, 8 Feb 2023 19:35:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NaLef/DfZdy0d3J1mIpV9aLCSzKgaHn7ZYV7X+qYOJHzCOew9g8agJemaFRFPhk0AcYnB8bHlEe2efRJO5rPNdotVY7c/fzkQG839SPjXTMUR4otAtx3Tu1GOSTtUslhNk8YJsw0S4+WNCkRfnwj0k0bapUCUA9nnj6uy0Q9V8ub97ch72ByZSgWFdgNkZqa7YBbSQE4C//R2KKCXIIcx1HYkr0j7p4fmmn8FPpkY4bpRiH/BBzgxljBGaL2r194g005WVsoqSrT3tJhEZ5X+NR25RlD9fK5hv/E2mRCd598fUS1hsuN/XiqhAT4b2kMSAlb7QycBWKnsptPLR2zZw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QiGa5EsVxsxQ/BSkjBoyNSh+3V/tekyU+GZauYWTxBY=; b=imSR6+gvZ2cyMbgtzKV0eQLwnhFoSjLLZTUBzH9hvHi4zVRFEC8WYDgCVDaoP1Kwbx3t4GpZDfErpc7jEmYze9workApYCMxZYnNy9PiWZv1ArfKXZtCUqBiF8uIEfzTP2cSHVKjvxZUxwO6RpjBUxluOC+1clzkc7Bt39uJ0bli2KKnjSpeIhc52mwBfkzJDNfpKVeOk2xUzVSsd2l9NOoTF2myi1vHQ7l4Gy8Q/fnFkMP0wlEaRbZhzLTVLfG2sFBlNlwvPwYyUiL/rvfEivsk5sXXc3mp5+MDtP+N8j3Z0uyeEMF/HvKYBXf8Gs5jSbGuE4TutgUigetOyEUxZg==
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=QiGa5EsVxsxQ/BSkjBoyNSh+3V/tekyU+GZauYWTxBY=; b=eWY7pe7t4+ctBdc5LHDPsQfesByylIGHmsOgjwHCG4QrpfmdxYtKwHanCgdO1tTIPykacS+21H2xhl3s69YlbyssVDrM6knhGFIw9p1YixHNnyidKWCtQuDIoaT71JqNqLaFqnEoNMclVWZi4TWHTaAgVyVDltT9/8hiN6tRq30=
Received: from SA0PR00MB1034.namprd00.prod.outlook.com (2603:10b6:806:132::6) by CH2PR00MB0725.namprd00.prod.outlook.com (2603:10b6:610:ad::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6123.0; Thu, 9 Feb 2023 03:35:43 +0000
Received: from SA0PR00MB1034.namprd00.prod.outlook.com ([fe80::637c:4a02:b790:37e0]) by SA0PR00MB1034.namprd00.prod.outlook.com ([fe80::637c:4a02:b790:37e0%3]) with mapi id 15.20.6123.000; Thu, 9 Feb 2023 03:35:42 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>, Amanda Baber via RT <drafts-expert-review-comment@iana.org>
CC: "oauth@ietf.org" <oauth@ietf.org>, "ryanridenour92@gmail.com" <ryanridenour92@gmail.com>, "neil.e.madden@gmail.com" <neil.e.madden@gmail.com>, Justin Richer <jricher@mit.edu>, Roy Fielding <fielding@gbiv.com>, "david@alkaline-solutions.com" <david@alkaline-solutions.com>, "bcampbell@pingidentity.com" <bcampbell@pingidentity.com>
Thread-Topic: [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
Thread-Index: AQHZOygclHu5dYBCME2Zp+Ut/ImECK7F6gMAgAAOTeI=
Date: Thu, 09 Feb 2023 03:35:42 +0000
Message-ID: <SA0PR00MB10342FC9AD719FA5C2C18EC7F5D99@SA0PR00MB1034.namprd00.prod.outlook.com>
References: <RT-Ticket-1264432@icann.org> <rt-5.0.3-41757-1674065064-1576.1264432-9-0@icann.org> <rt-5.0.3-46491-1674066633-577.1264432-9-0@icann.org> <CC85682F-99E6-4D1D-8877-A81426526429@mnot.net> <CA+k3eCT0HN+LFkQCnfP2BhhPV=NaXaReRuV-ktA1Y=LNOsZ_qw@mail.gmail.com> <2D7F6171-D53F-4F3A-B46C-CF587B2AEDCF@mnot.net> <MW4PR00MB1028EF0ECBF9572B800E01ADF5C99@MW4PR00MB1028.namprd00.prod.outlook.com> <rt-5.0.3-608687-1674546169-1593.1264432-9-0@icann.org> <rt-5.0.3-2984994-1675797139-106.1264432-9-0@icann.org> <D76B3FE8-79FB-43B3-AEE1-2B1385C271C1@mnot.net>
In-Reply-To: <D76B3FE8-79FB-43B3-AEE1-2B1385C271C1@mnot.net>
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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2023-02-09T03:33:45.5122843Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA0PR00MB1034:EE_|CH2PR00MB0725:EE_
x-ms-office365-filtering-correlation-id: 5b47141d-1286-40bf-2ded-08db0a4eb8bf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: I8oe7zJFM8xFIXxEXZXsDEQJ2H74teJ4Ms25GOWsEO6xetYseSQLrO0sHBVovi1lr14WQS5zD4mvzFSCcZzh6C4haBPOGgErjwXOWh8FgRQyDeQNYkn2tFntMOUApIHZrU9YrrZ5Z0p5KfphJk0LNBAM4gyPZPq5BgyRRv1TD0oWeIktsE1UsOvHckD84qTJhzBYMQ0qPC5xHyj+rl2D+6q3+K2GGBjzjPHOsjxPXFcXIDfVmXN2DiOusw22wHhdWy7m0k0hoMoeCx4bxEt5ae8wVdXALUzIX+Zj0s4TkNPTZHoPJCOkB/a9JV5WvPbdGr3tZhymy89PsZJFY0QlgyXR6b+hyBSl76noUacP72BaT/L84RwyOHzCHp4LJfUEfKOpvOgP2MXhe3SHvEpamLGnY3KujOfLWiVIe0DkOg0TjlCIVVJJrL1zLQCr1jb2CXYJSmqy3QHK15QqZYgpTBEAOHNPxlh+O6X8GtiDPUPVvDTGebmSn7wBRdYg8uV+1B4BYKqHmqRIEZyPgywk0h76IxhNF56fnY0fTVrW3DCB1z9vzaH7Xc3yMKBStgBSy6rClLKxn0NGZjFA2bd3VMf8/YF+22wh/gDtORE6gqD4CC9Ws1YRI4vHwzr5K+YcB375RZdgaDf+vU8RcIHaopzxXswIiTd5G49/wdqEzot23gWJCToI7ErQK1t0RweazGXHNqS9pc5NqmWQ+QylW+vW3igl9mgNcIWdBn6gNj5LqmxOVnhyeYmZkaIFl3a9iK/QqPG+ePUbMoUmGAixanooWtkz3guvrWsL5zFLo2pBjlAMGswS410iLGnfgg5WM0U4FF1At/w9YPbk+OCAGw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR00MB1034.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(396003)(346002)(39860400002)(376002)(136003)(366004)(451199018)(66899018)(10290500003)(83380400001)(33656002)(18265965005)(8990500004)(4326008)(64756008)(66446008)(8676002)(91956017)(66556008)(66476007)(76116006)(2906002)(86362001)(66946007)(38070700005)(55016003)(30864003)(38100700002)(41300700001)(122000001)(966005)(478600001)(53546011)(6506007)(54906003)(110136005)(316002)(8936002)(82950400001)(82960400001)(5660300002)(9686003)(186003)(26005)(7696005)(52536014)(71200400001)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: oVfs3VRw83t7E8qcyaActbpTcHhIsMu/Y7aiToLqvnQAqDMRrMLpBroETahyZh+KbdkB6KKXX4gPIkj4Ur6f9Y/KserCP1gV4jMZR9eX9I7aXNal/u6ioBr3BdRNSzqceTi6DWxwGBou1q+eNdSpS4shXdS5BhMcRJCKjZvfSTSbCVtmAPfbf3bGGhPQpcOXjoWR6o9RkzMpQntg7HINo7HtoD3uNx+PsepYom3PW/bXPdlIS6gpxQBoFwDCTB/iB3rloFJk/9TWr6JJaeQPkHhm5Jh12hMRAVykdYsNT8C/57LSjkNqzuWPmpwGD9ZuqZ9Tc+gxJ/icYJ0v2cq4gMqnO0Y0BOuYuvEDLc/IYL6Z6V0SzkdHEY76sbbXjPg1d0ZFXXEXehOYCLzqnGyXoXZ+kTY8JQ6uAUaW0wZN5O7pOP1vUnvlxN5XKQeIaViRQoJSbljRe7vCfpjbS3XSKwP0MBYkn5v+azCxd9l4WiefTOZHrzzwbQ6mDbe6Hp9kRXbAeW9lH3q90qTLX9CbPz2NKzeoT+jpOHRb+Qwdqcfk7v93FTm9D9v5q9DNqlDS5oVbumDIYZZBdyPRSCyaEgg+ocjBIxrS/UTP/ndJlOo/Rp11dY7ootHz/YYKqTmgz2UwwXiqfupQp8cMlhSkFP8mU6ZOLPw0lDacf1yv24dc2rW+WeZezdww29KddIn+TJU/zLjLkCLTzDk15plqyGpCjN/Gdkt1YQyV/RaSMws8IigoOFlGwrR61qsAsXPRGIiMgBsUPfR3959qvbK6LX38yMZDiWah+rCwcoEEfsSKhABocJ13dKsdn3gMxzmsVBS03MAHlCil4qLCgA66BGN5DtpWL0NfFEEGAcHJBPckY1vDFjfU/NwU+leiOXlURJV0As6T2qTndhRd3TedVvdEkOA3eDgvqB8mAJ3mEyUf4Adi0HtBP/W1C4iwTXxyVox23yYolsQ7DDgB3pPzMXnOVLCSLM4t40HnvyJtjJOZoPwZ7Q1G2wfvH72NTiktnKLmLjQAThNBpK90SreXS5TlsJAjA7C3rkugicGB1gFPz3Hfj7cUsf2KedA5b1TRdfZuVtTmZylwhPfPDlo7tsUXN59Ymk1xCbYbxiWL4T88kmvfpR4f3XDLAwnOgKzs5MV4Aw4d4kiyeuRK2+ofkF/e5OEor6BWy/C1zZWNTFLm3Ui7EcDKxdVU4y2QmrjlInWNLqGTyiMK3zwzqkQnDLeKJ5JX8YWpiHP4VB/PFXxaQqPvf2QcihHSBwFxzRIrAPs0/MVvWE8vcbrhi6PNUpysWNu3d/ZtaSHS8KXgUuRHtLP3UDN1tRbb0d2DFxbdwgs/Y8ffgoAnCh8Jufn32LnNeoUa72kH39QIMMd2xo0hfcqAsxJPqHWhIRzFU27fX1za/hvRe22VbNA4JRFwVIP7KS0sMRmn7e57aBZnNFVAEmTm4se+r6fwEDt9Bu9WPesO2++qcDuXq+ciMqdc/9eDbFbAfkrM6aNumfwuiPHlDwpRmCmxEEgqhsvDtaOncUC+lSWAv55y1gx8J4OgbI7LnxPV0M9efBTfKftxTlhR7WjNpoKWYB1Xy1CVGSxh1EjEB95fvyT474L/hsMwdA==
Content-Type: multipart/alternative; boundary="_000_SA0PR00MB10342FC9AD719FA5C2C18EC7F5D99SA0PR00MB1034namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR00MB1034.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b47141d-1286-40bf-2ded-08db0a4eb8bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2023 03:35:42.5852 (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: Zkt8ZSWOd4Rzwo8uXeQRv8g35RGPhxRSIjhMfChRJVH+XLxDPMNqyQQ7Uj+Geo5UpyrkwXKIh7Zjca7cnttwNA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0725
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QhWXW2c4rT6wXQgOY3NvFjuqO7o>
Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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, 09 Feb 2023 03:35:56 -0000
Per my reply on your review thread, Mark, I plan to make those updates shortly. Thanks again for your useful review. Best wishes, -- Mike ________________________________ From: Mark Nottingham <mnot@mnot.net> Sent: Thursday, February 9, 2023 11:42:34 AM To: Amanda Baber via RT <drafts-expert-review-comment@iana.org> Cc: oauth@ietf.org <oauth@ietf.org>; ryanridenour92@gmail.com <ryanridenour92@gmail.com>; neil.e.madden@gmail.com <neil.e.madden@gmail.com>; Mike Jones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mit.edu>; Roy Fielding <fielding@gbiv.com>; david@alkaline-solutions.com <david@alkaline-solutions.com>; bcampbell@pingidentity.com <bcampbell@pingidentity.com> Subject: Re: [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields) Hi David, As far as I can tell, very little of our feedback was addressed in the latest draft. Much of it was general review, not about the header registration; from that perspective, I note that the DPoP-Nonce header field syntax still isn't explicitly defined. Cheers, > On 8 Feb 2023, at 6:12 am, David Dong via RT <drafts-expert-review-comment@iana.org> wrote: > > Dear Mark / Roy, > > We see that this document has been updated; could you please let us know if this is OK or if you have further comments? > > Thank you. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > > Best regards, > > David Dong > IANA Services Specialist > > On Tue Jan 24 07:42:49 2023, Michael.Jones@microsoft.com wrote: >> Hi Mark, >> >> Like Brian, I appreciate your detailed review. My thoughts on the >> review points are interleaved with the discussion text below. >> >>> Keep in mind that HTTP header fields are basically sets of >>> constrained octets with weird combination rules; if you don't use SF, >>> you should be specifying (for example) what happens when two header >>> values (and/or fields) are present (as per below). SF does a lot of >>> the legwork here, even if from a type system standpoint it's not a >>> perfect fit. >> >> I agree that we should specify these things - probably using language >> parallel to that in the SF draft, where appropriate. I also share >> your assessment that, unfortunately, the SF type system is not an >> ideal fit for the DPoP headers. >> >>> That said, personally I'd deconstruct the JWT and convey it as >>> separate binary values, so that if binary structured headers ever >>> does catch on, it can get the perf/compactness advantages of that. >> >> Deconstructing the JWT would entail defining a new JWT serialization >> (representation). Currently there is exactly one JWT serialization >> and this specification uses it. I suspect developers would like us to >> keep it that way. >> >> Only one of the fields of a signed JWT is actually binary (the >> signature); the header and payload are JSON. All are encoded using >> the base64 URL-safe character set (letters, numbers, -, and _ with no >> trailing =s) for safe transmission with encoded fields separated by >> the also URL-safe character period. Furthermore, the signature is >> computed over the base64url-encoded values of the first two fields >> with a period between them. The base64url encoding and concatenation >> is integral to the computation of the signature. Any different >> serialization would still have to perform these computations. >> >> (Note also that some JWTs have three base64url-encoded fields >> separated by period characters and some have five, depending upon >> whether they are signed (three) or encrypted (five); deconstructing a >> value with a variable number of non-independent fields seems like >> significant unnecessary complexity.) >> >>>> ABNF syntax for the nonce value is provided at >>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop- >>>> 12.html#section-8-9 along with the description of its use in the >>>> DPoP exchange. >> >>> I see. It'd be better if it were explicitly called out as the syntax >>> for the field (ideally with a section title that makes this clear), >>> rather than making the reader do that work. >> >> I'm fine with us making the editorial improvement that you suggest. >> >>>> I believe that the SF String type would accommodate the content we >>>> intended to allow servers to use for the nonce (it's basically a >>>> server chosen value that the client treats as opaque and sends back >>>> in subsequent DPoP proof JWTs). However, that would be a breaking >>>> change, which shouldn't be undertaken lightly. >> >>> Right. It really depends on how advanced deployment of this is; if >>> there's only modest production use, it may still be reasonable to >>> make such a change (especially keeping in mind that people who adopt >>> drafts need to bear the consequences of doing so). >> >> I'm with Brian here. I don't believe that the cost/benefit tradeoff >> of the breaking change versus using the SF String type is a good one. >> >>> To be concrete -- what should an implementation do when it receives >>> two DPoP header fields, both with valid values? When it receives one >>> with two comma-separated values? >> >> These are great questions. I'll commit to us answering them in the >> next draft. >> >>>>> - The long line-wrapped example in Section 4.1 would benefit from >>>>> RFC8792 encoding. In HTTP, a line-wrapped field like the one shown >>>>> has whitespace inserted between each line, which is problematic >>>>> here. >>> >>>> This is a bit of a stylistic preference thing. That example and >>>> others in the draft are intentionally similar (with a note about >>>> line breaks and extra space being for display purposes) to closely >>>> related and referenced documents like RFC7515, RFC7519, and RFC6749. >>>> The examples from these RFCs seem to have worked well for >>>> readers/implementers in practice, and so we'd prefer to keep the >>>> formatting conventions in this draft the same as in those. >>> >>> Consistency between documents that specify HTTP protocol elements is >>> important, so I'd ask you to reconsider; while the community that has >>> been developing and implementing the specification may already be >>> familiar with it, aligning with other documents makes it easier for a >>> broader audience. See, for example, the Signatures specification: >>> https://httpwg.org/http-extensions/draft-ietf-httpbis-message- >>> signatures.html#name-request-response-signature- >> >> I'm fine with us making this editorial change to the examples, since >> you feel that this would help some readers of the specification. >> >> In closing, I'll say that I appreciate that the SF spec has done heavy >> lifting that we would do well to take advantage of. I appreciate you >> bringing it to our attention. That said, since SF's type system does >> not cleanly map to some of the DPoP fields, and since the use of SF is >> optional, I personally believe that the best route for us to take >> advantage of SF is to study it and ensure that the questions that SF >> answers for the field types that it defines are also answered for the >> fields defined by the DPoP draft. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Mark Nottingham >> Sent: Sunday, January 22, 2023 7:13 PM >> To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> >> Cc: Amanda Baber via RT <drafts-expert-review-comment@iana.org>; >> oauth@ietf.org; Roy Fielding <fielding@gbiv.com> >> Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf- >> oauth-dpop (http-fields) >> >> Hi Brian, >> >>> On 21 Jan 2023, at 5:46 am, Brian Campbell >>> <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote: >>> >>> >>> Hi Mark, >>> >>> Thanks for the review and feedback. I am aware of HTTP Structured >>> Fields and certainly see value in it - even using it in some other >>> work in which I'm involved. However, I'm unsure of its fit or utility >>> for this draft. With that said, I've tried to reply more specifically >>> to your comments inline below. >>> >>> >>> On Wed, Jan 18, 2023 at 3:32 PM Mark Nottingham >>> <mnot=40mnot.net@dmarc.ietf.org> wrote: >>> A few things caught my eye in this document: >>> >>> - Section 4.1 defines the DPoP header field as a JWT, which (as I >>> understand it) is a base64-encoded string. If that's the case, I'd >>> recommend making it a Structured Field Item (see RFC8941 s 3.3) with >>> a fixed type of Byte Sequence (s 3.3.5). That will require changing >>> the syntax to add a prefix and suffix of ":". >>> >>> As Justin pointed out, a JWT is three Base64url encoded segments >>> delimited by the `.` period character, which means it can't be a SF >>> Byte Sequence. As DW pointed out, a JWT just happens to always start >>> with a letter because the first segment is always encoded JSON, so >>> will always start with 'ey'. So the DPoP header field value does just >>> happen to fit the SF Token syntax, But the SF Token syntax does very >>> little regarding the validity of the JWT. >> >> Keep in mind that HTTP header fields are basically sets of constrained >> octets with weird combination rules; if you don't use SF, you should >> be specifying (for example) what happens when two header values >> (and/or fields) are present (as per below). SF does a lot of the >> legwork here, even if from a type system standpoint it's not a perfect >> fit. >> >> That said, personally I'd deconstruct the JWT and convey it as >> separate binary values, so that if binary structured headers ever does >> catch on, it can get the perf/compactness advantages of that. >> >> >>> - The DPoP-Nonce header field's syntax isn't obviously specified. It >>> should be. I'd suggest a Structured Field Item with a fixed type of >>> String (RFC 8941 s 3.3.3), which would surrounding the value with >>> quotes. >>> >>> ABNF syntax for the nonce value is provided at >>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop- >>> 12.html#section-8-9 along with the description of its use in the DPoP >>> exchange. >> >> I see. It'd be better if it were explicitly called out as the syntax >> for the field (ideally with a section title that makes this clear), >> rather than making the reader do that work. >> >> >>> I believe that the SF String type would accommodate the content we >>> intended to allow servers to use for the nonce (it's basically a >>> server chosen value that the client treats as opaque and sends back >>> in subsequent DPoP proof JWTs). However, that would be a breaking >>> change, which shouldn't be undertaken lightly. >> >> Right. It really depends on how advanced deployment of this is; if >> there's only modest production use, it may still be reasonable to make >> such a change (especially keeping in mind that people who adopt drafts >> need to bear the consequences of doing so). >> >> >>> - Neither header has interoperable parsing or serialisation >>> specified; divergent error handling may cause interoperability >>> problems. Adopting Structured Fields would address this. >>> >>> Both are composed of a narrow set of printable ASCII with parsing, >>> validation, usage, and error handling specified at the application >>> layer. I'm not going to claim that it's perfect by any means. But >>> those interoperability problems seem conjectural and it's not obvious >>> that adopting Structured Fields would add value in the context of >>> this draft. >> >> To be concrete -- what should an implementation do when it receives >> two DPoP header fields, both with valid values? When it receives one >> with two comma-separated values? >> >> >>> - See RFC9110 s 16.3.2 for things that should be considered when >>> defining new HTTP fields. I suspect that the document needs to be >>> more explicit about at least some of these items. Adopting Structured >>> Fields would address some (but not all) of these questions. >>> >>> The authors (on-behalf-of and with the help of the WG) have >>> endeavored to touch on all the considerations needed to ensure >>> interoperability of the protocol overall as well as HTTP related >>> (e.g. caching, applicability to request/response, prohibiting >>> multiple occurrences, scope of applicability). However, the group >>> clearly does not have your depth of HTTP expertise so may well have >>> missed something. If that's the case, it would be very helpful for >>> specifics to be raised. >>> >>> - See also <https://httpwg.org/admin/editors/style-guide#header-and- >>> trailer-fields> for the preferred editorial style when defining new >>> HTTP fields. >>> >>> - The long line-wrapped example in Section 4.1 would benefit from >>> RFC8792 encoding. In HTTP, a line-wrapped field like the one shown >>> has whitespace inserted between each line, which is problematic here. >>> >>> This is a bit of a stylistic preference thing. That example and >>> others in the draft are intentionally similar (with a note about line >>> breaks and extra space being for display purposes) to closely related >>> and referenced documents like RFC7515, RFC7519, and RFC6749. The >>> examples from these RFCs seem to have worked well for >>> readers/implementers in practice, and so we'd prefer to keep the >>> formatting conventions in this draft the same as in those. >> >> Consistency between documents that specify HTTP protocol elements is >> important, so I'd ask you to reconsider; while the community that has >> been developing and implementing the specification may already be >> familiar with it, aligning with other documents makes it easier for a >> broader audience. See, for example, the Signatures specification: >> https://httpwg.org/http-extensions/draft-ietf-httpbis-message- >> signatures.html#name-request-response-signature- >> >> Cheers, >> >> >>> >>> Cheers, >>> >>> >>> >>> >>>> On 19 Jan 2023, at 5:30 am, David Dong via RT <drafts-expert-review- >>>> comment@iana.org> wrote: >>>> >>>> Dear Mark Nottingham and Roy Fielding (cc: oauth WG), >>>> >>>> As the designated experts for the http-fields registry, can you >>>> review the proposed registration in draft-ietf-oauth-dpop for us? >>>> Please see: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >>>> >>>> The due date is February 1st, 2023. >>>> >>>> If this is OK, when the IESG approves the document for publication, >>>> we'll make the registration at >>>> >>>> https://www.iana.org/assignments/http-fields/http-fields.xhtml >>>> >>>> We'll wait for both reviewers to respond unless you tell us >>>> otherwise. >>>> >>>> With thanks, >>>> >>>> David Dong >>>> IANA Services Specialist >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). >>> Any review, use, distribution or disclosure by others is strictly >>> prohibited. If you have received this communication in error, please >>> notify the sender immediately by e-mail and delete the message and >>> any file attachments from your computer. Thank you. >> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Mark Nottingham https://www.mnot.net/
- [OAUTH-WG] [IANA #1264432] expert review for draf… David Dong via RT
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Justin Richer
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham
- Re: [OAUTH-WG] [IANA #1264432] expert review for … David Waite
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Brian Campbell
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Neil Madden
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Ryan Ridenour
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mike Jones
- [OAUTH-WG] [IANA #1264432] expert review for draf… David Dong via RT
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mike Jones
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mike Jones
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mike Jones
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mike Jones
- Re: [OAUTH-WG] [IANA #1264432] expert review for … Mark Nottingham