Re: [Gen-art] Telechat Review of draft-ietf-httpauth-extension-08

[Jari Arkko <[e-mail]>]

Matt: Many thanks for your detailed review. Much appreciated.

Authors, can you take these notes into account?

Jari

On 01 Sep 2016, at 05:15, Matt Miller <[e-mail]> wrote:

> * 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".