Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Mar 2014 03:03:34 +0000

Some additional review...

Big question: how much to do with ABFAB does this really have, vs.
essentially any really usable client UI for a non-trivial GSS-API
mechanism? More to the point, is this open to contributions from other
perspectives to broaden the document's applicability? I got the sense that
other than mentioning an NAI a fair bit, there's not much specific to
ABFAB here.

Section 3:
Is the trust anchor about verifying a service, or about verifying the
authentication service (avoiding the "IdP" term, but you know what I
mean)? I thought the latter, and that service verification was a
by-product of ABFAB being a mutual-auth mech. Think this text could be
clearer if so.

Section 4:
Starts awkwardly. Suggest excising the first clause ("When using the ABFAB
architecture to perform federated authentication to some service,")

It specifically says you're not trying to recommend the use of "identity
selector" as a term, but the document sure focuses on that term. Is there
a good reason not to recommend that? Or are you talking mostly about how a
user would perceive it? Still seems like unifying that makes sense; the
web is helped by the fact that the thing you use to access it is "a
browser".

Section 6.3
I suggest reconsidering the use of "provisioning" here. It's a
well-understood term, even in this exact context of provisioning, say,
wireless authentication info, into clients. I think it's fine to use it.

Section 6.3.2:
Implies a free lunch: "In this case, trust anchors could be directly
provided through the provisioning mechanism to help establish the trust
relationship in a secure manner."

If there were actually any way to do that, you'd already have the trust
anchors. This just moves the problem to a different set of trust anchors.

Section 6.3.3:
I can't really see the norm being auto-provisioning the password itself
into clients. I would think it much more likely the password would be left
out of that step and the user would enter it then or later, so there's no
confusion likely. Maybe this is tied up with the need for a way to verify
identities provisioned into the selector.

Section 6.5:
Is it really impossible to verify identities somehow? Authentication at
least should be verifiable; it certainly would be with other federated
mechanisms.

Section 7:
Delving firmly into opinion, consider that familiar apps like mail and IM
clients all feature the multiple account dialog these days. On the one
hand, it seems like success depends on an ABFAB "identity" being yet
another account option in those apps. Maybe that needs some discussion. If
it's not possible to hope for this, why not? And why shouldn't that raise
red flags for me as a reader? How has this worked or not worked for, say,
Kerberos? Can we learn anything from that?

-- Scott

---

From: Mark Donnelly <[email-masked]>
Date: Tue, 04 Mar 2014 15:54:37 +0000

Hey all:

First, I have some easy editorial remarks:
* Section 6.3.2 mentions provisioning several times, but section 6.3
   says that the draft won't be using the term provisioning.
* Section 7.5 contains, "...to identify which the identity is used..."
   The word "the" should be removed.

Next, some quick content remarks:
* Section 4 lists that "there are of course two methods that could be
   employed to configure identities and associated information."  I can
   imagine more than that!
* Section 6.3.3, "Fully Automated Addition," discusses that users might
   be confused when they can access services without a password prompt.
   I disagree - Windows Networking, SPNEGO under Internet Explorer,
   browser cookies, and browsers remembering your credentials all offer
   access to services without prompting for credentials. I would not be
   surprised to discover that access without specific credential
   prompting is more common than with.

Now, some topics for discussion:
* The end of Section 6.1 suggests helpful links that might be presented 
for each identity, such as a password changing URL and
Helpdesk URL.  Where do you suggest that we get these values?  Would 
that be in the authentication response?  Would that just use 
conventional paths?

* Section 6.5 talks about verifying the identity, and how there's no
   way to verify a NAI and credential tuple.  Is that really true?
   Couldn't we create one?  Maybe set up a do-nothing GSS server on the
   machine with the Identity Selector, and then specify that any ABFAB
   RADIUS system MUST allow access to that localsystem (say,
   localhost.localdomain/test).
* Section 7.3 (Listing Services and Identities) - I'd like to see this
   have some more detail.  For instance, it could discuss how the nature
   of the many-to-many associations between identities and services
   creates a need to list out the identities with their associated
   servers, and also list out the services, with their associated
   identities.  I'd be happy to add this.

Cheers,
--Mark

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Mar 2014 07:17:36 +0000

> other than mentioning an NAI a fair bit, there's not much specific to

Nicely phrased.

To carry it further:  Usability is very difficult specialty, often 
finding that counter-intuitive results are best.  My standard example is 
that we typically assume it is always better to give users more 
information, but in fact it isn't.  (Think of the classic Bell curve. 
Hitting the statistical peak, for users' cognitive load, means not too 
little information and not too much.)

