I thought we already had; if not, approved. Cheers,
> On 9 Mar 2023, at 12:32 pm, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > Hi Mark, > We’ve published > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-14.html, which > incorporates the PR. Could you please approve IANA registration of the HTTP > fields on that basis? > Thanks again for your help with the draft. > -- Mike > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Mike Jones > Sent: Tuesday, March 7, 2023 8:58 PM > To: Mark Nottingham <mnot=40mnot....@dmarc.ietf.org> > Cc: Roy Fielding <field...@gbiv.com>; Amanda Baber via RT > <drafts-expert-review-comm...@iana.org>; oauth@ietf.org > Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for > draft-ietf-oauth-dpop (http-fields) > Thanks - will do. > From: Mark Nottingham <mnot=40mnot....@dmarc.ietf.org> > Sent: Tuesday, March 7, 2023 7:55:29 PM > To: Mike Jones <michael.jo...@microsoft.com> > Cc: Brian Campbell <bcampb...@pingidentity.com>; Amanda Baber via RT > <drafts-expert-review-comm...@iana.org>; oauth@ietf.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 Mike, > > Thanks. I left a comment on the PR, suggesting two small tweaks. > > Cheers, > > > > On 8 Mar 2023, at 2:33 pm, Mike Jones > > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > > > Hi Mark, > > > > I've created the pull request > > https://github.com/danielfett/draft-dpop/pull/180 to incorporate your > > suggestions. Please also see some additional replies below, which are > > prefixed by "Mike>". > > > > Please let us know if you'd like to see any changes to the PR before we > > merge it and publish an updated draft incorporating your suggestions. > > > > Thanks, > > -- Mike > > > > -----Original Message----- > > From: Mike Jones > > Sent: Monday, January 23, 2023 11:42 PM > > To: 'Mark Nottingham' <mnot=40mnot....@dmarc.ietf.org>; 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 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. > > > > Mike> > > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs > > does include the validation check "there is not more than one DPoP HTTP > > request header field". In the PR, I also explicitly added that the there > > is a single field value. > > > >> 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. > > > > Mike> The nonce syntax ABNF now has its own section title in the PR. > > > > 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. > > > > Mike> Per my earlier comment about the validation rules, these issues are > > both addressed in the rules. > > > >>>> - 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. > > > > Mike> I applied RFC 8792 '\' line wrapping. > > > > 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/ -- Mark Nottingham https://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
