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]