[abfab] UI draft -01

[Rhys Smith <[e-mail]>]

Not working to a deadline or anything, obviously… !

draft-ietf-abfab-usability-ui-considerations-01 has been uploaded; available in all the usual places, including https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerations/

Thanks to those who reviewed the doc, we’ve now had several more pairs of eyes look through it than we previously have had, which is great.

I’ve done a tidy up of the document to get it into an almost-ready state, and finished the majority of the TODOs. It also addresses the feedback I received post-London (see below). Changelog at the bottom lists the main changes. So in my opinion, it’s getting pretty close now.

What’s left? Three final main TODOs remain - security & privacy considerations, which I’ll be working on ASAP, and the handling of errors & successes sections which I was going to get some help with but I think it’s fallen through the cracks in the meantime (both mine and the offerer of the help) so that’ll be for the next iteration of the doc.



Addressing specific feedback from Kevin, Mark, Dave:

=====

From Kevin:

> Sections 3, 4, and 6 refer to the identity selector as a 'mechanism' used by
> GSS-API to obtain identity information. This is potentially confusing since
> the identity selector is not a mechanism in the GSS-API sense of the term.
> Especially since in section 6.5 "...error messages provided by the mechanism
> may not be helpful enough..." does use 'mechanism' in the GSS-API sense of
> the term.

Agreed, changed throughout.


> Section 7.5 says the ui should indicate when an identity is 'currently in use,'
> but it is unclear to me how that can be determined. The selector knows when it
> has sent an identity and can be informed when an authentication is successful
> or fails, but how can it know for how long that authentication remains valid
> or in use?

Agreed, added a caveat to that effect.


> Implementing sections 7.1, 8, and 9 would require that the GSS-API mechanism
> report back to the identity selector when the authentication completes. The
> mechanism needs to provide a unique key which can be used to look up the
> identity the the selector previously provided at the start of the
> authentication. Would it make sense for the draft to specify that the NAI alone
> should be sufficient for this purpose? I.e., that the identity selector MUST
> NOT store different identities that use the same NAI?

Agreed, added.


> There are numerous cases of lowercase "should" thoughout the document.
> It is unclear whether these ought to be uppercase SHOULD or even MUST.
> e.g. 6.6.1, 7.3, 7.4

If I’ve used SHOULD or MUST then it’s RFC2119. If i’ve used should or must, then it’s not :-).


> Minor grammar/style nits:
> 1. "This document aims to document these challenges with the
>   aim of producing well-thought out UIs with some degree of
>   consistency."
>   Awkward. Maybe replace "aims to document" with "addresses”?

Problem is that we’re not addressing the challenges, we’re enumerating them.


> 7. "This potentially complex many-to-many association between is not
>   easily comprehended by the user"
>   Should be "...between identities and services”

Yep!


> 8. "can really effect" should be "can really affect"


Gah, good catch.


=====


From Mark:

> 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.

Heh, oops :-). Sorted.



> * Section 7.5 contains, "...to identify which the identity is used..."
>  The word "the" should be removed.

Done.

> 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!

Changed to “at least”… Interested in whether you think some of the other methods that you can think of should be added to the doc?


> * 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.

I do only say “could” be confused, and I stick by that - because we’re moving from within the enterprise to a global federated ecosystem where existing authentication mechanisms to the variety of services that are relevant to ABFAB have existing methods and practices and we’re changing those here.


> 
> 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?

Included in the automated identity provisioning^Wpopulation configuration. You could push these out alongside the trust anchors and whatnot. That would seem more sensible than adding it to the authentication process itself to me.


> * 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).

Mmm good idea. In which case, there’s no *current* way to do it, but that might be something worth working on because it could be pretty useful.


> * 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.

Cool, happy to take some text! For the next draft now, obviously.


> Oh, and further - what if you're using multiple services, with different identities, at the same time?

Mmm that one paragraph is turning out to be a bit of a minefield... It’s definitely an aspiration rather than a concrete suggestion, given that it seems rather impossible to actually implement at the moment.

=====


From Dave:

> Calling for icons is a very specific design solution recommendation.

Agreed. I’ve tried to tidy up the language a bit throughout the document to explicitly point out that the role of the document is to enumerate the issues, and the examples of things you might want to do in a UI are just that - simply examples, and they do not in any way replace good solid HCI/UX design work.


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

email: [e-mail] / [e-mail]
GPG: 0x4638C985