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

["Alexey Melnikov" <[e-mail]>]

Alexey Melnikov 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:
----------------------------------------------------------------------

In Section 2.2:

    bare-token        = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_")

Did you intent to allow leading "-" (and possibly "_") above?
As you are using "-<bare-token>.<domain-name>" for private extensions,
I think the ABNF is not right. I think you meant:

    lead-token-char   = (%x30-39 / %x41-5A / %x61-7A / "_")
    bare-token        = lead-token-char *(%x30-39 / %x41-5A / %x61-7A /
"-" / "_")


In Section 3, last paragraph:

   Support of this header is OPTIONAL; clients MAY also implement this
   extension only for some selected authentication schemes.  New
   authentication schemes can make support of the optional
   authentication mandatory by its specification, though.

I don't think this paragraph is needed, as this is granted, because
support for any
extension like specified in this document is optional. So I suggest
deleting it.


Section 3.1:

   I am still not convinced that Optional-WWW-Authenticate is needed,
   but the section provides a reasonable overview of the current
situation.


In Section 4:

   Support of this header is OPTIONAL, and clients MAY choose any subset
   of these parameters to be supported.  The set of supported parameters
   MAY also be authentication scheme-dependent.  However, some
   authentication schemes can require mandatory/recommended support for
   some or all of the features provided in this header.

As above, I don't think this paragraph is needed.

4.4.  No-auth parameter

   This parameter SHOULD NOT be used along with the
   location-when-unauthenticated parameter.

Why is this only a SHOULD NOT (or to rephrase it: what are possible
conditions for violating this)?

   If both were supplied,
   clients MAY choose which one is to be honored.

I would rather you pick one behaviour in order to improve
interoperability.

In 4.5:

   When the user requests termination of an authentication period, and
   if the client currently displays a page supplied by a response with
   this parameter, the client will be redirected to the specified
   location by a new GET request (as if it received a 303 response).

Is this value advisory? Should the client go to this page automatically
or would the server redirect it? If the latter, why does this need to be
told to the client?

   The log-out operation (e.g. erasing memories of user name,
   authentication credential and all related one-time credentials such
   as nonce or keys) SHOULD occur before processing a redirection.

4.6.  Logout-timeout parameter

   The parameter "logout-timeout", when contained in a successfully-
   authenticated response, means that any authentication credentials and
   state related to the current protection space are to be discarded if
   a time specified in this header (in seconds) has passed since from
   the time this header was received.  The value MUST be an integer.  As
   a special case, the value 0 means that the client is requested to
   immediately log-out from the current authentication space and revert
   to an unauthenticated status.

It sounds like this is not just a request, but the client will be logged
out. If this is correct,
then you should reword this, for example:

   As a special case, the value 0 means that the server is logging the
client
   out immediately from the current authentication space and that the
client
   is now returns to unauthenticated state.