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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
