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

[Mark Nottingham <[e-mail]>]

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/