Re: Genart last call review of draft-ietf-httpbis-unprompted-auth-10

Hi Reese, and thanks for your review!
I've landed this commit based on your comments:
https://github.com/httpwg/http-extensions/commit/6cf4a202c6034888123383d10239e13d639d71d4
I'll submit a new draft revision incorporating it once IETF LC is done.
More detailed responses inline.
David

On Mon, Sep 9, 2024 at 4:30 PM Reese Enghardt via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Reese Enghardt
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-httpbis-unprompted-auth-10
> Reviewer: Reese Enghardt
> Review Date: 2024-09-09
> IETF LC End Date: 2024-09-11
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is fairly clear and concise. I have a few
> suggestions to
> make the document more accessible.
>
> Major issues: None.
>
> Minor issues:
>
> Section 1:
>
> "Members of less well-defined communities might use more ephemeral keys to
> acquire access to geography- or capability-specific resources, as issued
> by an
> entity whose user base is larger than the available resources can support
> (by
> having that entity metering the availability of keys temporally or
> geographically)."
>
> Does this sentence introduce a new use case that is separate from the
> company
> use case described in the previous sentence, or is it a similar use case
> but
> under different circumstances? It is not quite clear to me what a "member
> of a
> less well-defined community" is, I assume "less well-defined than
> employees of
> a company"? Are users within a certain geography or with devices with
> specific
> capabilities an example? What does "larger than the available resources can
> support" mean here, is this part tied to the new use case or circumstances
> described before? Please consider rephrasing this sentence to make it
> clearer.
>

Good point. The intent was for this to be a separate example. I've rephrased
by adding "As another example, " to clarify this.

Section 2:
>
> As a non-expert, I would appreciate a high-level description of the entire
> flow
> here. The client generates the data to be signed and then sends the
> signature,
> and the details are in Sections 3 and 4, but what happens afterwards?
> Please
> consider adding one or two sentences to explain the basic principle of how
> the
> scheme works, i.e., how the server is then able to authenticate the client.
>

Agreed. Added <<Once the
server receives these, it can check whether the signature validates against
an
entry in its database of known keys. The server can then use the validation
result to influence its response to the client, for example by restricting
access to certain resources.>>

Section 5:
>
> As this section is titled "Example", I expected a full example of the
> scheme,
> but it looks like this is just an example of a request. Please consider
> turning
> this section into a full example of how the scheme works, potentially
> moving it
> to after Section 6.
>

The response isn't particularly interesting here, since there's no header
being
sent back by this mechanism. This is an example of the main on-the-wire
portion of this spec. I thought through explaining how the server reacts to
it,
but it ended up being redundant with other portions of text.

Nits/editorial comments: None.
>