[abfab] Comments on draft-smith-abfab-usability-ui-considerations-03

"Jim Schaad" <ietf@augustcellars.com> Fri, 01 March 2013 18:23 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E5121F93BE for <abfab@ietfa.amsl.com>; Fri, 1 Mar 2013 10:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqauirEEM22R for <abfab@ietfa.amsl.com>; Fri, 1 Mar 2013 10:22:58 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A267421F93BD for <abfab@ietf.org>; Fri, 1 Mar 2013 10:22:57 -0800 (PST)
Received: from Philemon (75-148-161-130-Houston.hfc.comcastbusiness.net [75.148.161.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A58632C9BE; Fri, 1 Mar 2013 10:22:31 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: smith@Cardiff.ac.uk
Date: Fri, 01 Mar 2013 12:21:51 -0600
Message-ID: <03a101ce16a9$ab322f40$01968dc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4WjMgOr398ifT8RQCjlSNQwR6FpQ==
Content-Language: en-us
Cc: abfab@ietf.org
Subject: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-03
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 01 Mar 2013 18:23:05 -0000

Rhys,

1.  Terminology - Bullet #1 - s/which they have an organization/which they
have an association/

2. Terminology -  Move NAI before Identity to deal with problem of expand on
first use.

3.  Terminology - Bullet # 2 - Message sentence with the "and".  I mis-read
it the first time as the GSS-API would do the mapping rather than the
identity selector.

4.   Section 4- Context - s/user to user/user to use/

5. Section 4 - Context - In the first bullet - I think you want to say that
this is a GSS-API implementation specific file and not an application
specific file.  The term application is overloaded with the application that
the user is using to talk to the service.

6.  Section 6.1 - Is the issuing organization always going to be derivable
from the NAI of the user?  Under what circumstances would this not be the
case?

7.  Section 6.2.2. - Implies either a lot of different ways or some standard
way being created to do this.  This needs to be made clearer that there is
going to be an association between the implementation of ABFAB, the UI and
the IDP service.

8.  Section 6.4  - bullet #2 - s/the identity provisioned/the identity
automatically provisioned/

9.  Section 7 - add new section - Server identification.  There are a number
of different ways that services can be identified.  The name of the service,
the name of the server, parameters that are included in the service (for
example the account that I am going to use to send mail), or some
combination of the above.

10 Section 7 - Identity selection by calling application rather than GSS-API

11 Section 7 - last paragraph - last sentence - should this be an
"automatic" option on some types of authentication failures?

12.  Section 7.3 - why should the association only be doable after
authentication?  Esp for manual authentications.

13.  Section 7.3.1 - It would be beneficial to list the types of things that
are selections.  I don't know that it is necessary to know the realm in all
cases.

14.  Section 7.3.1 - User-driven - on demand associations - Pop up a
selection dialog box when you are trying to get to a service you have never
seen before.

15.  Section 8 - should applications attempt to use multiple names if there
are multiple names associated with the service.  Need to discuss possible
privacy implications of this approach in terms of association of multiple
names together.



Import/Export of credentials
Password protect the store - not the same as password used for the IDP
Credentials that are "pluggable" - that may or may not be present on the
machine