Re: [abfab] UI considerations document

Sam Hartman <> Fri, 16 October 2015 13:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 06BF61AD0C3 for <>; Fri, 16 Oct 2015 06:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8b8F6n09PI6F for <>; Fri, 16 Oct 2015 06:02:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21F301AD0C4 for <>; Fri, 16 Oct 2015 06:02:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1BF32086A; Fri, 16 Oct 2015 09:01:03 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oyLSO-2vwMes; Fri, 16 Oct 2015 09:01:03 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS; Fri, 16 Oct 2015 09:01:03 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 4E7F888C9F; Fri, 16 Oct 2015 09:02:33 -0400 (EDT)
From: Sam Hartman <>
To: Mark Donnelly <>
References: <>
Date: Fri, 16 Oct 2015 09:02:33 -0400
In-Reply-To: <> (Mark Donnelly's message of "Fri, 16 Oct 2015 00:01:35 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [abfab] UI considerations document
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Oct 2015 13:02:40 -0000

>>>>> "Mark" == Mark Donnelly <> writes:

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

    Mark> However, I have a few questions for the list.

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

I definitely think it is worth mentioning; it was certainly something we
were all thinking of.
See if you find something starting at

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

The overall protocol supports pseudonyms, but the UI is not currently
involved in this decision at all.

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

So, here are privacy impacts I can think of from the UI.

* Automatically choosing an identity can have privacy impact.  Think of
the Chrome incognito discussion.  Whether to let a given application
choose a given identity  for a given service has privacy impact.

* Discussion of the difference between the Kerberos model (use your
default credential when you can, giving your KDC  information about what
services you access even if they don't support Kerberos at all and our
model of requesting the user explicitly select an identity when first
talking to a service.  Note that the impact would be a bit different for
ABFAB if we used a default credential.  Rather than letting the home
IDP  know what service you are using, it would let the service know what
IDP you were using even if the IDP was inappropriate for that service.

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

I'd assume that if someone doesn't want a password change URI they can
not fill it in.
Also, this is an informational document.
So I tend to agree with you.