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

[Rhys Smith <[e-mail]>]

Comments below...




On 7 Aug 2013, at 11:03, Stefan Winter <[e-mail]> wrote:

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

Thanks :-)


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

I think this advice can only be aimed at anyone implementing an identity selector for a particular target audience. If you're an OS vendor and your target audience is "all humans" then yes, I agree totally. But I think it's good advice if you're implementing for a much more specific set of people.

The R&E community that Moonshot is targeting is probably close enough to "all humans" that we can't do much here, but if say the high energy physics world using CERN (to use a random example) were to develop their own ID selector they might be able 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.

The document currently really doesn't talk about what the services might be at all, the use cases document does that. My +1 is for not talking about this at all, since others with interests in other kinds of services might want their use cases called out as well.

But, I don't feel massively strongly about this, so I could do so if you and others think strongly about this…




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

Unfortunately this is a technical requirement of ABFAB and needs to be a realm so that the correct IdP can be identified. There is a friendly name in the SHOULD in the next para. The MUST may well be the NAI, password, and trust anchor.


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

Good point. Text amended.


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

Users tend to like direct links to a password change URL, rather than having to go to a general helpdesk page.



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

Yes. Good stuff. Text added.


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

Not sure… I would imagine the provisioning process would include that information. The user should hopefully then be able to go and override that. In an enterprise provisioning scenario, you want to interact with the user as little as possible.


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

That's a pretty cool idea, but not sure we can make this a requirement on all UIs. It's certainly something deployers (such as us Moonshot folks) might want to think about though...




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

I don't the section suggests displaying many to many anywhere - it just points out that the many to many relationship exists. I don't think I even conceived of the idea of trying to do so, since it would be, as you point out, pretty horrendous. If you think the text implied that, then it certainly didn't mean to, and I can change the text to try to make that clear if you think it's worth doing...


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

It MUST be a MUST because if the user can't disassociate an identity from a service in any way, then they have no way to change their mind about the identity to use (or to not use ABFAB at all) for that service without completely removing the whole identity and all of its mappings. Which seems like bad UI design to me.


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

Good point. But it is a good idea. Maybe this should become a stronger statement. I've made that change.




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

Why thank you…

I'm submitting a new version with Jim and your changes as 04. -05 will start to address some of the currently empty suggestions…


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

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