draft-ietf-abfab-usability-ui-considerations-01.txt   draft-ietf-abfab-usability-ui-considerations-02.txt 
ABFAB R. Smith ABFAB R. Smith
Internet-Draft Cardiff University Internet-Draft Cardiff University
Intended status: Informational July 4, 2014 Intended status: Informational July 6, 2015
Expires: January 5, 2015 Expires: January 7, 2016
Application Bridging for Federated Access Beyond web (ABFAB) Usability Application Bridging for Federated Access Beyond web (ABFAB) Usability
and User Interface Considerations and User Interface Considerations
draft-ietf-abfab-usability-ui-considerations-01 draft-ietf-abfab-usability-ui-considerations-02
Abstract Abstract
The real world use of ABFAB-based technologies requires that any The real world use of ABFAB-based technologies requires that any
identity to be used to authenticate be configured on the ABFAB- identity that is to be used for authentication has to be configured
enabled client device. Achieving this requires software on that on the ABFAB-enabled client device. Achieving this requires software
device (either built into the operating system or a standalone on that device (either built into the operating system or a
utility) that will interact with the user, managing their identity standalone utility) that will interact with the user, managing their
information and identity-to-service mappings. All designers of identity information and identity-to-service mappings. All designers
software to fulfil this role will face the same set of challenges. of software to fulfil this role will face the same set of challenges.
This document aims to document these challenges with the aim of This document aims to document these challenges with the aim of
producing well-thought out UIs with some degree of consistency producing well-thought out UIs with some degree of consistency
between implementations. between implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Considerations around Terminology . . . . . . . . . . . . . . 5 5. Considerations around Terminology . . . . . . . . . . . . . . 6
5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 6 5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 7
6. Considerations around Management of Identities . . . . . . . 6 6. Considerations around Management of Identities . . . . . . . . 7
6.1. Information associated with each Identity . . . . . . . . 6 6.1. Information associated with each Identity . . . . . . . . 7
6.2. Storage of Identity Information . . . . . . . . . . . . . 8 6.2. Storage of Identity Information . . . . . . . . . . . . . 8
6.3. Adding/Association of an Identity . . . . . . . . . . . . 8 6.3. Adding/Association of an Identity . . . . . . . . . . . . 8
6.3.1. Manual Addition . . . . . . . . . . . . . . . . . . . 8 6.3.1. Manual Addition . . . . . . . . . . . . . . . . . . . 9
6.3.2. Manually Triggered Automated Addition . . . . . . . . 9 6.3.2. Manually Triggered Automated Addition . . . . . . . . 10
6.3.3. Fully Automated Addition . . . . . . . . . . . . . . 10 6.3.3. Fully Automated Addition . . . . . . . . . . . . . . . 11
6.4. Modifying Identity Information . . . . . . . . . . . . . 10 6.4. Modifying Identity Information . . . . . . . . . . . . . . 11
6.4.1. Manual Modification . . . . . . . . . . . . . . . . . 11 6.4.1. Manual Modification . . . . . . . . . . . . . . . . . 11
6.4.2. Automated Modification . . . . . . . . . . . . . . . 11 6.4.2. Automated Modification . . . . . . . . . . . . . . . . 11
6.5. Verifying an identity . . . . . . . . . . . . . . . . . . 11 6.5. Verifying an identity . . . . . . . . . . . . . . . . . . 12
6.6. Removing an Identity . . . . . . . . . . . . . . . . . . 11 6.6. Removing an Identity . . . . . . . . . . . . . . . . . . . 12
6.6.1. Manual Removal . . . . . . . . . . . . . . . . . . . 12 6.6.1. Manual Removal . . . . . . . . . . . . . . . . . . . . 12
6.6.2. Automated Removal . . . . . . . . . . . . . . . . . . 12 6.6.2. Automated Removal . . . . . . . . . . . . . . . . . . 12
6.7. Storing an Identity with or without credentials . . . . . 12 6.7. Storing an Identity with or without credentials . . . . . 12
7. Considerations around Management of Service to Identity 7. Considerations around Management of Service to Identity
Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Associating a Service with an Identity . . . . . . . . . 13 7.1. Associating a Service with an Identity . . . . . . . . . . 13
7.1.1. User-driven Manual Association . . . . . . . . . . . 13 7.1.1. User-driven Manual Association . . . . . . . . . . . . 13
7.1.2. Automated Rules-based Association . . . . . . . . . . 13 7.1.2. Automated Rules-based Association . . . . . . . . . . 14
7.2. Disassociating a Service with an Identity . . . . . . . . 13 7.2. Disassociating a Service with an Identity . . . . . . . . 14
7.3. Listing Services and Identities . . . . . . . . . . . . . 14 7.3. Listing Services and Identities . . . . . . . . . . . . . 14
7.4. Showing the Service that is requesting Authentication . . 14 7.4. Showing the Service that is requesting Authentication . . 14
7.5. Showing the Identity currently in use . . . . . . . . . . 14 7.5. Showing the Identity currently in use . . . . . . . . . . 15
7.6. Multiple Identities for a Particular Service . . . . . . 14 7.6. Multiple Identities for a Particular Service . . . . . . . 15
7.7. Not using ABFAB for a Particular Service . . . . . . . . 15 7.7. Not using ABFAB for a Particular Service . . . . . . . . . 15
8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . 15 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Identity Association/Verification Errors . . . . . . . . 15 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 16
8.2. Service Errors . . . . . . . . . . . . . . . . . . . . . 15 9.1. Reporting Authentication Success on First Use of
8.3. Other Errors. . . . . . . . . . . . . . . . . . . . . . . 15 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 15 9.2. Reporting Authentication Success . . . . . . . . . . . . . 17
9.1. Reporting Authentication Success on First Use of Identity 15
9.2. Reporting Authentication Success . . . . . . . . . . . . 16 10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Other Considerations . . . . . . . . . . . . . . . . . . . . 16 10.1. Identity Selector Taking Focus . . . . . . . . . . . . . . 17
10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 16 10.2. Import/Export of Credentials . . . . . . . . . . . . . . . 17
10.2. Import/Export of Credentials . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
16. Normative References . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The use of ABFAB-based technologies requires that any identity to be The use of ABFAB-based technologies requires that any identity that
used to authenticate be configured on the client device. Achieving is to be used for authentication has to be configured on the client
this requires software on that device (either built into the device. Achieving this requires software on that device (either
operating system or a standalone utility) that will interact with the built into the operating system or a standalone utility) that will
user, and manage the user's identities and credential-to-service interact with the user, and manage the user's identities and
mappings. Anyone designing that software will face the same set of credential-to-service mappings. Anyone designing that software will
challenges. face the same set of challenges.
This document does not intend to supplant evidence-based UI design This document does not intend to supplant evidence-based UI design
guidelines; implementers of identity selectors are strongly guidelines; implementers of identity selectors are strongly
encouraged to understand the latest in HCI and UX thought and encouraged to understand the latest in HCI and UX thought and
practice. Instead, it aims to document the common challenges faced practice. Instead, it aims to document the common challenges faced
by implementers with the aim of providing a common starting point for by implementers with the aim of providing a common starting point for
implementers in the hope that this aids in producing well-thought out implementers in the hope that this aids in producing well-thought out
UIs with some degree of consistency. UIs with some degree of consistency.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
Various items of terminology used in the document are heavily Various items of terminology used in the document are heavily
overloaded and could thus mean a variety of different things to overloaded in that they mean a variety of different things to
different people. In an attempt to minimise this problem, this different people. In an attempt to minimise this problem, this
section gives a brief description of the main items of terminology section gives a brief description of the main items of terminology
used in order to aid a consistent understanding of this document. used in order to aid a consistent understanding of this document.
o NAI: Network Access Identifier - a standard way of identifying a o NAI: Network Access Identifier - a standard way of identifying a
user and assisting in the routing of an authentication request user and assisting in the routing of an authentication request
(see [RFC4282]). (see [RFC4282]).
o Identity: In this context, an identity is a credential given to a o Identity: In this context, an identity is a credential given to a
user by a particular organisation with which they have an user by a particular organisation with which they have an
skipping to change at page 15, line 16 skipping to change at page 15, line 41
There may be cases where a user does not wish to use ABFAB based There may be cases where a user does not wish to use ABFAB based
authentication at all to a particular service, even though it is authentication at all to a particular service, even though it is
ABFAB enabled. To support this, the identity selector would have to ABFAB enabled. To support this, the identity selector would have to
allow the user to choose not to use ABFAB when they attempt to allow the user to choose not to use ABFAB when they attempt to
authenticate to a service. It would be desirable if the user could authenticate to a service. It would be desirable if the user could
also flag that this should be remembered. also flag that this should be remembered.
8. Handling of Errors 8. Handling of Errors
All GSS-API calls need to be instantiated from the application. For Errors during the ABFAB authentication process can happen at any of
this reason when an error occurs the user needs to be sent back to the many layers - they could be GSS-API errors, EAP errors, RADIUS/
the application to re-initiate the GSS-API call. This can get RadSec errors, SAML errors, application errors, etc. ABFAB based
tedious and cause the user to opt out of what they are trying to technologies are limited in error handling by the limitations in the
accomplish. In addition to this the error messages themselves may protocols used.
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 For example, all GSS-API calls are necessarily instantiated from
GSS-API as error messages and error handling can really affect within the calling application. For this reason, when an error
usability. Another solution would be to alter the application to occurs the error is passed back to the application in order for it to
handle the errors as it is instantiating the GSS-API communication. deal with it. To retry, the application needs to re-initiate the
GSS-API call. Unless the application has been written to deal with
this properly, this process can be very tedious for a user and cause
them 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.
TODO: Lots more to discuss here... Absent an improvement to the error handling of these protocols,
implementors of an ABFAB Identity Selector will need to work around
these limitations. Possible error conditions need to be considered,
and decisions about what errors should be presented to the user, and
how, need to be made.
8.1. Identity Association/Verification Errors To give an idea of the range of errors that might be seen, consider
the following non-exhaustive set of potential errors.
TODO: e.g. wrong password, bad trust anchors, etc. TODO. Identity Association/Verification Errors:
8.2. Service Errors o The credentials presented to the IdP were not able to be verified
- e.g. wrong username/password.
TODO: e.g. identity is correct but no authorisation. TODO. o The Trust Anchor for the IdP was invalid.
8.3. Other Errors. Service Errors:
TODO: e.g. network errors. TODO. o The Identity might have been successfully authenticated by the
IdP, but the user might not have authorisation to use the service
they are attempting to use.
Other Errors:
o The IdP didn't respond to the Service.
o The IdP didn't respond to the Client.
o Network errors.
o Timing errors.
9. Handling of Successes 9. Handling of Successes
It is of course hoped that the identity selector will have to It is of course hoped that the identity selector will have to
occasionally handle successes as well as errors. This section has occasionally handle successes as well as errors. This section has
some brief discussion about some areas you might want to think about. some brief discussion about some areas you might want to think about.
9.1. Reporting Authentication Success on First Use of Identity 9.1. Reporting Authentication Success on First Use of Identity
The first time an identity is used with a service, it would be good The first time an identity is used with a service, it would be good
skipping to change at page 16, line 46 skipping to change at page 17, line 44
information. information.
11. Contributors 11. Contributors
The following individuals made important contributions to the text of The following individuals made important contributions to the text of
this document: Sam Hartman (Painless Security LLC), and Maria Turk this document: Sam Hartman (Painless Security LLC), and Maria Turk
(Codethink Ltd). (Codethink Ltd).
12. Acknowledgements 12. Acknowledgements
Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, Mark Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman,
Donally, Dave Crocker. Mark Donally, and Dave Crocker, for feedback and suggestions.
13. Security Considerations 13. Security Considerations
TODO: Bad trust anchors, no trust anchors, phishing. Most security considerations are ones relevant to the use of GSS-EAP
and are detailed in [I-D.ietf-abfab-arch]. There are, however, a few
specific sets of security considerations related to the UI
implementation.
14. Privacy Considerations First, as discussed earlier, the Identity Selector should use a Trust
Anchor to authenticate the IdP before it sends the users credentials
to it. Having no Trust Anchor information at all, or an incorrect
Trust Anchor, can enable the possibility of someone spoofing the IdP
and harvesting credentials sent to it. So, how this Trust Anchor is
configured and managed can have major security implications:
TODO: See Arch for general discussion. Particular to UI - storing o The most secure way for a Trust Anchor to be configured is to have
credentials on a particular device, mobility considerations. it provisioned alongside the other identity information in an
enterprise provisioning scenario. This allows for the correct
Trust Anchor to be configured with no user input required.
However, thought needs to be given to Trust Anchor expiry and
consequent requirement for regular reprovisioning of identity
information.
15. IANA Considerations o Another way that is potentially secure would be to allow the user
to discover the Trust Anchor information out of band and manually
input this information into the Identity Selector. This is only
secure, however, for those users who understand what they're doing
in this scenario; pragmatically, this is unlikely to be the case
for many users so is not a recommended approach for the average
user.
o A pragmatic approach would be leap of faith, whereby no Trust
Anchor information is initially provisioned, and the first time
the Identity Selector connects to the IdP it remembers the Trust
Anchor information for future use. This doesn't mitigate against
spoofing of an IdP in the first instance, but would enable
mitigation against it for all future connections.
o Finally, there may be interesting ways to leverage technologies
such as DANE to store the Trust Anchor for an IdP in DNS.
Secondly, the storage of the user's credentials by the Identity
Selector should be done in a secure manner to mitigate against people
taking unauthorised control of the device being able to gather these
credentials. Use of a secure credential storage mechanism, such as
the GNOME Keyring on Linux, or Keychain on the Mac, are recommended.
14. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
16. Normative References 15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997. Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P.
Network Access Identifier", RFC 4282, December 2005. Eronen, "The Network Access Identifier",
RFC 4282, December 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Boeyen, S., Housley, R., and W. Polk,
Infrastructure Certificate and Certificate Revocation List "Internet X.509 Public Key Infrastructure
(CRL) Profile", RFC 5280, May 2008. Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[I-D.ietf-abfab-arch] [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofenig, H.,
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Lear, E., and J. Schaad, "Application
Schaad, "Application Bridging for Federated Access Beyond Bridging for Federated Access Beyond Web
Web (ABFAB) Architecture", draft-ietf-abfab-arch-12 (work (ABFAB) Architecture",
in progress), February 2014. draft-ietf-abfab-arch-12 (work in
progress), February 2014.
[I-D.ietf-abfab-usecases] [I-D.ietf-abfab-usecases] Smith, R., "Application Bridging for
Smith, R., "Application Bridging for Federated Access Federated Access Beyond web (ABFAB) Use
Beyond web (ABFAB) Use Cases", draft-ietf-abfab- Cases", draft-ietf-abfab-usecases-05 (work
usecases-05 (work in progress), September 2012. in progress), September 2012.
Appendix A. Change Log Appendix A. Change Log
Note to RFC Editor: if this document does not obsolete an existing Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC. RFC, please remove this appendix before publication as an RFC.
IETF draft -01 to ietf draft -02
1. Tidying up language throughout.
2. Finished remaining TODOs - largely in the error handling section.
3. Added security considerations section.
IETF draft -00 to ietf draft -01 IETF draft -00 to ietf draft -01
1. Tidying up language throughout 1. Tidying up language throughout
2. Doing some of the TODOs 2. Doing some of the TODOs
3. Added language that tries to explain that this document is not a 3. Added language that tries to explain that this document is not a
substitute for good HCI/UX design. substitute for good HCI/UX design.
4. Changed terminology slightly to avoid confusion between an 4. Changed terminology slightly to avoid confusion between an
 End of changes. 30 change blocks. 
112 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/