[abfab] UI considerations document

Mark Donnelly <mark@painless-security.com> Fri, 16 October 2015 04:01 UTC

Return-Path: <mark@painless-security.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D31221B2E58 for <abfab@ietfa.amsl.com>; Thu, 15 Oct 2015 21:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dhHYN1eLo6id for <abfab@ietfa.amsl.com>; Thu, 15 Oct 2015 21:01:51 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F42311B2E55 for <abfab@ietf.org>; Thu, 15 Oct 2015 21:01:50 -0700 (PDT)
Received: from localhost (localhost []) by mail.painless-security.com (Postfix) with ESMTP id 9585F20869 for <abfab@ietf.org>; Fri, 16 Oct 2015 00:00:17 -0400 (EDT)
Received: from mail.painless-security.com ([]) by localhost (mail.suchdamage.org []) (amavisd-new, port 10024) with ESMTP id aAiaV39rhwjR for <abfab@ietf.org>; Fri, 16 Oct 2015 00:00:17 -0400 (EDT)
Received: from [] (c-73-182-250-48.hsd1.ma.comcast.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mark@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA for <abfab@ietf.org>; Fri, 16 Oct 2015 00:00:17 -0400 (EDT)
To: abfab@ietf.org
From: Mark Donnelly <mark@painless-security.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5620769F.4020203@painless-security.com>
Date: Fri, 16 Oct 2015 00:01:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/xIutHfWbpVMv3UH4AQ4mBb9VDDE>
Subject: [abfab] UI considerations document
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 04:01:53 -0000


I've spoken with Rhys about the UI considerations document
and I've volunteered to handle the next revision of the draft.  I've
collected the comments from the last draft and I'm working to
incorporate them in.

However, I have a few questions for the list.

To start off, Alejandro Perez Mendez wrote that a reference to Microsoft
Cardspace in section 5.1 would be nice.  Does anyone have one?  All I
can find is a Wikipedia article, which notes the discontinuation of
Cardspace.  (Actually, does that warrant the removal of the inclusion in
the doc?  I'm not familiar with Cardspace at all.)

Next, Ken Klingenstein asked about whether the user will want some
degree of privacy, or a pseudo-identity.  Does the UI have any
visibility or control over this?  As I understand the system, the
information that is released about an identity is decided entirely by
the IDP, and communicated to the RP.

Ken also suggests that we add a privacy considerations section.  If the
answer to the above question is that the UI doesn't have any visibility
into what attributes the IDP releases, then I'm not sure what could go
in to a privacy considerations section for the UI document.  The privacy
considerations I see would all apply to the greater system, rather than
the client UI.  Does anyone have any better thoughts?

Finally, Ken suggested that the UI drop the concept of an NAI having a
password change URL.  Ken argues that the helpdesk URL that the document
already specifies would be less volatile, and the user could navigate
from there.  I think this would remove a usable feature of the system,
and if the password change URL doesn't work then the user could go
through the helpdesk anyway.  Any thoughts?