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 <m...@mnot.net> Sent: Thursday, February 9, 2023 11:42:34 AM To: Amanda Baber via RT <drafts-expert-review-comm...@iana.org> Cc: oauth@ietf.org <oauth@ietf.org>; ryanridenou...@gmail.com <ryanridenou...@gmail.com>; neil.e.mad...@gmail.com <neil.e.mad...@gmail.com>; Mike Jones <michael.jo...@microsoft.com>; Justin Richer <jric...@mit.edu>; Roy Fielding <field...@gbiv.com>; da...@alkaline-solutions.com <da...@alkaline-solutions.com>; bcampb...@pingidentity.com <bcampb...@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-comm...@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.jo...@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-boun...@ietf.org> On Behalf Of Mark Nottingham >> Sent: Sunday, January 22, 2023 7:13 PM >> To: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> >> Cc: Amanda Baber via RT <drafts-expert-review-comm...@iana.org>; >> oauth@ietf.org; Roy Fielding <field...@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....@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....@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- >>>> comm...@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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
