draft-ietf-abfab-usability-ui-considerations-00.txt   draft-ietf-abfab-usability-ui-considerations-01.txt 
ABFAB R. Smith ABFAB R. Smith
Internet-Draft Cardiff University Internet-Draft Cardiff University
Intended status: Informational February 13, 2014 Intended status: Informational July 4, 2014
Expires: August 17, 2014 Expires: January 5, 2015
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-00 draft-ietf-abfab-usability-ui-considerations-01
Abstract Abstract
The use of ABFAB-based technologies requires that the identities to The real world use of ABFAB-based technologies requires that any
be used to authenticate are configured on the client device. identity to be used to authenticate be configured on the ABFAB-
Achieving this requires software on that device (either built into enabled client device. Achieving this requires software on that
the operating system or a standalone utility) that will interact with device (either built into the operating system or a standalone
the user, and manage the user's identities and credential-to-service utility) that will interact with the user, managing their identity
mappings. Anyone designing that software will face the same set of information and identity-to-service mappings. All designers of
challenges. This document aims to document these challenges with the software to fulfil this role will face the same set of challenges.
aim of producing well-thought out UIs with some degree of This document aims to document these challenges with the aim of
consistency. producing well-thought out UIs with some degree of consistency
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 August 17, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Considerations around Terminology . . . . . . . . . . . . . . 6 5. Considerations around Terminology . . . . . . . . . . . . . . 5
5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 6 5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 6
6. Considerations around Management of Identities . . . . . . . . 7 6. Considerations around Management of Identities . . . . . . . 6
6.1. Information associated with each Identity . . . . . . . . 7 6.1. Information associated with each Identity . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 8
6.3.2. Manually Triggered Automated Addition . . . . . . . . 9 6.3.2. Manually Triggered Automated Addition . . . . . . . . 9
6.3.3. Fully Automated Addition . . . . . . . . . . . . . . . 10 6.3.3. Fully Automated Addition . . . . . . . . . . . . . . 10
6.4. Modifying Identity Information . . . . . . . . . . . . . . 11 6.4. Modifying Identity Information . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . 11
6.6. Removing an Identity . . . . . . . . . . . . . . . . . . . 12 6.6. Removing an Identity . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . 13
7.2. Disassociating a Service with an Identity . . . . . . . . 14 7.2. Disassociating a Service with an Identity . . . . . . . . 13
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 . . . . . . . . . . 14
7.6. Multiple Identities for a Particular Service . . . . . . . 14 7.6. Multiple Identities for a Particular Service . . . . . . 14
7.7. Not using ABFAB for a Particular Service . . . . . . . . . 14 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 8.1. Identity Association/Verification Errors . . . . . . . . 15
8.2. Service Errors . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Service Errors . . . . . . . . . . . . . . . . . . . . . 15
8.3. Other Errors. . . . . . . . . . . . . . . . . . . . . . . 15 8.3. Other Errors. . . . . . . . . . . . . . . . . . . . . . . 15
9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 15 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 15
9.1. Reporting Authentication Success on First Use of 9.1. Reporting Authentication Success on First Use of Identity 15
Identity . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Reporting Authentication Success . . . . . . . . . . . . 16
9.2. Reporting Authentication Success . . . . . . . . . . . . . 16 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 16
10.1. Identity Selector Taking Focus . . . . . . . . . . . . . . 16 10.2. Import/Export of Credentials . . . . . . . . . . . . . . 16
10.2. Import/Export of Credentials . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 16. Normative References . . . . . . . . . . . . . . . . . . . . 17
16. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The use of ABFAB-based technologies requires that the identities to The use of ABFAB-based technologies requires that any identity to be
be used to authenticate are configured on the client device. used to authenticate be configured on the client device. Achieving
Achieving this requires software on that device (either built into this requires software on that device (either built into the
the operating system or a standalone utility) that will interact with operating system or a standalone utility) that will interact with the
the user, and manage the user's identities and credential-to-service user, and manage the user's identities and credential-to-service
mappings. Anyone designing that software will face the same set of mappings. Anyone designing that software will face the same set of
challenges. This document aims to document these challenges with the challenges.
aim of producing well-thought out UIs with some degree of
consistency. This document does not intend to supplant evidence-based UI design
guidelines; implementers of identity selectors are strongly
encouraged to understand the latest in HCI and UX thought and
practice. Instead, it aims to document the common challenges faced
by implementers with the aim of providing a common starting point for
implementers in the hope that this aids in producing well-thought out
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 thus could mean a variety of different things to overloaded and could thus 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 with a consistent understanding of this used in order to aid a consistent understanding of this document.
document.
o NAI: Network Access Identifier - a standard way of identifying a o NAI: Network Access Identifier - a standard way of identifying a
user. See [RFC4282]. user and assisting in the routing of an authentication request
(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
association. A user MAY have multiple identities - potentially association. A user may have multiple identities - potentially
multiple identities per organisation, or muliple identities from a multiple identities per organisation, and also across multiple
set of organisations. The identity will consist of an NAI, organisations. Each identity will consist of an NAI, alongside
alongside other information that supports authentication. Note other information that supports authentication. Note that in
that in other contexts the usual use of "identity" would match our other contexts the usual use of "identity" would match our use of
use of "user", whereas the usual use of "identifier" matches our "user", whereas the usual use of "identifier" matches our use of
use of identity. identity.
o Service: The thing that the user is attempting to authenticate to o Service: The thing that the user is attempting to authenticate to
via ABFAB technology. See [TODO: Link to ABFAB-Use-Cases] for via ABFAB technology. See [I-D.ietf-abfab-usecases] for some
example use cases of what these services could be. example ABFAB use cases. Also known as the Relying Party.
o Identity Selector: The mechanism by which the GSS-API acquires the o Identity Selector: A piece of software that enables the process by
identity to use with a particular service. An Identity Selector which the GSS-API acquires the identity to use with a particular
typically would allow the user to configure a set of identities service. An Identity Selector typically would allow the user to
along with service to identity mappings. configure a set of identities along with service to identity
mappings.
o Trust anchor: An authoritative source of verification of a o Trust anchor: An authoritative source of verification of a
particular service, used to allow authentication of a server using particular ABFAB service or Identity Provider, used to allow
X.509 [TODO: link]. Typically a commercial CA to allow authentication of a server using X.509 [RFC5280]. Typically a
authentication via chain of trust, or a preconfigured non- commercial CA to allow authentication via chain of trust, or a
commercial certificate. preconfigured non-commercial certificate (e.g. self-signed).
4. Context 4. Context
When using the ABFAB architecture to perform federated authentication When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to
to some service, when a user attempts to authenticate to an ABFAB perform federated authentication to some service, a user will need to
secured application they will need to provide identity information provide identity information that they wish to use to authenticate to
that they wish to authenticate to that particular service with. This that particular service. This will happen through a process of the
will happen through a process of the application calling the GSS-API, application calling the GSS-API, which will in turn gather the user's
which will in turn gather the users credentials through whatever credentials through some process. We will call this process the
mechanism it has been configured to do so. We will call this "identity selector" in this document (though note that this is not a
mechanism the "identity selector" in this document (though note that recommendation on terminology for the process).
this is not a recommendation on terminology for the mechanism).
The simplest way to achieve the desired effect would be a mechanism The simplest way to achieve the desired effect would be a process
that simply takes the credentials from the currently logged in user that simply takes the credentials from the currently logged in user
(e.g. the Windows Domain Credentials) and uses those for all services (e.g. the Windows Domain Credentials) and uses those for all services
that request authenticate through ABFAB. This approach gives that request authenticate through ABFAB. This approach gives
ultimate simplicity in terms of UI - i.e. it wouldn't have one - but ultimate simplicity in terms of UI (it wouldn't have one) but the
the least flexibility. If there is ever to be a requirement for a least flexibility (the user has to use a single identity for
user to use a different set of credentials for a service, then everything). If there is ever to be a requirement for a user to use
something more complex will be needed. a different set of credentials for a service, then something more
complex will be needed.
Where there is a requirement for multiple credentials to be Where there is a requirement for multiple credentials to be
supported, there are of course two methods that could be employed to supported, there are at least two methods that could be employed to
configure identities and associated information: configure identities and associated information:
o They could be configured manually by a user in a configuration o They could be configured manually by the user in a configuration
file that could be edited by hand or some such simple mechanism, file that could be edited by hand or some such simple process, and
and read by the GSS-API mechanism. While this could work very read by the GSS-API mechanism. While this could work very well
well functionally, in practice only a small subset of users would functionally, in practice only a small subset of users would be
be happy with - and able to - configure their identities in such a happy with - and able to - configure their identities in such a
manner. manner.
o They could be configured through some interactive mechanism. For o They could be configured through some interactive process. For
ease of use this should have a simple UI, although a headless mode ease of use this should have a simple UI, although to support some
(i.e. a way of interacting with the identity selector without a use cases a headless mode (i.e. a way of interacting with the
GUI) may need to be supported. identity selector when there is no GUI present) may need to be
supported.
When designing an identity selector with a UI (or indeed, with a When designing an identity selector with a UI (or indeed, with a
headless mode), any implementer will share a common set of usability headless mode), any implementer will share a common set of usability
considerations inherent to the context. This document aims to considerations inherent to the context. This document aims to
explore these considerations, and provide advice and guidance on explore these considerations, and provide advice and guidance on
addressing them where possible. addressing them where possible.
5. Considerations around Terminology 5. Considerations around Terminology
Anyone designing an identity selector will have to grapple with Anyone designing an identity selector will have to grapple with
skipping to change at page 6, line 23 skipping to change at page 5, line 48
The first area where terminology is needed is around the identity/ The first area where terminology is needed is around the identity/
identities of the user. Users are typically used to seeing a variety identities of the user. Users are typically used to seeing a variety
of terms for aspects of their identity in the federated sense, and an of terms for aspects of their identity in the federated sense, and an
even larger variety in the wider internet sense. For example, in the even larger variety in the wider internet sense. For example, in the
federated sense some of these terms include "username", "login", federated sense some of these terms include "username", "login",
"network account", "institutional account", "home organisation "network account", "institutional account", "home organisation
account", "credentials", and a myriad of other such terms. However, account", "credentials", and a myriad of other such terms. However,
NAI - the technically correct name for their identity in an ABFAB NAI - the technically correct name for their identity in an ABFAB
sense - is highly unlikely to be one of these terms that users are sense - is highly unlikely to be one of these terms that users are
used to seeing. used to seeing. Further, given that the NAI superficially looks like
an email address, there is a definite potential for confusion.
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 is easily are abstract concepts that some users may not find is easily
understandable. Implementers may wish to keep such abstract understandable. Implementers may wish to keep such abstract
concepts, or may wish to examine attempts to map to real world concepts, 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 Microsoft Cardspace. the user's "Wallet", as used by Microsoft Cardspace.
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 suffice. probably usually suffice.
5.3. Identity to Service Mapping 5.3. Identity to Service Mapping
Depending on your perspective either each identity may be mapped to Depending on your perspective either each identity may be mapped to
multiple services, or each service has multiple identities mapped to multiple services, or each service has multiple identities mapped to
it. Thus any UI could present either perspective, or both. it. Thus any UI could present either perspective, or both.
6. Considerations around Management of Identities 6. Considerations around Management of Identities
One of the core features of an identity selector is the management of One of the core features of an identity selector is the management of
a user's identities. This section first looks at what information a user's identities. This section first looks at what information
associated with an identity will need to managed, and then looks in associated with an identity will need to managed, and then looks in
detail at various usability considerations of this area. detail at various usability considerations of this area.
6.1. Information associated with each Identity 6.1. Information associated with each Identity
There is firstly a minimal set of information that MUST be stored The bare minimum set of information that MUST be stored about each
about each identity to allow ABFAB authentication to take place: identity to allow ABFAB authentication to take place is a single
item:
o NAI: The user's Network Access Identifier (see [RFC4282]) for this o NAI: The user's Network Access Identifier (see [RFC4282]) for this
particular credentials. For example, "joe@example.com". particular credential. For example, "joe@example.com". Note that
the identity selector MUST NOT store different identities that use
the same NAI. This is required as the NAI is the unique key that
is used by the identity selector when interacting with the GSS-API
mechanism for various reasons, for example, to allow the GSS-API
mechanism to report back error or success statuses.
Next up is a small set of information that SHOULD be stored about
each identity to allow the user to effectively select a particular
identity:
o Trust anchor: For the identity selector to be able to verify that o Trust anchor: For the identity selector to be able to verify that
the server it is going to talk to and attempt to authenticate the server it is going to talk to and attempt to authenticate
against is the server that it is expecting, and that it is not against is the server that it is expecting, and that it is not
being spoofed in some way. This is likely to be an X.509 being spoofed in some way. This is likely to be an X.509
certificate [TODO X509 ref], or a tuple of (trusted root certificate [RFC5280], or a tuple of (trusted root certificate,
certificate, servername in Subject or subjectAltName). servername in Subject or subjectAltName). Storing a credential
without a relevant trust anchor allows for the possibility of a
Next up is a small set of information that SHOULD be stored about malicious attacker intercepting traffic and masquerading as the
each identity to allow the user to effectively select a particular server in question.
identity:
o Credential: Whatever is used by the user to authenticate o Credential: Whatever is used by the user to authenticate
themselves with a particular NAI. What this will be will be themselves with a particular NAI. What exactly this will be will
dependent on the EAP method being used, but is likely to be be dependent on the EAP method being used, but is likely to be
something like a password or a certificate. Note that this is a something like a password or a certificate. Note that this is a
SHOULD, rather than a MUST, because there are use cases where the SHOULD, rather than a MUST, because there are use cases where a
user specifically chooses for this not to be "remembered". user may specifically opt for this not to be "remembered".
Finally, there is a set of optional information that MAY be stored
about each identity that represent useful information for the user to
have and could make an identity selector more usable. Note that this
list is neither intended to be exhaustive or even particularly
correct; any implementer is free to use whatever make sense in their
implementation and conforms to good HCI/UX guidelines. Instead, it
is simply a suggested starting point.
o Friendly name for identity: To allow the user to differentiate o Friendly name for identity: To allow the user to differentiate
between the set of identities represented in the Identity between the set of identities represented in the Identity
Selector. This should be editable by the user. The only Selector. This should be editable by the user. The only
restriction on this name is that it MUST be unique within that restriction on this name is that it MUST be unique within that
particular user's set of identities. For example: "My particular user's set of identities. For example: "My
University", "Google Account", "Work Login", etc. University", "Google Account", "Work Login", etc.
o Friendly icon for identity: To allow the user to differentiate o Friendly icon for identity: To allow the user to differentiate
between the set of identities they have they should be able to set between the set of identities they have they should be able to set
an icon for that particular identity. an icon for that particular identity.
Finally, there is a set of optional information that MAY be stored
about each identity that represent useful information for the user to
have. Note that this list is not intended to be exhaustive; any
implementer is free to add any more items to their identity selector
that make sense in their implementation.
o Password changing URL: The URL the user should visit should they o Password changing URL: The URL the user should visit should they
need to change their password for this particular identity. For need to change their password for this particular identity. For
example, "http://www.example.com/passwordreset". example, "http://www.example.com/passwordreset".
o Helpdesk URL: The URL the user should visit to get contact details o Helpdesk URL: The URL the user should visit to get contact details
for the helpdesk of the organisation that issued this particular for the helpdesk of the organisation that issued this particular
identity for when the user encounters issues and needs help. For identity for when the user encounters issues and needs help. For
example, https://www.example.com/helpdesk. example, https://www.example.com/helpdesk.
6.2. Storage of Identity Information 6.2. Storage of Identity Information
skipping to change at page 8, line 49 skipping to change at page 8, line 39
are provisioning identities into the UI, provisioning is an are provisioning identities into the UI, provisioning is an
overloaded term in the identity and access management space and could overloaded term in the identity and access management space and could
easily be confused with identity provisioning in the sense of the easily be confused with identity provisioning in the sense of the
creation of the identity by the home organisation's identity creation of the identity by the home organisation's identity
management procedures. management procedures.
6.3.1. Manual Addition 6.3.1. Manual Addition
Allowing users to manually add an identity is technically the easiest Allowing users to manually add an identity is technically the easiest
method to get this information, but it is a method that has the method to get this information, but it is a method that has the
greatest usability drawbacks. Most of the information required is greatest usability drawbacks - including some that create potential
relatively technical and finding some way of explaining what each security issues. Most of the information required is relatively
field is to an non-technical audience is challenging (to say the technical and finding some way of explaining what each field is to an
least). This especially is the case for trust anchor information. non-technical audience is challenging (to say the least). This
Thus this method should be considered as a power-user option only, or especially is the case for trust anchor information. Thus this
as a fall-back should the other methods not be applicable. method should be considered as a power-user option only, or as a
fall-back should the other methods not be applicable. Implementers
may well decide not to offer the manual option due to these
drawbacks.
When this method is used, careful consideration should be given to 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 the UI presented to the user. The UI will have to ask for all of the
information detailed in Section 6.1. information detailed in Section 6.1.
There are two points at which a user could manually add an identity: There are two points at which a user could manually add an identity:
o Asynchronously: the user could be allowed to, at any time, trigger o Asynchronously: the user could be allowed to, at any time, trigger
a workflow of manually adding an identity. This represents the a workflow of manually adding an identity. This represents the
most flexible way of adding an identity since a user can perform most flexible way of adding an identity since a user can perform
this at any time. It does, however, have inherent issues when it this at any time. It does, however, also have inherent issues
comes to verifying the newly added identity - see Section 6.5. when it comes to verifying the newly added identity - see
Section 6.5.
o Just In Time: when connecting to a service which has no mapping to o Just In Time: when connecting to a service which has no mapping to
an existing identity, the user could be given an option to add a an existing identity, the user could be given an option to add a
new one, as well as associating with an existing one. This new one, as well as associating with an existing one. This seems
presents a better user experience when it comes to verifying the to present a better user experience when it comes to verifying the
newly added identity (see Section 6.5), however, represents a less newly added identity (see Section 6.5), however, it represents a
direct method of adding an identity. Users who have not yet added less direct method of adding an identity. Users who have not yet
the appropriate identity to their identity selector may find it added the appropriate identity to their identity selector may find
difficult to understand that they must try to access a particular it difficult to understand that they must try to access a
service in order to add an identity. particular service in order to add an identity.
Of course, implementers could support both styles of identity Of course, implementers could support both styles of identity
addition to gain the benefits of both and give flexibility to the addition to gain the benefits of both and give flexibility to the
user. user.
One item worthy of discussion here is the area of verification of Finally, the area of verification of trust anchors is very important.
trust anchors. An Identity Selector SHOULD try to ensure that manual An Identity Selector that allows for manual addition of identity
addition of an identity and checking of the relevant trust anchors is information SHOULD try to ensure that trust anchor information is
done as securely as possible, whereby users have to enter and confirm gathered and checked in a secure a manner as possible - where users
all trust anchor information, or be required to explicitly agree to have to enter and confirm all trust anchor information, or be
an insecure configuration if this is not done properly. required to explicitly agree to an insecure configuration if this is
not done properly.
6.3.2. Manually Triggered Automated Addition 6.3.2. Manually Triggered Automated Addition
One way to bypass the need for manual addition of a user's identity - One way to bypass the need for manual addition of a user's identity -
and all of the usability issues inherent with that approach - is to and all of the usability and security issues inherent with that
provide some sort of manually triggered, but automated, provisioning approach - is to provide some sort of manually triggered, but
process. automated, addition process.
One approach to accomplishing this, for example, could be for an One approach to accomplishing this, for example, could be for an
organisation to have a section on their website where their users organisation to have a section on their website where their users
could visit, enter the user part of their NAI, and be given piece of could visit, enter the user part of their NAI, and be given piece of
provisioning data that contains much or all of the relevant identity data that contains much or all of the relevant identity information
information for importing into the identity selector. for importing into the identity selector.
It is reasonable to assume that any such provisioning service is It is reasonable to assume that any such automated addition service
likely to be organisation specific, so that the Issuing Organisation is likely to be organisation specific, so that the Issuing
and realm part of the NAI will be constant, as would be the trust Organisation and realm part of the NAI will be constant, as would be
anchor information. The user part of their NAI will have been input the trust anchor information. The user part of their NAI will have
on the web service. The password could be provided as a part of the been input on the web service. The password could be provided as a
provisioning file or the identity selector could prompt the user to part of the provided data or the identity selector could prompt the
enter it. user to enter it.
Additionally, the user SHOULD be given the opportunity to: Additionally, the user SHOULD be given the opportunity to:
o Supply or change the default friendly name for that identity - to o Supply or change the default friendly name for that identity - to
allow the user to customise the identifier they use for that allow the user to customise the identifier they use for that
identity; identity;
o Indicate whether or not the identity selector should always ask o Indicate whether or not the identity selector should always ask
before using services with this identity - to customise the way in before using services with this identity - to customise the way in
which the identity selector interacts with the user with this which the identity selector interacts with the user with this
particular identity; particular identity;
o Reject the addition of the identity completely - to allow the user o Reject the addition of the identity completely - to allow the user
to back out of the association process in an intuitive way. to back out of the association process in an intuitive way.
In this case, trust anchors could be directly provided through the In this case, trust anchors could be directly provided through the
provisioning mechanism to help establish the trust relationship in a automated addition process to help establish the trust relationship
secure manner. in a secure manner.
6.3.3. Fully Automated Addition 6.3.3. Fully Automated Addition
Many organisations manage the machines of their users using Many organisations manage the machines of their users using
enterprise management tools. Such organisations may wish to be able enterprise management tools. Such organisations may wish to be able
to automatically add a particular user's identity to the identity to automatically add a particular user's identity to the identity
selector on their machine/network account so that the user has to do selector on their machine/network account so that the user has to do
nothing. nothing.
This represents the best usability for the user - who wouldn't This represents the best usability for the user - who wouldn't
actually have to do anything. However, it can only work on machines actually have to do anything. However, it can only work on machines
centrally managed by the organisation. centrally managed by the organisation.
Additionally, having an identity automatically provided, including Additionally, having an identity automatically provided, including
its password, does have some particular usability issues. Users are its password, does have some particular usability issues. Users are
used to having to provide their username and password to access used to having to provide their username and password to access
services. When attempting to access services, authenticating to them remote services. When attempting to access services, authenticating
completely transparently to the user could represent a source of to them completely transparently to the user could represent a source
confusion. User training within an organisation to explain that of confusion. User training within an organisation to explain that
automated provisioning of their identity has been enabled is the only automated population of their identity has been enabled is the only
way to counter this. way to counter this.
6.4. Modifying Identity Information 6.4. Modifying Identity Information
This process is conceptually fairly similar to adding an identity, This process is conceptually fairly similar to adding an identity,
and thus shares many of the usability issues with that process. Some and thus shares many of the usability issues with that process. Some
particular things are discussed here. particular things are discussed here.
6.4.1. Manual Modification 6.4.1. Manual Modification
An identity selector may allow a user to manually modify some or all An identity selector may allow a user to manually modify some or all
of the information associated with each identity. The obvious item of the information associated with each identity. The obvious item
that MUST be allowed to be changed by the user is the password that SHOULD be allowed to be changed by the user is the password
associated with the identity. associated with the identity.
6.4.2. Automated Modification 6.4.2. Automated Modification
To ease usability, organisations may wish to automatically provide To ease usability, organisations may wish to automatically provide
updates to identity information. For example, if the user's password updates to identity information. For example, if the user's password
changes, it could automatically update the password for the identity changes it could automatically update the password for the identity
in the user's identity selector. in the user's identity selector, or if the trust anchor information
changes (e.g. if a certificate is changed) it could be automatically
pushed out to all users.
6.5. Verifying an identity 6.5. Verifying an identity
An inherent by-product of the ABFAB architecture is that an identity An inherent by-product of the ABFAB architecture is that an identity
cannot be verified during the addition process; it can only be cannot be verified during the addition process; it can only be
verified while it is in use with a real service. This represents a verified while it is in use with a real service. This represents a
definite usability issue no matter which method of identity addition definite usability issue no matter which method of identity addition
is used (see Section 6.3): is used (see Section 6.3):
o If the user has manually added the identity (see Section 6.3) they o If the user has manually added the identity (see Section 6.3) they
may have gone through the whole manual process with no errors and may have gone through the whole manual process with no errors and
so believe the identity has been set up correctly. However, when so believe the identity has been set up correctly. However, when
they attempt to access a service, they may be given an error they attempt to access a service, they may be given an error
message, thus causing some amount of confusion. message, thus causing some amount of confusion.
o If the user has had the identity provisioned into their identity o If the user has had the identity populated into their identity
selector, then there is a much greater chance of the identity selector, then there is a much greater chance of the identity
information being correct. However, if any of the information is information being correct. However, if any of the information is
not correct, then there is the potential for confusion as the user not correct, then there is the potential for confusion as the user
did not add the information in the first place. did not add the information in the first place.
Also, if the identity information is incorrect the user may not know Also, if the identity information is incorrect the user may not know
where the error lies, and the error messages provided by the where the error lies, and the error messages provided by the process
mechanism may not be helpful enough to indicate the error and how to may not be helpful enough to indicate the error and how to fix it
fix it (see Section 8). (see Section 8).
6.6. Removing an Identity 6.6. Removing an Identity
This is fairly similar to adding or modifying an identity, and thus This is fairly similar to adding or modifying an identity, and thus
shares many of the usability issues with those processes. Some shares many of the usability issues with those processes. Some
particular things are discussed here. particular things are discussed here.
6.6.1. Manual Removal 6.6.1. Manual Removal
Allowing the user to manually delete an identity is probably the best Allowing the user to manually delete an identity is probably the best
skipping to change at page 12, line 41 skipping to change at page 12, line 35
7. Considerations around Management of Service to Identity Mappings 7. Considerations around Management of Service to Identity Mappings
A service to identity mapping tells the identity selector which A service to identity mapping tells the identity selector which
identity should be used for a particular service. There is identity should be used for a particular service. There is
potentially a many-to-many association between identities and potentially a many-to-many association between identities and
services since a user may wish to use one of their identities for services since a user may wish to use one of their identities for
many services, or more than one identity for a single service (e.g. many services, or more than one identity for a single service (e.g.
if they have multiple roles on that service). if they have multiple roles on that service).
This potentially complex many-to-many association between is not This potentially complex many-to-many association between identities
easily comprehended by the user, and allowing the user to both and services is not easily comprehended by the user, and allowing the
manipulate it and control can be challenging. These obstacles are user to both manipulate it and control can be challenging. These
especially common when errors occur after an association has been obstacles are especially common when errors occur after an
made. In this scenario it is important that an identity can be association has been made. In this scenario it is important that an
disassociated with a service. identity can be disassociated with a service.
To further complicate the picture, users may wish for: To further complicate the picture, users may wish for:
1. The identity to service mapping to be stored along with the 1. The identity to service mapping to be stored along with the
credential, i.e. the user should always be authenticated to a credential, i.e. the user should always be authenticated to a
particular service with a particular identity with no prompting. particular service with a particular identity with no prompting.
2. The identity to service mapping to be stored but not the 2. The identity to service mapping to be stored but not the
credential, i.e. the user should not be prompted to choose the credential, i.e. the user should not be prompted to choose the
identity for a particular service, but should be prompted to identity for a particular service, but should be prompted to
skipping to change at page 14, line 23 skipping to change at page 14, line 17
failures. failures.
7.3. Listing Services and Identities 7.3. Listing Services and Identities
A service listing should be considered in the identity selector which A service listing should be considered in the identity selector which
is both searchable and editable by the user. is both searchable and editable by the user.
7.4. Showing the Service that is requesting Authentication 7.4. Showing the Service that is requesting Authentication
When a user is attempting to authenticate to a service for the first When a user is attempting to authenticate to a service for the first
time, there should be some indiciation given to the user as to which time, there should be some indication given to the user as to which
service is requesting authentication. In many cases, the service may service is requesting authentication. In many cases, the service may
be obvious (where the user has started the process of attempting to be obvious (where the user has started the process of attempting to
authenticate to a particular service), but in other cases this may authenticate to a particular service), but in other cases this may
not be obvious (e.g. if an authentication attempt is triggered by a not be obvious (e.g. if an authentication attempt is triggered by a
timer or a specific event), and for this scenario some indiciation as timer or a specific event), and for this scenario some indication as
to the requesting service is necessary. to the requesting service is necessary.
7.5. Showing the Identity currently in use 7.5. Showing the Identity currently in use
It would be beneficial if, when using a service, the identity It would be beneficial if, when using a service, the identity
currently in use could be made visible to the user while he/she is currently in use could be made visible to the user while they are
using a specific service. This allows the user to identify which the using a specific service. This allows the user to identify which
identity is used with a particular service at a particular time (the identity is used with a particular service at a particular time (the
user may have more than one identity that they could use with a user may have more than one identity that they could use with a
particular service) - so that they can then disassociate the pairing. particular service) - so that they can then disassociate the pairing.
Implementing such a feature may be hard, however, due to the layered
nature of the ABFAB transaction - the identity selector will
certainly know when successful (or failed) authentications to a
particular service have happened, but after that it typically plays
no further part in the use of the service. Therefore, knowing that a
particular service is still using a particular identity in order to
indicate this to the user would be challenging.
7.6. Multiple Identities for a Particular Service 7.6. Multiple Identities for a Particular Service
An Identity Selector should be able to deal with the case where a An Identity Selector should be able to deal with the case where a
user has multiple identities associated with a single service. For user has multiple identities associated with a single service. For
example, upon receiving a request for authentication to a service example, upon receiving a request for authentication to a service
that multiple identities are configured for, ask the user which of that multiple identities are configured for, ask the user which of
the identities should be used in this instance. the identities should be used in this instance.
7.7. Not using ABFAB for a Particular Service 7.7. Not using ABFAB for a Particular Service
skipping to change at page 15, line 18 skipping to change at page 15, line 24
8. Handling of Errors 8. Handling of Errors
All GSS-API calls need to be instantiated from the application. For 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 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 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 tedious and cause the user to opt out of what they are trying to
accomplish. In addition to this the error messages themselves may accomplish. In addition to this the error messages themselves may
not be useful enough for the user to decipher what has gone wrong. 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 It is important to try and avoid error cases all together while using
GSS-API as error messages and error handling can really effect GSS-API as error messages and error handling can really affect
usability. Another solution would be to alter the application to usability. Another solution would be to alter the application to
handle the errors as it is instantiating the GSS-API communication. handle the errors as it is instantiating the GSS-API communication.
TODO: Lots more to discuss here... TODO: Lots more to discuss here...
8.1. Identity Association/Verification Errors 8.1. Identity Association/Verification Errors
TODO: e.g. wrong password, bad trust anchors, etc. TODO. TODO: e.g. wrong password, bad trust anchors, etc. TODO.
8.2. Service Errors 8.2. Service Errors
skipping to change at page 16, line 44 skipping to change at page 16, line 46
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, Stefan, David. Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, Mark
Donally, Dave Crocker.
13. Security Considerations 13. Security Considerations
TODO: Bad trust anchors, no trust anchors, phishing. TODO: Bad trust anchors, no trust anchors, phishing.
14. Privacy Considerations 14. Privacy Considerations
TODO: See Arch for general discussion. Particular to UI - storing TODO: See Arch for general discussion. Particular to UI - storing
credentials on a particular device, mobility considerations. credentials on a particular device, mobility considerations.
skipping to change at page 17, line 22 skipping to change at page 17, line 26
This document does not require actions by IANA. This document does not require actions by IANA.
16. Normative References 16. 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, March 1997. 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. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-12 (work
in progress), February 2014.
[I-D.ietf-abfab-usecases]
Smith, R., "Application Bridging for Federated Access
Beyond web (ABFAB) Use Cases", draft-ietf-abfab-
usecases-05 (work 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 -00 to ietf draft -01
1. Tidying up language throughout
2. Doing some of the TODOs
3. Added language that tries to explain that this document is not a
substitute for good HCI/UX design.
4. Changed terminology slightly to avoid confusion between an
identity selector "mechanism" and a GSS-API mechanism.
5. Added a caveat about the potential for the UI to show the
identity currently in use for a particular service.
6. Added a requirement that the identity selector must not store the
same NAI for multiple identities.
7. Stopped talking about "provisioning" after saying that I wouldn't
talk about "provisioning".
Draft -04 to ietf draft -00 Draft -04 to ietf draft -00
1. Adding brief discussion of identities vs identifiers (Ken). 1. Adding brief discussion of identities vs identifiers (Ken).
2. Changing assumption about credentials having a password in favour 2. Changing assumption about credentials having a password in favour
of more generic text for other auth types. of more generic text for other auth types.
3. Adding discussion of storage of identity information. 3. Adding discussion of storage of identity information.
4. Added sections on dealing with multiple identities per service, 4. Added sections on dealing with multiple identities per service,
 End of changes. 51 change blocks. 
197 lines changed or deleted 270 lines changed or added

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