[abfab] Review of draft-smith-abfab-usability-ui-considerations-03

[Stefan Winter <[e-mail]>]

Hi,

as promised at IETF87, I gave the above draft a read. Since it has
expired and a new rev is pending, I'm not digging into nits, but remain
on a conceptual layer:

5.1 Identity
============

contains the advice
"  Implementors of an identity selector will need to carefully consider
   their indended audience for both their level of technical capability
   and the existing terminology that they may have been exposed to."

That is a nice thought, but IMHO won't help in reality. The implementer
of an Identity Selector does not know in which contexts his software is
going to be used.
If you think on the probably widest scale: you implement a built-in
identity selector for an extremely popular Operating System with
millions of users:

- Your "target audience" is every human who is able to power on a
computer; levels of technical capability will vary from total
incompetence to extremely skilled.

- You also do not know which terminology all those users have been
exposed to.

5.2 Services
============

This section is rather thin, and could use some more text. I for one see
the identity selector as an EAP supplicant; yes it does ABFAB-specific
things, but it needs not be a separate entity from a network-enabling
EAP supplicant. I think it's worth mentioning that one of the services
the identity selector could provide is the "Network Login Service";
converging the network and other-service logins into one.

6.1, first bullet, your TODO remark
===================================

Especially since we do not know the level of skill on the user side,
forcing the id to be a realm seems inappropriate to me. A friendly name
is understood by everybody; a cryptic @foo.bar.baz construct much less so.

6.1, fourth bullet
==================

The trust anchor is not necessarily a certificate. At least in the
network use case, it is most often the tuple of (trusted root
certificate; server name as in Subject or subjectAltName).

The fact that it's a tuple has consequences for UI: it needs to provide
input fields and/or provisioning mechanisms for both parts.

6.1 last two bullets
====================
Since these are optional, probably not worth discussing a lot, just a
question: "Reset Password" is typically a helpdesk operation; so with
Helpdesk URL I don't see much use for a separate Password Change URL?

6.2.1 Manual Addition
=====================
In EAP supplicants we often see a bad behaviour in that supplicants
default to "don't verify server identity" or "allow to continue
connecting even if server identity doesn't match".

I would suggest adding text that the UI should force the user as much as
possible towards a secure setting. I.e. verification of server identity
should be on by default, and if the user just "clicks next" the UI will
not allow him to go to the next step unless he's either finalised
entering trust anchor information - or - explicitly configures that he
wants an insecure config (I imagine a big fat signal-colour warning on
screen when he checks that option).

6.2.2 second bullet
===================
The text is okay, but I believe it is misplaced here. Even with manual
provisioning, the same question needs to be settled (and arguably also
in fully automated addition). So it's more like a general requirement
for an identity selector to ask this question and belongs to section
6.1. It is a question that's probably best asked in the moment when the
user uses a service for the first time, and the decision is subsequently
memorised by the ID selector.

6.4 Verifying an identity
=========================
It might make sense for the identity provider to set up a "test" service
along with his RADIUS/ABFAB/SAML server. The identity selector could
then (if a login URL or so is provided with UI or automated
provisioning) check for a successful identity setup immediately after
the identity is added. Being able to specify the test service URL is
then required for UI. This is way cooler than with network access; you
can only test that if you are near a hotspot or ethernet plug of that
network. But with ABFAB, having an IP address is enough to do a test. I
believe this should be exploited.

7 Mappings
==========
I'm not sure a full "many to many" relationship is needed to be
configurable or visible in UI.

A user would likely configure "Identity A is good for services m and n"
(a 1 to n relationship); or "I have accounts with identity B and C for
service x" (a n to 1 relationship).

If all these relationships are configured, it may be that the
consequence is that several of the identities are good for several of
the services; but that is nothing that needs to be communicated to the
user. The UI should IMHO steer clear of explaining the user's full mesh
of mappings to him.

I could imagine a user clicking on one identity and be shown the
services he has configured for it; or clicking on a service, and be
shown which identities are good for that service. I don't see how
presenting a tree, or even forest, of graphs with the full mesh is in
any way helpful (or even comprehensible) to a user.

7.4 Disassociating Mappings
===========================
Why would this be a MUST requirement? The whole process of
dis-associating seems like an action without consequences for me. It
would not change anything on the service side (i.e. account details are
not deprovisioned when dis-associating - right?).
And even if disassociated, the user could visit the service later again
and re-associate at any time.

So, what changes when disassociating an identity from a service? Is it
more than UI hygiene, i.e. is the effect more significant than just
removing bloat from the list of services locally?

9.1 Success on First Use Reporting
==================================
You write "depending on the service" here; which begs the question: how
is the identity selector supposed to know if a given service is among
those that should be reported as success to the user. This would IMHO
require the identity selector to have metadata to that end about the
service; which doesn't seem like a good idea to me.

And now I'm leaving you to those large empty TODO sections in the
document :-)

Greetings,

Stefan Winter
-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]