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

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.

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.

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.

Nits/editorial comments: None.

Received on Monday, 9 September 2024 23:30:41 UTC