Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations
draft-smith-abfab-usability-ui-considerations-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rhys Smith | ||
| Last updated | 2012-03-29 | ||
| Replaced by | draft-ietf-abfab-usability-ui-considerations | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-smith-abfab-usability-ui-considerations-01
ABFAB R. Smith
Internet-Draft Cardiff University
Intended status: Informational March 29, 2012
Expires: September 30, 2012
Application Bridging for Federated Access Beyond web (ABFAB) Usability
and User Interface Considerations
draft-smith-abfab-usability-ui-considerations-01
Abstract
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.
Status of This Memo
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 30, 2012.
Copyright Notice
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
Smith Expires September 30, 2012 [Page 1]
Internet-Draft ABFAB UI Considerations March 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Considerations around Terminology . . . . . . . . . . . . . . 4
5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Considerations around Management of Identities . . . . . . . . 4
6.1. Information associated with each Identity . . . . . . . . 4
6.2. Adding/Association of an Identity . . . . . . . . . . . . 5
6.2.1. Manual Addition . . . . . . . . . . . . . . . . . . . 5
6.2.2. Manually Triggered Automated Addition . . . . . . . . 6
6.2.3. Fully Automated Addition . . . . . . . . . . . . . . . 7
6.3. Modifying Identity Information . . . . . . . . . . . . . . 8
6.3.1. Manual Modification . . . . . . . . . . . . . . . . . 8
6.3.2. Automated Modification . . . . . . . . . . . . . . . . 8
6.4. Verifying an identity . . . . . . . . . . . . . . . . . . 8
6.5. Removing an Identity . . . . . . . . . . . . . . . . . . . 8
6.5.1. Manual Removal . . . . . . . . . . . . . . . . . . . . 9
6.5.2. Automated Removal . . . . . . . . . . . . . . . . . . 9
7. Considerations around Service to Identity Mapping . . . . . . 9
7.1. Listing Services and Identities . . . . . . . . . . . . . 9
7.2. Associating a Service with an Identity . . . . . . . . . . 9
7.2.1. User-driven Manual Association . . . . . . . . . . . . 9
7.2.2. Automated Rules-based Association . . . . . . . . . . 9
7.3. Dis-associating a Service with an Identity . . . . . . . . 10
8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Identity Association/Verification Errors . . . . . . . . . 10
8.2. Service Errors . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Other Errors. . . . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11
Smith Expires September 30, 2012 [Page 2]
Internet-Draft ABFAB UI Considerations March 2012
1. Introduction
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.
2. Conventions
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].
3. Terminology
TODO:
o Identity: TODO.
o Identity Selector: TODO.
o NAI: Network Access Identifier; see [RFC4282].
o Service: TODO.
o Trust anchor: TODO.
4. Context
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.
Smith Expires September 30, 2012 [Page 3]
Internet-Draft ABFAB UI Considerations March 2012
5. Considerations around Terminology
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.
5.1. Identity
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".
5.2. Services
TODO.
6. Considerations around Management of Identities
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.
6.1. Information associated with each Identity
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.
o Friendly name of Identity - To allow the user to differentiate
between the set of identities they have they should be able to
give each identity a "friendly" identifier. The only restriction
on this name is that it MUST be unique within that particular
user's set of identities. For example "My University Login".
Smith Expires September 30, 2012 [Page 4]
Internet-Draft ABFAB UI Considerations March 2012
o Issuing Organisation - Shows the organisation that issued this
particular credential. This should be... what? For example
"Sandford University".
o NAI - The user's Network Access Identifier (see [RFC4282]) for
this particular credentials. For example, "joe@example.com".
o Password - The password associated with this particular NAI.
o Trust Anchor - For a user to be able to verify (whether they
understand what is happening or not) the identity of the service
they are accessing, or where their identity is held and verified,
each identity will need trust anchor information so that the
identity selector can be sure that the server they are talking to
is legit. This will either be an X509 certificate or
There is also going to be a set of optional information that would be
very useful.
o Password changing URL - The URL the user should visit should they
need to change their password for this particular identity. For
example, "http://www.example.com/passwordreset".
6.2. Adding/Association of an Identity
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.
6.2.1. Manual Addition
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,
Smith Expires September 30, 2012 [Page 5]
Internet-Draft ABFAB UI Considerations March 2012
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:
1. Randomly - the user could be allowed to, at any time, trigger a
workflow of manually adding an identity. This represents the
most flexible way of adding an identity as a user can perform
this at any time. It does, however, have inherent issues when it
comes to verifying the newly added identity (see Section 6.4).
2. When connecting to a service - the user could be given an option
when connecting to a service which has no mapping to any existing
associated identity to add a new one. This presents a better
user experience when it comes to verifying the newly added
identity (see Section 6.4), however, represents a less direct
method of adding an identity. Users who have not yet added the
appropriate identity to their identity selector may find it
difficult to understand that they must try to access a particular
service in order to 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...
6.2.2. Manually Triggered Automated Addition
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
Smith Expires September 30, 2012 [Page 6]
Internet-Draft ABFAB UI Considerations March 2012
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:
o Supply or change the default friendly name for that identity - to
allow the user to customise the identifier they use for that
identity;
o Indicate whether or not the identity selector should always ask
before using services with this identity - to customise the way in
which the identity selector interacts with the user with this
particular identity;
o Reject the addition of the identity completely - to allow the user
to back out of the association process tidily.
In this case, trust anchors could be directly provided in the file to
help establish the trust relationship...
6.2.3. Fully Automated Addition
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...
Smith Expires September 30, 2012 [Page 7]
Internet-Draft ABFAB UI Considerations March 2012
6.3. Modifying Identity Information
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.
6.3.1. Manual Modification
An identity selector may allow a user to manually modify some or all
of the information associated with each identity.
6.3.2. Automated Modification
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.
6.4. Verifying an identity
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:
o If the user has manually added the identity (see Section 6.2) they
will have gone through the whole manual process with no errors and
so believe the identity has been set up correctly. However, when
they attempt to access a service, they may be given an error
message, thus causing some amount of confusion.
o If the user has had the identity provisioned into their identity
selector, then there is a much greater chance of the identity
information being correct. However, if any of the information is
not correct, then there is the potential for confusion as the user
did not add the information in the first place.
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).
6.5. Removing an Identity
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.
Smith Expires September 30, 2012 [Page 8]
Internet-Draft ABFAB UI Considerations March 2012
6.5.1. Manual Removal
TODO.
6.5.2. Automated Removal
TODO.
7. Considerations around Service to Identity Mapping
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.
7.1. Listing Services and Identities
A service list should be considered in the client which is both
searchable and editable by the user.
7.2. Associating a Service with an Identity
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.
7.2.1. User-driven Manual Association
The user could manually associate a particular service with a
particular identity. Lots of UI issues.
7.2.2. Automated Rules-based Association
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.
Smith Expires September 30, 2012 [Page 9]
Internet-Draft ABFAB UI Considerations March 2012
7.3. Dis-associating a Service with an Identity
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.
8. Handling of Errors
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...
8.1. Identity Association/Verification Errors
e.g. wrong password, bad trust anchors, etc. TODO.
8.2. Service Errors
e.g. identity is correct but no authorisation. TODO.
8.3. Other Errors.
e.g. network errors. TODO.
9. Contributors
The following individuals made important contributions to the text of
this document: Sam Hartman (Painless Security LLC), and Maria Turk
(Codethink Ltd).
10. Acknowledgements
TODO
Smith Expires September 30, 2012 [Page 10]
Internet-Draft ABFAB UI Considerations March 2012
11. Security Considerations
TODO
12. IANA Considerations
This document does not require actions by IANA.
13. References
13.1. Normative References
[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.
13.2. Informative References
Appendix A. Change Log
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
1. None, republishing to refresh the document. Other than adding
this comment...
Appendix B. Open Issues
Note to RFC Editor: please remove this appendix before publication as
an RFC.
Author's Address
Dr. Rhys Smith
Cardiff University
39-41 Park Place
Cardiff CF10 3BB
United Kingdom
Phone: +44 29 2087 0126
EMail: smith@cardiff.ac.uk
Smith Expires September 30, 2012 [Page 11]