[http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)
"Alexey Melnikov" <aamelnikov@fastmail.fm> Thu, 01 September 2016 14:50 UTC
Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: http-auth@ietf.org
Delivered-To: http-auth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7126F12D9DC; Thu, 1 Sep 2016 07:50:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.31.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147274142144.10095.917266239677089935.idtracker@ietfa.amsl.com>
Date: Thu, 01 Sep 2016 07:50:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/boaOuzDdk1WGt9uehcFy3TkIg0I>
Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-extension@ietf.org
Subject: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 14:50:21 -0000
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: ---------------------------------------------------------------------- I agree with Stephen that this document must include the registration template as per Section 4.2.1 of BCP 90 (RFC 3864). 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.
- [http-auth] Alexey Melnikov's No Objection on dra… Alexey Melnikov
- [http-auth] Alexey Melnikov's No Objection on dra… Alexey Melnikov
- Re: [http-auth] Alexey Melnikov's No Objection on… 大岩寛
- Re: [http-auth] Alexey Melnikov's No Objection on… Alexey Melnikov
- Re: [http-auth] Alexey Melnikov's No Objection on… Alexey Melnikov
- Re: [http-auth] Alexey Melnikov's No Objection on… Alexey Melnikov
- Re: [http-auth] Alexey Melnikov's No Objection on… 大岩寛
- Re: [http-auth] Alexey Melnikov's No Objection on… Yutaka OIWA
- Re: [http-auth] Alexey Melnikov's No Objection on… Alexey Melnikov