| ABFAB | R. Smith |
| Internet-Draft | Cardiff University |
| Intended status: Informational | March 29, 2012 |
| Expires: September 28, 2012 |
Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations
draft-smith-abfab-usability-ui-considerations-01
The use of ABFAB-based technologies requires that each user's machine is configured with the user's identities. This will require something on that machine which will manage the user's identities and services. Anyone designing that "something" will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some consistency.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The use of ABFAB-based technologies requires that each user's machine is configured with the user's identities. This will require something on that machine which will manage the user's identities and services. Anyone designing that "something" will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some consistency.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
TODO:
When using the ABFAB architecture to perform federated authentication in a non-web environment, when a user attempts to authenticate to an ABFAB secured application they will be prompted to provide an identity that they wish to authenticate with. This will happen through a process of the application calling the GSS-API, which will in turn gather the users credentials through whatever mechanism it has been configured to do so. We will call this the "identity selector" in this document, though that in no way is a recommendation on terminology for the mechanism!
Any designer of an identity selector will share a common set of usability considerations inherent to the context.
It is assumed that identity selector will attempt to gather a set of identities that belong to its user, and allow that user to manage them in some manner.
Anyone designing an identity selector will have to grapple with choosing terminology that the average user has some chance of understanding. This section will have some discussion around choosing the correct terminology.
Users are used to a variety of terms for aspects of their identity in the ABFAB sense; some of these terms include "username", "login", "network account", "home organisation account", "credentials" and a myriad of other such terms. NAI is unlikely to be one of these terms they are used to.
Careful thought needs to be given to the terminology used in the UI.
Also what paradigm to use when presenting identity to users. Examples that have been deployed include the idea of reality-based paradigms such as "Identity Cards" that are held in the user's "Wallet".
TODO.
A core feature of an identity selector is in management of a user's identities. This section looks at various usability considerations of this area.
Before we can discuss usability considerations around management of a user's identities, we should first look at what information will be a part of the user's identities.
There is going to be a minimal set of information that should be stored about each identity.
There is also going to be a set of optional information that would be very useful.
Users will have identities given to them by the organisation the user has a relationship with. One of the core tasks of an identity selector will be to associate to these identities. This could be done in one of three ways: user manually adds, manually triggered automated provisioning, completely automated provisioning. Each of these is discussed in more detail.
Note that the term "association" or "addition" of an identity is used rather than "provisioning" of an identity, because while we actually are provisioning identities into the UI, provisioning is an overloaded term in the space and could easily be confused with identity provisioning in the sense of the creation of the identity by the home organisation's identity management procedures.
Allowing users to manually associate an identity represents the easiest method of achieving the goal, but it is a method that has the greatest usability drawbacks. Most of the information required is relatively technical and finding some way of explaining what each field is to an untechnical audience is challenging, to say the least.
Thus, this method should be considered as a power-user option only, or as a fall-back should the other methods not be applicable.
When this method is used, careful consideration should be given to the UI presented to the user. The UI will have to ask for all of the information detailed in Section 6.1.
There are two points where a user could manually add an identity:
Of course, both styles of identity addition could be enabled, thus gaining the benefits of both. However, this would also result in the drawbacks of each also being present.
Something about choosing an appropriate trust anchor and verifying your IdP...
One way to bypass the need for manual addition of a user's identity, and all of the usability issues inherent in that approach, is to provide some sort of manually triggered, but automated, provisioning process.
One approach to accomplishing this, for example, could be for an organisation to have a section on their website where their users could visit, enter the user part of their NAI, and be given a file that automatically sets up many or all of the identity information for that identity.
It is reasonable to assume that any such provisioning service is likely to be organisation specific, so that the Issuing Organisation and realm part of the NAI will be constant. The user part of their NAI will have been input on the web service. The password MAY be provided as a part of the provisioning file.
Thus, all required information should be contained within this provisioning file. The identity selector should import this information, and ask the user to provide the correct password for that identity (if a password was not provided).
Additionally, the user SHOULD be given the opportunity to:
In this case, trust anchors could be directly provided in the file to help establish the trust relationship...
Many organisations manage the machines of their users using enterprise management tools. Such organisations may wish to be able to automatically add a particular user's identity to the identity selector on their machine/network account so that the user has to do nothing.
This represents the best usability for the user - they don't actually have to do anything. However, it can only work on machines centrally managed by the organisation.
Additionally, having an identity automatically provided, including its password, does have some particular usability issues. Users are used to having to provide their username and password to access services. When attempting to access services, authenticating to them completely transparently to the user could represent a source of confusion. User training within an organisation to explain that automated provisioning of their identity has been enabled is the only way to counter this.
In this case, trust anchors could be directly provided in the file to help establish the trust relationship...
This is fairly similar to adding an identity, and thus shares many of the usability issues with that process. Some particular things are discussed here.
An identity selector may allow a user to manually modify some or all of the information associated with each identity.
To ease usability, organisations may wish to automatically provide updates to identity information. For example, if the user's password changes, it could automatically update the password for the identity in the user's identity selector.
An inherent by-product of the ABFAB architecture is that an identity cannot be verified during its addition, or directly after; it can only be verified while it is in use with a real service. This represents a definite usability issue no matter which method of identity addition is used (see Section 6.2) as:
Also, if the identity information is incorrect the user may not know where the error lies, and the error messages provided by the mechanism may not be helpful enough to indicate the error and how to fix it (see Section 8).
This is fairly similar to adding or modifying an identity, and thus shares many of the usability issues with those processes. Some particular things are discussed here.
TODO.
TODO.
There is a many to many association between Identities and Services. This association is not easily comprehended by the user. Representing this association and allowing the user to both manipulate it and control it is challenging. These obstacles are especially common when errors occur after an association has been made. In this scenario it is important to make it easy for the user to disassociate the Identity from the service.
A service list should be considered in the client which is both searchable and editable by the user.
In addition to that there needs to be a way for the user to create the service to Identity association, however this should only occur once the identity has authenticated with the service without any error.
There are a few ways this association could happen.
The user could manually associate a particular service with a particular identity. Lots of UI issues.
It would be benefical from a usability perspective to minimise - or avoid entirely - situations where the user has to pick an identity for a particular service. This could be accomplished by having rules to describe services and their mapping to identities. Such a rule could match, for example, a particular identity for all IMAP servers, or a particular identity for all services in a given service realm.
It is also good practice to allow for the associated Identity to be visible to the user while he/she is using a specific service. The user would then be able to identify the Identity and disassociate it if there is an error.
All GSS-API calls need to be instantiated from the application. For this reason when an error occurs the user needs to be sent back to the application to re-initiate the GSS-API call. This can get tedious and cause the user to opt out of what they are trying to accomplish. In addition to this the error messages themselves may not be useful enough for the user to decipher what has gone wrong.
It is important to try and avoid error cases all together while using GSS-API as error messages and error handling can really effect usability. Another solution would be to alter the application to handle the errors as it is instantiating the GSS-API communication.
Lots more to discuss here...
e.g. wrong password, bad trust anchors, etc. TODO.
e.g. identity is correct but no authorisation. TODO.
e.g. network errors. TODO.
The following individuals made important contributions to the text of this document: Sam Hartman (Painless Security LLC), and Maria Turk (Codethink Ltd).
TODO
TODO
This document does not require actions by IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4282] | Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. |
Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.
Draft -00 to draft -01
Note to RFC Editor: please remove this appendix before publication as an RFC.