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

[David Dong via RT <[e-mail]>]

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, [e-mail] 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 <[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 <drafts-expert-review-
> >> [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