[http-auth] Jari Arkko's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)

["Jari Arkko" <[e-mail]>]

Jari Arkko has entered the following ballot position for
draft-ietf-httpauth-extension-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Comments from the Gen-ART reviewer Matt Miller should be taken into
account, see below. I considered making a Discuss about the reference to
Authentication-Info RFC but I trust that you guys will make the correct
modifications. Thanks!

----

* There is at least a couple of mentions of the
"Authentication-Info" header, but no reference to RFC 7615 in which
it is defined.  I think an informational reference is warranted
here.

* Just reading sections 4.5. "Location-when-logout parameter" and
4.6. "Logout-timeout parameter", it is unclear how these are meant
to interact to inform a client the user's authentication session.
Frankly, I think the text in section 4.5 is too vague about how
a client can detect termination of a user's authenticated session,
and could use more of a hint on how "logout-timeout" is involved
to accomplish it. At the least, I think both sections 4.5. and
4.6. need pointers to section 5. to help readers get a
sense of how to apply them.

* In section 4.7. "Username parameter", I think there should be
an explicit pointer to the Security Considerations to warn about
potential issues this parameter presents.  I also recommend
separating that portion of the Security Considerations about
"username" into its own subsection to make such a callout
better.

* Since this document is acknowledging that cookies are used for
authentication, and

Nits/editorial comments:

* In section 2.1. "Terms for describing authentication protocol
flow", the word "distinguishable" should instead be "distinguished"
in the phrase "it can't be distinguishable from a non-authenticated
response."

* In section 3. "Optional Authentication", the word "be" is missing
in "Optional-WWW-Authenticate header MUST NOT sent on 401
responses".

* In section 3.1. "Note on Optional-WWW-Authenticate and use of
WWW-Authenticate header with non-401 status", the word "is" should
be replaced with "are" in the phrase "clients which is unaware of
this extension will ignore the header".

* Also in section 3.1., the word "authentications" should be
"authentication" in the phrase "secondary fallback method of
authentications".

* Also in section 3.1., the word "ignores" should be "ignore" in
the phrase "just ignores the WWW-Authenticate headers".

* Also in section 3.1., all instances of the word "implementer"
should be replaced with "implementers" in the phrase "the authors
propose implementer of the standard HTTP/1.1 specification
(especially implementer of this extension)".

* In section 4. "Authentication-Control header", the word "an"
should be "a" in the phrase "and MUST be sent in an plain".

* In section 4.1. "Non-ASCII extended header parameters", the
interoperability note as a number of grammatical challenges.
I believe the following addresses the grammar issues while
retaining its meaning:

   """
   Interoperability note: [RFC7235], Section 2.2, defines the "realm"
   authentication parameter which cannot be replaced by the "realm*"
   extend parameter.  It means that the use of non-ASCII values for an
   authentication realm is not the defined behavior in HTTP.
   Unfortunately, some people currently use a non-ASCII realm parameter
   in reality, but even its encoding scheme is not well-defined.
   Given this background, this document does not specify how to handle
   a non-ASCII "realm" parameter in the extended header fields.  If
   needed, the authors propose to use a non-extended "realm" parameter
   form, with a wish for maximum interoperability.
   """

* In section 4.2. "Auth-style parameter", the word "preferences"
should be replaced with "preference" in the phrase "server's
preferences for user interface behavior".

* In section .4.4. "No-auth parameter", the word "authentications"
should be replaced with "authentication" in the phrase "content is
desired before authentications".

* In section 4.6. "Logout-timeout parameter", the word "from" should
be removed in the phrase "has passed since from the time this header
was received".

* In section 5.3. "When to use Cookies", the first sentence has some
grammatical challenges, which I believe the following text addresses:

   """
   In current Web sites using form-based authentication, Cookies
   [RFC6265] are used for managing both authorization and
   application sessions.
   """

* In section 5.4. "Parallel deployment with Form/Cookie
authentications", the META tag example should be "<META
http-equiv="refresh" ...>" instead of ">META http-equiv="refresh"
...<".

* In section 7. "IANA Considerations", the word "documents" should
be "document" in the phrase "a publicly-accessible documents".