Hi Mark, a quick note on one item:

- 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 ":".

A JWT cannot be sent as a Byte Sequence because it is not :just: Base64. 
Specifically, a JWT in compact serialization (which is what’s intended here) is 
encoded as three sets of Base64url separated by periods “.”, which are outside 
the base64URL alphabet. If anything, this fits the “token68” rule, which I 
:think: means that it could be defined as sf-token here, to make it a fully 
structured field, but I’m not entirely sure.

I’ll let the document authors chime in on other comments.

 — Justin



- 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.

- Neither header has interoperable parsing or serialisation specified; 
divergent error handling may cause interoperability problems. Adopting 
Structured Fields would address this.

- 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.

- 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.

Cheers,




On 19 Jan 2023, at 5:30 am, David Dong via RT 
<drafts-expert-review-comm...@iana.org<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to