Hi Reese, and thanks for your review!
I've landed this commit based on your comments:
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@xxxxxxxx> 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 anentry 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
