[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [23.30.188.241]) (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 [127.0.0.1]) 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 ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAiaV39rhwjR for <abfab@ietf.org>; Fri, 16 Oct 2015 00:00:17 -0400 (EDT)
Received: from [10.113.143.111] (c-73-182-250-48.hsd1.ma.comcast.net [73.182.250.48]) (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
All: I've spoken with Rhys about the UI considerations document (https://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-02), 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? Thanks, --Mark
- [abfab] UI considerations document Mark Donnelly
- Re: [abfab] UI considerations document Sam Hartman