< draft-ietf-abfab-usability-ui-considerations-03.txt   draft-ietf-abfab-usability-ui-considerations-04.txt >
ABFAB R. Smith ABFAB R. Smith
Internet-Draft Cardiff University Internet-Draft Cardiff University
Intended status: Informational M. Donnelly Intended status: Informational M. Donnelly
Expires: April 21, 2016 Painless Security Expires: September 22, 2016 Painless Security
October 19, 2015 March 21, 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-03 draft-ietf-abfab-usability-ui-considerations-04
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 that is to be used for authentication has to be configured identity that is to be used for authentication has to be configured
on the ABFAB-enabled client device. Achieving this requires software on the ABFAB-enabled client device. Achieving this requires software
on that device (either built into the operating system or a on that device (either built into the operating system or a
standalone utility) that will interact with the user, managing their standalone utility) that will interact with the user, managing their
identity information and identity-to-service mappings. All designers identity information and identity-to-service mappings. All designers
of 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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 21, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
7.1.1. User-driven Manual Association . . . . . . . . . . . 17 7.1.1. User-driven Manual Association . . . . . . . . . . . 17
7.1.2. Automated Rules-based Association . . . . . . . . . . 17 7.1.2. Automated Rules-based Association . . . . . . . . . . 17
7.1.3. Association Conflicts . . . . . . . . . . . . . . . . 17 7.1.3. Association Conflicts . . . . . . . . . . . . . . . . 17
7.2. Disassociating a Service with an Identity . . . . . . . . 18 7.2. Disassociating a Service with an Identity . . . . . . . . 18
7.3. Listing Services and Identities . . . . . . . . . . . . . 19 7.3. Listing Services and Identities . . . . . . . . . . . . . 19
7.4. Showing the Service that is requesting Authentication . . 19 7.4. Showing the Service that is requesting Authentication . . 19
7.5. Showing the Identity currently in use . . . . . . . . . . 19 7.5. Showing the Identity currently in use . . . . . . . . . . 19
7.6. Multiple Identities for a Particular Service . . . . . . 20 7.6. Multiple Identities for a Particular Service . . . . . . 20
7.7. Not using ABFAB for a Particular Service . . . . . . . . 20 7.7. Not using ABFAB for a Particular Service . . . . . . . . 20
8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . 20 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . 20
9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 21 8.1. Errors in GSS-API . . . . . . . . . . . . . . . . . . . . 20
9.1. Reporting Authentication Success on First Use of Identity 21 8.1.1. Log of Errors . . . . . . . . . . . . . . . . . . . . 21
9.2. Reporting Authentication Success . . . . . . . . . . . . 21
10. Other Considerations . . . . . . . . . . . . . . . . . . . . 21 8.2. Examples of errors . . . . . . . . . . . . . . . . . . . 21
10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 21 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 22
9.1. Reporting Authentication Success on First Use of Identity 22
9.2. Reporting Authentication Success . . . . . . . . . . . . 22
10. Other Considerations . . . . . . . . . . . . . . . . . . . . 22
10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 22
10.2. Import/Export of Credentials . . . . . . . . . . . . . . 22 10.2. Import/Export of Credentials . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
16.1. Normative References . . . . . . . . . . . . . . . . . . 24 16.1. Normative References . . . . . . . . . . . . . . . . . . 25
16.2. Informative References . . . . . . . . . . . . . . . . . 25 16.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The use of ABFAB-based technologies requires that any identity that The use of ABFAB-based technologies requires that any identity that
is to be used for authentication has to be configured on the client is to be used for authentication has to be configured on the client
device. Achieving this requires software on that device (either device. Achieving this requires software on that device (either
built into the operating system or a standalone utility) that will built into the operating system or a standalone utility) that will
interact with the user, and manage the user's identities and interact with the user, and manage the user's identities and
credential-to-service mappings. Anyone designing that software will credential-to-service mappings. Anyone designing that software will
face the same set of challenges. face the same set of challenges.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
Implementers of an identity selector will need to carefully consider Implementers of an identity selector will need to carefully consider
their intended audience for both their level of technical capability their intended audience for both their level of technical capability
and the existing terminology that they may have been exposed to. and the existing terminology that they may have been exposed to.
Beyond terminology, careful thought needs to be given to the paradigm Beyond terminology, careful thought needs to be given to the paradigm
to use when presenting identity to users, as identities and services to use when presenting identity to users, as identities and services
are abstract concepts that some users may not find easily are abstract concepts that some users may not find easily
understandable. Implementers may wish to keep such abstract concepts understandable. Implementers may wish to keep such abstract concepts
despite this, or may wish to examine attempts to map to real world despite this, or may wish to examine attempts to map to real world
paradigms, e.g. the idea of using "Identity Cards" that are held in paradigms, e.g. the idea of using "Identity Cards" that are held in
the user's "Wallet", as used by the new defunct Microsoft Cardspace the user's "Wallet", as used by the now defunct Microsoft Cardspace
([MS-CS]). ([MS-CS]).
5.2. Services 5.2. Services
Terminology around services is likely to be less of a problem than Terminology around services is likely to be less of a problem than
identity, but it will actually depend on what the service is. For identity, but it will actually depend on what the service is. For
example, each service could be simply described as "server", example, each service could be simply described as "server",
"system", etc. But for simplicity just the word "service" will "system", etc. But for simplicity just the word "service" will
probably usually suffice. probably usually suffice.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
also flag that this should be remembered. also flag that this should be remembered.
8. Handling of Errors 8. Handling of Errors
Errors during the ABFAB authentication process can happen at any of Errors during the ABFAB authentication process can happen at any of
the many layers - they could be GSS-API errors, EAP errors, RADIUS/ the many layers - they could be GSS-API errors, EAP errors, RADIUS/
RadSec errors, SAML errors, application errors, etc. ABFAB based RadSec errors, SAML errors, application errors, etc. ABFAB based
technologies are limited in error handling by the limitations in the technologies are limited in error handling by the limitations in the
protocols used. protocols used.
For example, all GSS-API calls are necessarily instantiated from 8.1. Errors in GSS-API
within the calling application. For this reason, when an error
occurs the error is passed back to the application in order for it to
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.
Absent an improvement to the error handling of these protocols, All GSS-API calls are necessarily instantiated from within the
implementors of an ABFAB Identity Selector will need to work around calling application. For this reason, when an error occurs the error
these limitations. Possible error conditions need to be considered, is passed back to the application in order for it to deal with it.
and decisions about what errors should be presented to the user, and To retry, the application needs to re-initiate the GSS-API call.
how, need to be made. 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
application may not display the error messages to the user. Even
when the application does display the errors, the messages themselves
may not be useful enough for the user to decipher what has gone
wrong.
Two extensions to GSS-API are suggested for the consideration of the
kitten working group:
o GSS-API should provide a method for applications to invoke to
indicate that the application has displayed the last error to the
user.
o GSS-API should provide a method for applications to invoke to
indicate that the authentication succeeded, but is insufficient
for the task at hand and needs to be retried.
8.1.1. Log of Errors
The Identity Selector can improve the general GSS-API error reporting
experience by displaying a list of errors experienced by ABFAB
applications. When an application error occurs, the EAP mechanism
MAY record that error. If the mechanism records these errors, the
Identity Selector MAY display these errors to the user. Thus, the
user will have a single place to go to view all of the errors that a
user experiences across all applications. Therefore, an Identity
Selector that implements an error display SHOULD present the user
with the context of the error, including the calling application and
the time.
8.2. Examples of errors
To give an idea of the range of errors that might be seen, consider To give an idea of the range of errors that might be seen, consider
the following non-exhaustive set of potential errors. the following non-exhaustive set of potential errors.
Identity Association/Verification Errors: Identity Association/Verification Errors:
o The credentials presented to the IdP were not able to be verified o The credentials presented to the IdP were not able to be verified
- e.g. wrong username/password. - e.g. wrong username/password.
o The Trust Anchor for the IdP was invalid. o The Trust Anchor for the IdP was invalid.
Service Errors: Service Errors:
o The Identity might have been successfully authenticated by the o The IdP recognizes the client, but decides not to authorize it for
IdP, but the user might not have authorisation to use the service this service.
or privilege levels within the service they are attempting to use.
o The EAP session succeeds, but the RADIUS system sends access-
reject to the Relying Party
o The RADIUS system succeeds, but the Relying Party rejects the
session. For instance, the SAML part of the session could contain
an error that causes the Relying Party to reject the client.
o The Identity might have been successfully authenticated, but the
user might not have authorisation to use the service or privilege
levels within the service they are attempting to use. For
instance, the Identity could authorise the use of an operating
system as an unprivileged user, which would prevent the user's
goal of managing the hard drives.
Other Errors: Other Errors:
o The IdP didn't respond to the Service. o The IdP didn't respond to the Service.
o The IdP didn't respond to the Client. o The IdP didn't respond to the Client.
o Network errors. o Network errors.
o Timing errors. o Timing errors.
skipping to change at page 24, line 26 skipping to change at page 25, line 22
Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman,
Alejandro Perez-Mendez, Ken Klingenstein, and Dave Crocker for Alejandro Perez-Mendez, Ken Klingenstein, and Dave Crocker for
feedback and suggestions. feedback and suggestions.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, DOI 10.17487/ Network Access Identifier", RFC 4282,
RFC4282, December 2005, DOI 10.17487/RFC4282, December 2005,
<http://www.rfc-editor.org/info/rfc4282>. <http://www.rfc-editor.org/info/rfc4282>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
skipping to change at page 26, line 10 skipping to change at page 27, line 10
[MS-CS] Brown, K., "The InfoCard Identity Revolution", July 2006, [MS-CS] Brown, K., "The InfoCard Identity Revolution", July 2006,
<https://technet.microsoft.com/en-us/ <https://technet.microsoft.com/en-us/
magazine/2006.07.infocard.aspx>. magazine/2006.07.infocard.aspx>.
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 -03 to ietf draft -04
1. Document service errors.
2. Document GSS error handling, including a request for a couple of
new GSS methods, and maintaining a log of all GSS errors for
later viewing.
IETF draft -02 to ietf draft -03 IETF draft -02 to ietf draft -03
1. Tidying up language throughout. 1. Tidying up language throughout.
2. Added the idea of an identity provider object within the identity 2. Added the idea of an identity provider object within the identity
selector, and moved the trust anchor property from the identity selector, and moved the trust anchor property from the identity
to the identity provider. to the identity provider.
3. Added restrictions on manual modification of automatically added 3. Added restrictions on manual modification of automatically added
identities and identity providers. identities and identity providers.
 End of changes. 14 change blocks. 
42 lines changed or deleted 91 lines changed or added

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