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

[大岩寛 <[e-mail]>]

Thank you very much for your comments.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with Stephen that this document must include the registration template
> as per Section 4.2.1 of BCP 90 (RFC 3864).

Yes, I'll do it.

> 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 /
> "-" / "_")

Thank you for notifying it.  We'll remove - and _ from the initial character.

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

Of course, Experimental thing is always optional, as a starting point.
But if we have two or more OPTIONALs, we need to clarify whether these are
"one-by-one" or "all-or-nothing".
What we wanted to assure here is that
 - It's optional support may vary between schemes.
   For example, an implementation MAY choose to support it in Digest but not in Basic.
   Also, implementation MAY choose only to support "username" and not "logout-timeout".
   In this point, it's "one-by-one" OPTIONAL.

 - We have another "experimental" draft which normatively refers this draft and
   requires implementation of this extension.
   It's a kind of "all-or-nothing" (more precisely, "A implies B").
   It does not contradict with the "experimental status" of this draft.

These need a little more clarification than just saying "OPTIONAL" or "Experimental".
If you have some solution to resolve it nicely, it's really appreciated.

> 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)?
These are contradicting requests for the same scope and
using them together is meaningless.  So below,

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

we'll change these two clauses together to define precedence order between them.

> 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?

We'll clarify it.  It's client's role to go to that page. 
In client-initiated logging-out, the server cannot initiate redirect
unless the client takes some action first.

> 
>    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.
> 
Thank you very much.  We'll fix in this direction.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]