[abfab] comments on UI considerations for ABFAB

Ken Klingenstein <kjk@internet2.edu> Sat, 02 November 2013 17:15 UTC

Return-Path: <kjk@internet2.edu>
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 6DC6521F9B9F for <abfab@ietfa.amsl.com>; Sat, 2 Nov 2013 10:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUSG71247jQp for <abfab@ietfa.amsl.com>; Sat, 2 Nov 2013 10:15:02 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 646D611E8218 for <abfab@ietf.org>; Sat, 2 Nov 2013 10:14:58 -0700 (PDT)
Received: from BLUPR08MB309.namprd08.prod.outlook.com (10.141.48.143) by BLUPR08MB310.namprd08.prod.outlook.com (10.141.48.149) with Microsoft SMTP Server (TLS) id 15.0.815.6; Sat, 2 Nov 2013 17:14:57 +0000
Received: from BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) by BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) with mapi id 15.00.0815.000; Sat, 2 Nov 2013 17:14:56 +0000
From: Ken Klingenstein <kjk@internet2.edu>
To: "abfab@ietf.org" <abfab@ietf.org>
Thread-Topic: comments on UI considerations for ABFAB
Thread-Index: AQHO1+8NnrYVgZ5p4E+czQUI8PwD1w==
Date: Sat, 02 Nov 2013 17:14:56 +0000
Message-ID: <CE9A8F06.15E53%kjk@internet2.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [71.208.17.141]
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(81542001)(76786001)(31966008)(69226001)(76482001)(81686001)(76796001)(74366001)(59766001)(77982001)(83322001)(74662001)(56776001)(16236675002)(80976001)(81816001)(2656002)(65816001)(66066001)(36756003)(56816003)(76176001)(54316002)(80022001)(79102001)(87266001)(53806001)(51856001)(54356001)(4396001)(85306002)(63696002)(50986001)(74502001)(46102001)(77096001)(75432001)(83072001)(47736001)(74706001)(74876001)(49866001)(47446002)(81342001)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR08MB310; H:BLUPR08MB309.namprd08.prod.outlook.com; CLIP:71.208.17.141; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CE9A8F0615E53kjkinternet2edu_"
MIME-Version: 1.0
X-OriginatorOrg: internet2.edu
Subject: [abfab] comments on UI considerations for ABFAB
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: Sat, 02 Nov 2013 17:15:08 -0000

Rhys et al,
  I've done my homework (fearing Leif's steely eye) and reviewed the draft on the UI considerations (Sept 25 version). I'll be at IETF Sunday night through Wednesday, in case you'd like to chat further about this, but have to leave before the ABFAB session on Thursday.
  There's a lot of "still to do" sections in the draft, as you know - I'd be glad to look at them.
  A few overarching comments, and then some specifics on the draft.
      1. I'm glad that you're looking at the larger discovery problem issues rather than just the ABFAB use case. That said, it does bring the discussion close to other efforts such as AccountChooser. In speaking to John Bradley recently, they have many of the concerns that you mention (most notably they are now considering how to control what IdP's can register with an SP or an accountchooser location - trying to get into a dynamic process such as the one you mention, etc.)  Some reference to those discussions might be useful.
      2. There is almost no mention of privacy related issues. As a matter of form, there should be such as a section. Maybe mention the issues around hiding IdP's (we've had instances where people wanted to conceal their IdP choices from interested governments -certainly not in the US :)) - to whether an IdP follows privacy principles (via an end-entity tag or some other information that might want to be shown to the user.) One of the other ways this could be brought out is via some mention of identifiers.
  In your terminology section, I would introduce the identifier vs identity distinction, one I'm trying to hammer on in NSTIC. You mention that a user MAY have multiple identities. It would be good to say that an identity MAY have multiple identifiers associated with it, in order to preserve privacy, etc.
  The first sentence in section 4 could use some smoothing - seems like an awkward sentence. In that same section, you talk about a headless mode operation, but don't define it (and I, as a semi-knowledgeable reader don't know what it means.)
  The first sentence in section 6 uses "firstly" - not English on this side of the pond. And at the end of section 6.1, a typo (exmaple instead of example).
   In section 7, first sentence needs the word "tell" to be singular (tells). Also, the many-many scenario you talk about, in terms of complexities, might be best addressed with a single identity and a mechanisms for that identity to convey the role its in. Maybe hard in an ABFAB case, but maybe not and worth a mention as an alternative.
  Again, willing to review new sections as they are added. A topic close to home for me.

             Ken