Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations
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]