[http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT)

"Alissa Cooper" <alissa@cooperw.in> Wed, 07 January 2015 22:20 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B881A1BAC; Wed, 7 Jan 2015 14:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3dV9J2cZrcu; Wed, 7 Jan 2015 14:20:46 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024871A6F2C; Wed, 7 Jan 2015 14:20:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150107222027.18377.83227.idtracker@ietfa.amsl.com>
Date: Wed, 07 Jan 2015 14:20:27 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DNgUTsqxKrcQFx0eEwpjF_q1ClI
X-Mailman-Approved-At: Wed, 07 Jan 2015 14:56:44 -0800
Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org
Subject: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 07 Jan 2015 22:20:48 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-httpauth-hoba-09: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/



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

Good stuff! Couple of comments.

= Logging out =

The intro says

"Logout features can be useful for UAs, so HOBA defines a way to
      close a current HTTP "session", and also a way to close all
      current sessions, even if more than one session is currently
      active from different UAs for the same account."
    
But the method specified in 6.3 seems to only accomplish the first of
these (assuming the recommendation about server deletion of cookies
related to "the session" is meant to be specific to one session). What is
the method for logging out of all sessions associated with different UAs
for the same account?

= Section 6.1 =

Either the device identifier/device identifier type bits are
underspecified, or it's not clear to me how they are meant to be used.
What other device identifier types are expected to be used in the future,
such that a registry of them is necessary? To me it seems like you would
want UAs/users to take some care with the precision of the device
identifiers shared with servers -- e.g., "Alissa's laptop" seems like it
could be useful and fairly safe, whereas "IMEI 013584009812219" seems
like total overkill and a bad idea. (As an aside, it might be good to
provide some guidance about this in the document.) The creation of the
registry makes me wonder if more structured device identifiers of the
IMEI-ilk are envisioned, and if so what the purpose of them is expected
to be?

Also, I would suggest

s/if absent then the "string" form of device identifier MUST be used./if
absent then the "string" form of device identifier defined in Section 9.5
MUST be used.

= Section 8 =

"Binding my CPK with someone else's account would be fun and
   profitable so SHOULD be appropriately hard."

Sarcasm translates pretty poorly across cultures. I would suggest saying
what you actually mean here.

= Section 8.2 =

If you want to leave in the LinkedIn reference, or any specific example,
it needs a citation.