Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

[Mark Nottingham <[e-mail]>]

I thought we already had; if not, approved.

Cheers,


> On 9 Mar 2023, at 12:32 pm, Mike Jones <Michael.Jones=[e-mail]> 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 <[e-mail]> On Behalf Of Mike Jones
> Sent: Tuesday, March 7, 2023 8:58 PM
> To: Mark Nottingham <mnot=[e-mail]>
> Cc: Roy Fielding <[e-mail]>; Amanda Baber via RT <[e-mail]>; [e-mail]
> Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
>  Thanks - will do. 
>  From: Mark Nottingham <mnot=[e-mail]>
> Sent: Tuesday, March 7, 2023 7:55:29 PM
> To: Mike Jones <[e-mail]>
> Cc: Brian Campbell <[e-mail]>; Amanda Baber via RT <[e-mail]>; [e-mail] <[e-mail]>; Roy Fielding <[e-mail]>
> 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=[e-mail]> 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=[e-mail]>; Brian Campbell <bcampbell=[e-mail]>
> > Cc: Amanda Baber via RT <[e-mail]>; [e-mail]; Roy Fielding <[e-mail]>
> > 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 <[e-mail]> On Behalf Of Mark Nottingham
> > Sent: Sunday, January 22, 2023 7:13 PM
> > To: Brian Campbell <bcampbell=[e-mail]>
> > Cc: Amanda Baber via RT <[e-mail]>; [e-mail]; Roy Fielding <[e-mail]>
> > 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=[e-mail]> 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=[e-mail]> 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 <[e-mail]> 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
> >> [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> --
> Mark Nottingham   https://www.mnot.net/


--
Mark Nottingham   https://www.mnot.net/