Hi Mark,
We've published https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-14.html,
which incorporates the PR. Could you please approve IANA registration of the
HTTP fields on that basis?
Thanks again for your help with the draft.
-- Mike
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Mike Jones
Sent: Tuesday, March 7, 2023 8:58 PM
To: Mark Nottingham <mnot=40mnot....@dmarc.ietf.org>
Cc: Roy Fielding <field...@gbiv.com>; Amanda Baber via RT
<drafts-expert-review-comm...@iana.org>; oauth@ietf.org
Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop
(http-fields)
Thanks - will do.
________________________________
From: Mark Nottingham
<mnot=40mnot....@dmarc.ietf.org<mailto:mnot=40mnot....@dmarc.ietf.org>>
Sent: Tuesday, March 7, 2023 7:55:29 PM
To: Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>
Cc: Brian Campbell
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; Amanda Baber
via RT
<drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>>;
oauth@ietf.org<mailto:oauth@ietf.org> <oauth@ietf.org<mailto:oauth@ietf.org>>;
Roy Fielding <field...@gbiv.com<mailto:field...@gbiv.com>>
Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop
(http-fields)
Hi Mike,
Thanks. I left a comment on the PR, suggesting two small tweaks.
Cheers,
> On 8 Mar 2023, at 2:33 pm, Mike Jones
> <Michael.Jones=40microsoft....@dmarc.ietf.org<mailto:Michael.Jones=40microsoft....@dmarc.ietf.org>>
> wrote:
>
> Hi Mark,
>
> I've created the pull request
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your
> suggestions. Please also see some additional replies below, which are
> prefixed by "Mike>".
>
> Please let us know if you'd like to see any changes to the PR before we merge
> it and publish an updated draft incorporating your suggestions.
>
> Thanks,
> -- Mike
>
> -----Original Message-----
> From: Mike Jones
> Sent: Monday, January 23, 2023 11:42 PM
> To: 'Mark Nottingham'
> <mnot=40mnot....@dmarc.ietf.org<mailto:mnot=40mnot....@dmarc.ietf.org>>;
> Brian Campbell
> <bcampbell=40pingidentity....@dmarc.ietf.org<mailto:bcampbell=40pingidentity....@dmarc.ietf.org>>
> Cc: Amanda Baber via RT
> <drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>>;
> oauth@ietf.org<mailto:oauth@ietf.org>; Roy Fielding
> <field...@gbiv.com<mailto:field...@gbiv.com>>
> Subject: RE: [OAUTH-WG] [IANA #1264432] expert review for
> draft-ietf-oauth-dpop (http-fields)
>
> 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.
>
> Mike>
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs
> does include the validation check "there is not more than one DPoP HTTP
> request header field". In the PR, I also explicitly added that the there is
> a single field value.
>
>> 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.
>
> Mike> The nonce syntax ABNF now has its own section title in the PR.
>
> 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.
>
> Mike> Per my earlier comment about the validation rules, these issues are
> both addressed in the rules.
>
>>>> - 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.
>
> Mike> I applied RFC 8792 '\' line wrapping.
>
> 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 <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
> Of Mark Nottingham
> Sent: Sunday, January 22, 2023 7:13 PM
> To: Brian Campbell
> <bcampbell=40pingidentity....@dmarc.ietf.org<mailto:bcampbell=40pingidentity....@dmarc.ietf.org>>
> Cc: Amanda Baber via RT
> <drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>>;
> oauth@ietf.org<mailto:oauth@ietf.org>; Roy Fielding
> <field...@gbiv.com<mailto:field...@gbiv.com>>
> 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=40pingidentity....@dmarc.ietf.org<mailto:bcampbell=40pingidentity....@dmarc.ietf.org>>
>> 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=40mnot....@dmarc.ietf.org<mailto:mnot=40mnot....@dmarc.ietf.org>>
>> 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-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
>>
>> 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
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
--
Mark Nottingham https://www.mnot.net/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
