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

[Mark Nottingham <[e-mail]>]

Hi David,

As far as I can tell, very little of our feedback was addressed in the latest draft.

Much of it was general review, not about the header registration; from that perspective, I note that the DPoP-Nonce header field syntax still isn't explicitly defined.

Cheers,



> On 8 Feb 2023, at 6:12 am, David Dong via RT <[e-mail]> wrote:
> 
> 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
> 

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