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

[Brian Campbell <[e-mail]>]

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.



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



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



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



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