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