Although entirely well-intentioned, the draft suffers from either 
offering very generic suggestions, such as:

      "Implementers of an identity selector will need to carefully 
consider their intended audience..."

or very specific advice that is given without empirical justification 
and possibly contrary to empirical evidence, such as:

      "Friendly icon for identity: To allow the user to differentiate
       between the set of identities they have they should be able to set
       an icon for that particular identity."

I chose that latter example because it is so obviously reasonable; it's 
difficult to believe that it's not a good suggestion.  However my 
understanding is that users often are actually delayed or confused by 
designs with icon usage, like this, that hasn't first been tested for 
efficacy.  So, sometimes, the icons are a good idea.  Sometimes they 
aren't.  Guidance about making the choice is where the hard work is.

The draft offers no citations for HCI, UX, UCD or Usec research or 
experience.  That's an indication that it has the best of intentions, 
but lacks both theoretical and empirical underpinnings, for a topic that 
is acknowledged by its leaders to require both, when doing design.

And as difficult as usability is generally, it is much worse for usable 
security...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Rhys Smith <[email-masked]>
Date: Fri, 7 Mar 2014 09:27:17 +0000

First, thanks to everyone for the feedback. I’ll deal with all the smaller comments.

The one major comment is Scott’s, and Dave’s response. Can discuss in the WG meeting later this morning. But my comments back would be -

>> other than mentioning an NAI a fair bit, there's not much specific to

My thought here is that yes, very little of it is ABFAB specific in that sense. With relatively few modifications it could probably also provide relevant guidance for other GSS-API mechs that would use an identity selector-like thing.

On 7 Mar 2014, at 07:17, Dave Crocker <[email-masked]> wrote:
> […]
> The draft offers no citations for HCI, UX, UCD or Usec research or experience.  That's an indication that it has the best of intentions, but lacks both theoretical and empirical underpinnings, for a topic that is acknowledged by its leaders to require both, when doing design.

Short response - the draft currently is not really about recommending design solutions, it’s more about helping define the problem and throwing in a few recommendations that we currently think look like best practice.

Longer respones - from our experience with UIs in the world of SAML federations, there are two major things you can do to improve the UX: 1) Improve the UI directly using established UX research (obviously), but also 2) Consistency. To some extent, it doesn’t *matter* how good or bad the UI is as long as it’s consistent across implementations.

This paper is currently more addressing 2) than 1). It’s simply an attempt to pull together the scope of the problem of designing a UI based on the experience we’ve had in designing such a beast for Moonshot (our ABFAB implementation). The aim is that others who might come along and tread the same path can understand the scope of the problem and our thought processes when producing an implementation, in the hope that end users might benefit from having some commonality between implementations. 

Don’t get me wrong, I’m not saying that the other type of work is not valuable; far from it. It’s just that’s a design specification document is somewhat of a different doc from the considerations doc in its current form and would require input  from people more versed in the current state of the art in UX design that me and the current reviewers we’ve had.

Thinking through this, a few changes could probably be made to make this a bit clearer - removing all normative keywords, for example, so that we’re not forcing design choices on implementors which may later prove to be incorrect, wrong, or just plain stupid in hindsight…

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0x4638C985

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Mar 2014 16:55:12 +0000

Sorry I couldn't make the session.

Inline...

On 3/7/2014 9:27 AM, Rhys Smith wrote:
>> […] The draft offers no citations for HCI, UX, UCD or Usec research
>> or experience.  That's an indication that it has the best of
>> intentions, but lacks both theoretical and empirical underpinnings,
>> for a topic that is acknowledged by its leaders to require both,
>> when doing design.
>
> Short response - the draft currently is not really about recommending
> design solutions, it’s more about helping define the problem and
> throwing in a few recommendations that we currently think look like
> best practice.

Calling for icons is a very specific design solution recommendation.

> Longer respones - from our experience with UIs in the world of SAML
> federations, there are two major things you can do to improve the UX:
> 1) Improve the UI directly using established UX research (obviously),
> but also 2) Consistency. To some extent, it doesn’t *matter* how good
> or bad the UI is as long as it’s consistent across implementations.

If you have studies on efficacy that are applicable, please include them.

That something was /done/ might be interesting, but what is essential is 
a basis for judging whether it was /useful/.

> This paper is currently more addressing 2) than 1).

Oh?  That would mean that there was a framework, rather than a varying 
list of different things to consider.

It also means that the nature of the framework has some relevant field 
history so that its applicability to the current activity can be judged.

d/