< draft-ietf-abfab-usability-ui-considerations-02.txt   draft-ietf-abfab-usability-ui-considerations-03.txt >
ABFAB R. Smith ABFAB R. Smith
Internet-Draft Cardiff University Internet-Draft Cardiff University
Intended status: Informational July 6, 2015 Intended status: Informational M. Donnelly
Expires: January 7, 2016 Expires: April 21, 2016 Painless Security
October 19, 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-02 draft-ietf-abfab-usability-ui-considerations-03
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 40 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 January 7, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 7 5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 6
6. Considerations around Management of Identities . . . . . . . . 7 6. Considerations around Management of Identities . . . . . . . 7
6.1. Information associated with each Identity . . . . . . . . 7 6.1. Information associated with each Identity . . . . . . . . 7
6.2. Storage of Identity Information . . . . . . . . . . . . . 8 6.2. Information associated with each Identity Provider . . . 8
6.3. Adding/Association of an Identity . . . . . . . . . . . . 8 6.3. Storage of Identity Information . . . . . . . . . . . . . 9
6.3.1. Manual Addition . . . . . . . . . . . . . . . . . . . 9 6.4. Adding/Association of an Identity . . . . . . . . . . . . 10
6.3.2. Manually Triggered Automated Addition . . . . . . . . 10 6.4.1. Identity Provider Addition . . . . . . . . . . . . . 10
6.3.3. Fully Automated Addition . . . . . . . . . . . . . . . 11 6.4.2. Identity Addition . . . . . . . . . . . . . . . . . . 12
6.4. Modifying Identity Information . . . . . . . . . . . . . . 11 6.5. Modifying Identity Information . . . . . . . . . . . . . 14
6.4.1. Manual Modification . . . . . . . . . . . . . . . . . 11 6.5.1. Manual Modification . . . . . . . . . . . . . . . . . 14
6.4.2. Automated Modification . . . . . . . . . . . . . . . . 11 6.5.2. Automated Modification . . . . . . . . . . . . . . . 15
6.5. Verifying an identity . . . . . . . . . . . . . . . . . . 12 6.6. Verifying an identity . . . . . . . . . . . . . . . . . . 15
6.6. Removing an Identity . . . . . . . . . . . . . . . . . . . 12 6.7. Removing an Identity . . . . . . . . . . . . . . . . . . 15
6.6.1. Manual Removal . . . . . . . . . . . . . . . . . . . . 12 6.7.1. Manual Removal . . . . . . . . . . . . . . . . . . . 15
6.6.2. Automated Removal . . . . . . . . . . . . . . . . . . 12 6.7.2. Automated Removal . . . . . . . . . . . . . . . . . . 16
6.7. Storing an Identity with or without credentials . . . . . 12 6.8. Storing an Identity with or without credentials . . . . . 16
7. Considerations around Management of Service to Identity 7. Considerations around Management of Service to Identity
Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Associating a Service with an Identity . . . . . . . . . . 13 7.1. Associating a Service with an Identity . . . . . . . . . 17
7.1.1. User-driven Manual Association . . . . . . . . . . . . 13 7.1.1. User-driven Manual Association . . . . . . . . . . . 17
7.1.2. Automated Rules-based Association . . . . . . . . . . 14 7.1.2. Automated Rules-based Association . . . . . . . . . . 17
7.2. Disassociating a Service with an Identity . . . . . . . . 14 7.1.3. Association Conflicts . . . . . . . . . . . . . . . . 17
7.3. Listing Services and Identities . . . . . . . . . . . . . 14 7.2. Disassociating a Service with an Identity . . . . . . . . 18
7.4. Showing the Service that is requesting Authentication . . 14 7.3. Listing Services and Identities . . . . . . . . . . . . . 19
7.5. Showing the Identity currently in use . . . . . . . . . . 15 7.4. Showing the Service that is requesting Authentication . . 19
7.6. Multiple Identities for a Particular Service . . . . . . . 15 7.5. Showing the Identity currently in use . . . . . . . . . . 19
7.7. Not using ABFAB for a Particular Service . . . . . . . . . 15 7.6. Multiple Identities for a Particular Service . . . . . . 20
8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . . 15 7.7. Not using ABFAB for a Particular Service . . . . . . . . 20
9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 16 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . 20
9.1. Reporting Authentication Success on First Use of 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 21
Identity . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Reporting Authentication Success on First Use of Identity 21
9.2. Reporting Authentication Success . . . . . . . . . . . . . 17 9.2. Reporting Authentication Success . . . . . . . . . . . . 21
10. Other Considerations . . . . . . . . . . . . . . . . . . . . 21
10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 21
10.1. Identity Selector Taking Focus . . . . . . . . . . . . . . 17 10.2. Import/Export of Credentials . . . . . . . . . . . . . . 22
10.2. Import/Export of Credentials . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . 24
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 5, line 6 skipping to change at page 4, line 23
organisations. Each identity will consist of an NAI, alongside organisations. Each identity will consist of an NAI, alongside
other information that supports authentication. Note that in other information that supports authentication. Note that in
other contexts the usual use of "identity" would match our use of other contexts the usual use of "identity" would match our use of
"user", whereas the usual use of "identifier" matches our use of "user", whereas the usual use of "identifier" matches our 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 [I-D.ietf-abfab-usecases] for some via ABFAB technology. See [I-D.ietf-abfab-usecases] for some
example ABFAB use cases. Also known as the Relying Party. example ABFAB use cases. Also known as the Relying Party.
o Identity Provider: The thing able to make access management
decisions about the Identity.
o Identity Selector: A piece of software that enables the process by o Identity Selector: A piece of software that enables the process by
which the GSS-API acquires the identity to use with a particular which the GSS-API acquires the identity to use with a particular
service. An Identity Selector typically would allow the user to service. An Identity Selector typically would allow the user to
configure a set of identities along with service to identity configure a set of identities along with service to identity
mappings. mappings.
o Trust anchor: An authoritative source of verification of a o Trust anchor: An authoritative source of verification of a
particular ABFAB service or Identity Provider, used to allow particular ABFAB Identity Provider, used to allow authentication
authentication of a server using X.509 [RFC5280]. Typically a of an Identity Provider using X.509 [RFC5280]. Typically this
commercial CA to allow authentication via chain of trust, or a will be a commercial CA to allow authentication via chain of
preconfigured non-commercial certificate (e.g. self-signed). trust, or a preconfigured non-commercial certificate (e.g. self-
signed).
o Credential: Whatever is used by the user to authenticate
themselves with a particular NAI. What exactly this will be will
be dependent on the EAP method being used, but is likely to be
something like a password or a certificate.
4. Context 4. Context
When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to
perform federated authentication to some service, a user will need to perform federated authentication to some service, a user will need to
provide identity information that they wish to use to authenticate to provide identity information that they wish to use to authenticate to
that particular service. This will happen through a process of the that particular service. This will happen through a process of the
application calling the GSS-API, which will in turn gather the user's application calling the GSS-API, which will in turn gather the user's
credentials through some process. We will call this process the credentials through some process. We will call this process the
"identity selector" in this document (though note that this is not a "identity selector" in this document (though note that this is not a
recommendation on terminology for the process). recommendation on terminology for the process).
The simplest way to achieve the desired effect would be a process 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 (it wouldn't have one) but the ultimate simplicity in terms of UI (it wouldn't have one) but the
least flexibility (the user has to use a single identity for least flexibility (the user has to use a single identity for
everything). If there is ever to be a requirement for a user to use everything). If there is ever to be a requirement for a user to use
a different set of credentials for a service, then something more a different set of credentials for a service, or a requirement for
complex will be needed. the user to use ABFAB to authenticate to the operating system, 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 at least 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 the 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 process, and file that could be edited by hand or some such simple process, and
read by the GSS-API mechanism. While this could work very well read by the GSS-API mechanism. While this could work very well
functionally, in practice only a small subset of users would be functionally, in practice only a small subset of users would be
happy with - and able to - configure their identities in such a happy with - and able to - configure their identities in such a
skipping to change at page 6, line 26 skipping to change at page 6, line 10
Anyone designing an identity selector will have to grapple with Anyone designing an identity selector will have to grapple with
choosing terminology that the average user has some chance of choosing terminology that the average user has some chance of
understanding. This terminology can split into a few main functional understanding. This terminology can split into a few main functional
areas, as discussed next. areas, as discussed next.
5.1. Identity 5.1. Identity
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. Further, given that the NAI superficially looks like used to seeing. Further, given that the NAI superficially looks like
an email address, there is a definite potential for confusion. 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 easily
understandable. Implementers may wish to keep such abstract understandable. Implementers may wish to keep such abstract concepts
concepts, 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 Microsoft Cardspace. the user's "Wallet", as used by the new defunct Microsoft Cardspace
([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.
5.3. Identity to Service Mapping 5.3. Identity to Service Mapping
The basic functionality of the Identity Selector is to create the
correct combination of Identity and Service, so that the correct
identity is chosen to create the credential for the GSS-EAP
connection with the given service. Mapping is the process of
creating this relationship between identity and service.
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 manage, 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
The bare minimum set of information that MUST be stored about each The bare minimum set of information that MUST be stored about each
identity to allow ABFAB authentication to take place is a single identity to allow ABFAB authentication to take place is a single
item: 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 credential. For example, "joe@example.com". Note that particular credential. For example, "joe@example.com". Note that
the identity selector MUST NOT store different identities that use the identity selector MUST NOT store different identities that use
the same NAI. This is required as the NAI is the unique key that 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 is used by the identity selector when interacting with the GSS-API
mechanism for various reasons, for example, to allow the GSS-API mechanism for various reasons, for example, to allow the GSS-API
mechanism to report back error or success statuses. mechanism to report back error or success statuses or to allow the
application to request the use of a specific identity.
Next up is a small set of information that SHOULD be stored about Next up is a small set of information that SHOULD be stored about
each identity to allow the user to effectively select a particular each identity to allow the user to effectively select a particular
identity: identity:
o Trust anchor: For the identity selector to be able to verify that o Identity provider realm: The ABFAB realm of the identity provider.
the server it is going to talk to and attempt to authenticate This is used as a key to look up the identity provider from the
against is the server that it is expecting, and that it is not identity selector's list of identity providers, in order to access
being spoofed in some way. This is likely to be an X.509 the trust anchor during verification of the identity provider.
certificate [RFC5280], or a tuple of (trusted root certificate,
servername in Subject or subjectAltName). Storing a credential
without a relevant trust anchor allows for the possibility of a
malicious attacker intercepting traffic and masquerading as the
server in question.
o Credential: Whatever is used by the user to authenticate o Credential: Whatever is used by the users to authenticate
themselves with a particular NAI. What exactly this will be will themselves with a particular NAI. What exactly this will be will
be 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 the
SHOULD, rather than a MUST, because there are use cases where a identity selector SHOULD allow a user to store the credential.
user may specifically opt for this not to be "remembered". However, there are use cases where a user may specifically opt for
this not to be "remembered", so the identity selector MUST NOT
store the credential without confirmation from the user.
Finally, there is a set of optional information that MAY be stored Finally, there is a set of optional information that MAY be stored
about each identity that represent useful information for the user to about each identity that represent useful information for the user to
have and could make an identity selector more usable. Note that this have and could make an identity selector more usable. Note that this
list is neither intended to be exhaustive or even particularly list is neither intended to be exhaustive or even particularly
correct; any implementer is free to use whatever make sense in their correct; any implementer is free to use whatever make sense in their
implementation and conforms to good HCI/UX guidelines. Instead, it implementation and conforms to good HCI/UX guidelines. Instead, it
is simply a suggested starting point. 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: "Student
University", "Google Account", "Work Login", etc. username", "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.
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?identifier=myId".
o Helpdesk URL: The URL this particular identity should visit to get
contact details for the helpdesk of the organisation that issued
this particular identity for when the user encounters issues and
needs help. For example, https://www.example.com/
helpdesk?identifier=myId.
6.2. Information associated with each Identity Provider
Identity providers are entities that may be shared across multiple
identities. For instance, a person at a university may have one
identity as a student and another identity as an employee, but a
single identity provider makes access management decisions about
both. In these cases, the identity selector MUST consider it an
error if the trust anchor for the identity provider is different
between the various identities managed by the single identity
provider.
The bare minimum set of information that MUST be stored about each
identity provider is:
o Realm: The realm of the identity provider. This will uniquely
identify the identity realm.
o Trust anchor: For the identity selector to be able to verify that
the Identity Provider it is going to talk to and attempt to
authenticate against is the Identity Provider that it is
expecting, and that it is not being spoofed in some way. This is
likely to be an X.509 certificate [RFC5280], or a tuple of
(trusted root certificate, servername in Subject or
subjectAltName). Storing a credential without a relevant trust
anchor allows for the possibility of a malicious attacker
intercepting traffic and masquerading as the Identity Provider in
question.
Identity providers also have a set of optional information that MAY
be stored about each identify provider. This set includes, but is
not limited to:
o Friendly name for the identity provider: To allow the user to
differentiate between the set of identity providers represented in
the Identity Selector. This should be editable by the user. The
only restriction on this name is that it MUST be unique within
that particular user's set of identity providers. For example:
"My University", "Google", etc.
o Friendly icon for the identity provider: To allow the user to
differentiate between the set of identity providers they have they
should be able to set an icon for that particular identity
provider.
o Password changing URL: The URL the user should visit should they
need to change passwords for identities in this realm. 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 Note that the password changing URL and helpdesk URL somewhat mirror
the definitions of the same fields in the identity. The distinction
is that the URLs in the identity SHOULD apply to the individual
identity, whereas the URLs in the identity provider SHOULD apply to
all identities that the identity provider defines. For example, an
identity password change URL would provide a personalized experience
of changing the password for the given identity, but the identity
provider password change URL would direct the user to a page where
the user would need to enter the individual identity that needs a new
password.
If the identity contains no password change URL or helpdesk URL, the
identity selector MAY present any corresponding URL from the identity
selector instead. However, if the identity contains the URL, the
identity selector SHOULD present the URL from the identity.
6.3. Storage of Identity Information
Since some of the information that makes up the identity is sensitive Since some of the information that makes up the identity is sensitive
in nature (e.g. containing passwords), then this information SHOULD in nature (e.g. containing passwords), then this information SHOULD
be stored and accessed securely. This might involve ensuring the be stored and accessed securely. This might involve ensuring the
credential information is held in encrypted form on device and credential information is held in encrypted form on device and
accessed using a passphrase. For deeper integration into the system, accessed using a passphrase. For deeper integration into the system,
this could be done by using existing secure storage on the system this could be done by using existing secure storage on the system
such as Keychain on a Mac or the GNOME keyring on a GNOME based Linux such as Keychain on a Mac, the GNOME keyring on a GNOME based Linux
device. device, or the Credentials Manager on Windows.
6.3. Adding/Association of an Identity 6.4. Adding/Association of an Identity
Users will have one or more identities given to them by organisations Users will have one or more identities given to them by organisations
that they have a relationship with. One of the core tasks of an that they have a relationship with. One of the core tasks of an
identity selector will be to learn about these identities in order to identity selector will be to learn about these identities and their
use them when it comes to authenticating to services on behalf of the identity providers in order to use them when it comes to
user. Adding these identities could be done in one of three ways: authenticating to services on behalf of the user. Adding these
manual addition, automated addition that is manually triggered, or identities could be done in one of three ways: manual addition,
automated addition that is automatically triggered. Each of these automated addition that is manually triggered, or automated addition
are discussed in more detail next. that is automatically triggered. Each of these are discussed in more
detail next.
Note that the term "association" or "addition" of an identity is used Note that the term "association" or "addition" of an identity is used
rather than "provisioning" of an identity, because while we actually rather than "provisioning" of an identity, because while we actually
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.4.1. Identity Provider Addition
Allowing users to manually add an identity is technically the easiest 6.4.1.1. Manual Identity Provider Addition
method to get this information, but it is a method that has the
greatest usability drawbacks - including some that create potential Allowing users to add an identity provider manually is technically
security issues. Most of the information required is relatively the easiest method to get this information, but it is a method that
technical and finding some way of explaining what each field is to an has the greatest usability drawbacks - including some that create
non-technical audience is challenging (to say the least). This potential security issues. Most of the information required is
especially is the case for trust anchor information. Thus this relatively technical and finding some way of explaining what each
method should be considered as a power-user option only, or as a field is to an non-technical audience is challenging (to say the
fall-back should the other methods not be applicable. Implementers least). This especially is the case for trust anchor information.
may well decide not to offer the manual option due to these Thus this method should be considered as a power-user option only, or
drawbacks. 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.2.
Trust anchors present a particularly onerous challenge for the user
to enter. For this reason, many identity selectors will want to
implement a leap-of-faith acquisition of the trust anchor. For these
leap of faith acquisitions, the identity selector SHOULD present the
user with the name of the realm that the identity selector is
attempting to reach, the subject of the trust anchor certificate,
details of the certification chain, and a fingerprint of the
certificate. If the realm does not match the subject of the
certificate, the identity selector MUST inform the user of the
discrepency. The identity selector MAY reject the leap-of-faith on
its own, or MAY allow the user to proceed anyway. If the user
proceeds anyway, the identity selector SHOULD urge the user to reject
the leap-of-faith.
The area of verification of trust anchors is very important. An
Identity Selector that allows for manual addition of identity
provider information SHOULD try to ensure that trust anchor
information is gathered and checked in a secure a manner as possible
- where users have to enter and confirm all trust anchor information,
or be required to explicitly agree to an insecure configuration if
this is not done properly.
6.4.1.2. Manually Triggered Automated Identity Provider Addition
One way to bypass the need for manual addition of an identity
provider - and all of the usability and security issues inherent with
that approach - is to provide some sort of manually triggered, but
automated, addition process. One approach to accomplishing this, for
example, could be for an organisation to have a section on their
website where their users could visit and be given piece of data that
contains much or all of the relevant identity provider information
for importing into the identity selector.
Additionally, the user SHOULD be given the opportunity to:
o Supply or change the default friendly name and friendly icon for
that identity provider - to allow the user to customise the
identifier they use for that identity provider;
o Reject the addition of the identity provider completely - to allow
the user to back out of the association process in an intuitive
way.
In this case, trust anchors would be directly provided through the
automated addition process to help establish the trust relationship
in a secure manner.
6.4.1.3. Fully Automated Identity Provider Addition
Many organisations manage the machines of their users using
enterprise management tools. Such organisations may wish to be able
to automatically add a particular user's identity provider to the
identity selector on their machine/network account so that the user
has to do nothing.
This represents the best usability for the user - who wouldn't
actually have to do anything. However, it can only work on machines
centrally managed by the organisation.
6.4.2. Identity Addition
6.4.2.1. Manual Identity Addition
Allowing users to add an identity manually is relatively easy in
comparison to adding an identity provider manually. If the identity
provider is already known in the identity selector, then the identity
selector can construct the NAI from the identity provider and a
username. Thus the manual addition of an identity in a known realm
needs to prompt the user only to pick the realm, to enter the
username, and to enter the credential. If the identity provider is
not known to the identity selector, the identity selector will
provide the user with a way to define a new one as part of the
identity addition.
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, also have inherent issues this at any time. It does, however, also have inherent issues
when it comes to verifying the newly added identity - see when it comes to verifying the newly added identity - see
Section 6.5. Section 6.6.
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 seems new one, as well as associating with an existing one. This seems
to present 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, it represents a newly added identity (see Section 6.6), however, it represents a
less direct method of adding an identity. Users who have not yet less direct method of adding an identity. Users who have not yet
added the appropriate identity to their identity selector may find added the appropriate identity to their identity selector may find
it difficult to understand that they must try to access a it difficult to understand that they must try to access a
particular 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.
Finally, the area of verification of trust anchors is very important. 6.4.2.2. Manually Triggered Automated Identity Addition
An Identity Selector that allows for manual addition of identity
information SHOULD try to ensure that trust anchor information is
gathered and checked in a secure a manner as possible - where users
have to enter and confirm all trust anchor information, or be
required to explicitly agree to an insecure configuration if this is
not done properly.
6.3.2. Manually Triggered Automated Addition
One way to bypass the need for manual addition of a user's identity -
and all of the usability and security issues inherent with that
approach - is to provide some sort of manually triggered, but
automated, addition process.
One approach to accomplishing this, for example, could be for an Much like in the case of the manually triggered automated identity
organisation to have a section on their website where their users provider addition Section 6.4.1.2, an identity could be added to the
could visit, enter the user part of their NAI, and be given piece of identity selector through a user-initiated mechanism. To follow the
data that contains much or all of the relevant identity information example in the identity provider section above, the organization
for importing into the identity selector. could enhance the identity provider addition web service to prompt
for the user part of the NAI. The web service could then generate
all of the data needed for adding both the identity provider and the
identity.
It is reasonable to assume that any such automated addition service It is reasonable to assume that any such automated addition service
is likely to be organisation specific, so that the Issuing is likely to be organisation specific, so that the Issuing
Organisation and realm part of the NAI will be constant, as would be Organisation and realm part of the NAI will be constant, as would be
the trust anchor information. The user part of their NAI will have the trust anchor information. The user part of their NAI will have
been input on the web service. The password could be provided as a been input on the web service. The password could be provided as a
part of the provided data or the identity selector could prompt the part of the provided data or the identity selector could prompt the
user to enter it. user to enter it.
If the identity provider data contained in this identity to be added
conflicts with an existing identity provider known to the identity
selector, the identity selector SHOULD present the discrepency to the
user. The identity selector MAY reject the identity provider and
identity on its own, or MAY allow the user to proceed anyway. If the
identity selector allows the user to proceed anyway, the identity
selector SHOULD urge the user to reject the leap-of-faith, and
require the user to confirm the intent to proceed before proceeding.
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 6.4.2.3. Fully Automated Identity Addition
automated addition process to help establish the trust relationship
in a secure manner.
6.3.3. Fully Automated Addition
Many organisations manage the machines of their users using Section Section 6.4.1.3 introduced the concept of using enterprise
enterprise management tools. Such organisations may wish to be able management tools to add an identity provider to the identity
to automatically add a particular user's identity to the identity selector. These enterprise management tools could be used to add an
selector on their machine/network account so that the user has to do identity that uses the identity provider added in the above manner.
nothing.
This represents the best usability for the user - who wouldn't The user would not need to decipher difficult to understand data
actually have to do anything. However, it can only work on machines entry screens.
centrally managed by the organisation.
Additionally, having an identity automatically provided, including However, having an identity automatically provided, including its
its password, does have some particular usability issues. Users are password, does have some particular usability issues. Users are used
used to having to provide their username and password to access to having to provide their username and password to access remote
remote services. When attempting to access services, authenticating services. When attempting to access services, authenticating to them
to them completely transparently to the user could represent a source completely transparently to the user could represent a source of
of confusion. User training within an organisation to explain that confusion. User training within an organisation to explain that
automated population 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.5. 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.5.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 items
that SHOULD be allowed to be changed by the user is the password that SHOULD be allowed to be changed by the user are the friendly
associated with the identity. name, the friendly icon, and the credential, or password, associated
with the identity.
6.4.2. Automated Modification The identity selector should restrict other modification of the
information:
o Identity Selectors SHOULD NOT allow the editing of the NAI of an
identity or the trust anchor of an identity provider for items
that have been added through automated means (Section 6.4.1.2,
Section 6.4.1.3, Section 6.4.2.2 and Section 6.4.2.3).
o Identity Selectors MAY allow the update of the trust anchor of
identity providers that have stored the trust anchor through just
in time manual addition, using another just in time retrieval of
the trust anchor. Any identity selector that allows this update
MUST inform the user of the change in the trust anchor, and advise
the user that any unexpected change should be assumed to be an
attack.
o Identity Selectors SHOULD NOT allow manual modification of the
password changing URL.
o Identity Selectors SHOULD NOT allow manual modification of the
helpdesk URL.
6.5.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 provider or identity information. For example,
changes it could automatically update the password for the identity if the user's password changes it could automatically update the
in the user's identity selector, or if the trust anchor information password for the identity in the user's identity selector, or if the
changes (e.g. if a certificate is changed) it could be automatically trust anchor information changes (e.g. if a certificate is changed)
pushed out to all users. it could be automatically pushed out to all users.
6.5. Verifying an identity 6.6. 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.4):
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.4) 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 populated 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 process where the error lies, and the error messages provided by the process
may not be helpful enough to indicate the error and how to fix it may not be helpful enough to indicate the error and how to fix it
(see Section 8). (see Section 8).
6.6. Removing an Identity 6.7. 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.7.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
way to achieve the goal. Any UI should allow for this option. way to achieve the goal. Any UI should allow for this option.
6.6.2. Automated Removal 6.7.2. Automated Removal
While automated removal of an identity is a way of achieving the goal While automated removal of an identity is a way of achieving the goal
without having to interact with the user, the consequence is that without having to interact with the user, the consequence is that
things may disappear from the user's identity selector without them things may disappear from the user's identity selector without them
realising. realising.
6.7. Storing an Identity with or without credentials 6.8. Storing an Identity with or without credentials
Sometimes, a user may wish to have the identity they wish to use with Sometimes, a user may wish to have the identity they wish to use with
a service stored by the identity selector, but not the credential a service stored by the identity selector, but not the credential
(e.g. password) that goes along with that Identity. The consequence (e.g. password) that goes along with that Identity. The consequence
of this is that when a user attempts to authenticate to a service for of this is that when a user attempts to authenticate to a service for
which an identity, but no credential, is stored, then the user would which an identity, but no credential, is stored, then the user would
need to be prompted to manually enter the credential. need to be prompted to manually enter the credential.
7. Considerations around Management of Service to Identity Mappings 7. Considerations around Management of Service to Identity Mappings
skipping to change at page 14, line 5 skipping to change at page 17, line 19
after the identity in question has authenticated with the service after the identity in question has authenticated with the service
without any error. without any error.
There are a few ways this association could happen. There are a few ways this association could happen.
7.1.1. User-driven Manual Association 7.1.1. User-driven Manual Association
There are two ways in which manual association of an identity to a There are two ways in which manual association of an identity to a
service could happen: service could happen:
1. The user could manually associate a particular service with a 1. The identity selector MAY allow the user to associate a
particular identity using the identity selector before they first particular service with a particular identity manually, using the
attempt to use the service. In order to do so, however, the user identity selector before they first attempt to use the service.
would need to know all the required technical details of that This method is inadvisable, however, because not only might the
service beforehand, such as its GSS Acceptor Name. identity in question not yet have authenticated successfully, the
user would also need to know all the required technical details
of that service beforehand, such as its GSS Acceptor Name.
2. On encountering a service new to the identity selector, the 2. On encountering a service new to the identity selector, the
identity selector could pop up a dialogue box to the user asking identity selector SHOULD pop up a dialogue box to the user asking
if they would like to use an existing identity for this service if they would like to use an existing identity for this service
(and might also allow them to create a new identity and use (and might also allow them to create a new identity and use
that). that).
7.1.2. Automated Rules-based Association 7.1.2. Automated Rules-based Association
It would be beneficial from a usability perspective to minimise - or It would be beneficial from a usability perspective to minimise - or
avoid entirely - situations where the user has to pick an identity avoid entirely - situations where the user has to pick an identity
for a particular service. This could be accomplished by having rules for a particular service. This could be accomplished by having rules
to describe services and their mapping to identities. Such a rule to describe services and their mapping to identities. Such a rule
could match, for example, a particular identity for all IMAP servers, could match, for example, a particular identity for all IMAP servers,
or a particular identity for all services in a given service realm. or a particular identity for all services in a given service realm.
These rules could be configured as a part of the automated identity These rules could be configured as a part of the automated identity
addition process described in Section 6.3.2 or Section 6.3.3 addition process described in Section 6.4.2.2 or Section 6.4.2.3.
7.1.3. Association Conflicts
The presence of rules-based associations brings with it potential
conflicts in the rules. A non-exhaustive list of conflicts includes:
o One rule applies to all services of a particular type, while
another rule applies to all services within a particular domain.
For example, one rule applies identity A to all IMAP services,
while another rule applies identity B to all services in the
example.com domain.
o One rule originates from enterprise management tools as described
in Section 6.4.2.3, and another rule originates from manual
addition.
o The user has associated an identity with a service upon
encountering the service for the first time, and later creates a
rule that matches all services within that service's realm.
Identity selectors MUST order the precedence of rules as follows:
1. Manually created rules matching specific services and realms
2. Enterprise created rules matching specific services and realms
3. Manually created rules matching any service in a single realm
4. Enterprise created rules matching any service in a single realm
5. Manually created rules matching a single service in any realm
6. Enterprise created rules matching a single service in any realm
Identity selectors SHOULD notify the user whenever a new rule will
take precedence over an existing rule.
7.2. Disassociating a Service with an Identity 7.2. Disassociating a Service with an Identity
A user MUST be able to disassociate an identity with a service - that A user MUST be able to disassociate an identity with a service - that
is, to be able to remove the mapping without having to remove the is, to be able to remove the mapping without having to remove the
identity. identity.
There should also be provision for the automated disassociation of an For serious authentication errors, the identity selector SHOULD
identity with a service for appropriate types of authentication prompt the user to choose whether to disassociate the identity from
failures. the service or retain the association. The prompt SHOULD explain the
nature of the error.
When such a serious authentication error occurs and the identity is
selected by a rules-based association (Section 7.1.2), any
disassociation prompt MUST inform the user that the identity was
selected by a rule. The prompt SHOULD allow the user to retain the
association, or to disassociate the rule altogether. The prompt MAY
include a third choice, to create an exception so that the rule does
not apply to this specific service.
As of this writing, there are no authentication failures that should
cause the disassociation of an identity from a service.
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 indication given to the user as to which time, there should be some indication given to the user as to which
skipping to change at page 15, line 13 skipping to change at page 19, line 32
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 they are currently in use could be made visible to the user while they are
using a specific service. This allows the user to identify which 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.
This is especially useful when the identity is selected without any
user prompt, because of a previous association.
Implementing such a feature may be hard, however, due to the layered Implementing such a feature may be hard, however, due to the layered
nature of the ABFAB transaction - the identity selector will nature of the ABFAB transaction - the identity selector will
certainly know when successful (or failed) authentications to a certainly know when successful (or failed) authentications to a
particular service have happened, but after that it typically plays particular service have happened, but after that it typically plays
no further part in the use of the service. Therefore, knowing that a no further part in the use of the service. Therefore, knowing that a
particular service is still using a particular identity in order to particular service is still using a particular identity in order to
indicate this to the user would be challenging. indicate this to the user would be challenging.
One approach that could be used would be to display OS notifications
when an identity is used. The notification could include information
such as the application requesting the identity, the service
receiving the identity, and the identity used. Another approach
could be for the identity selector to maintain a history of identity
use.
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 16, line 28 skipping to change at page 21, line 11
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 Identity might have been successfully authenticated by the
IdP, but the user might not have authorisation to use the service IdP, but the user might not have authorisation to use the service
they are attempting to use. or privilege levels within the service they are attempting to use.
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 17, line 36 skipping to change at page 22, line 18
to include functionality that allows for the export/import of to include functionality that allows for the export/import of
identities and service to identity mappings. This could be for identities and service to identity mappings. This could be for
backup purposes, to allow a degree of mobility between identity backup purposes, to allow a degree of mobility between identity
selector instances, etc. selector instances, etc.
If providing this functionality, it would be advisable that the If providing this functionality, it would be advisable that the
credential store that is the result of the export should be secure - credential store that is the result of the export should be secure -
encrypted and password protected - given the nature of the encrypted and password protected - given the nature of the
information. information.
11. Contributors 11. Security Considerations
The following individuals made important contributions to the text of
this document: Sam Hartman (Painless Security LLC), and Maria Turk
(Codethink Ltd).
12. Acknowledgements
Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman,
Mark Donally, and Dave Crocker, for feedback and suggestions.
13. Security Considerations
Most security considerations are ones relevant to the use of GSS-EAP 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 and are detailed in [I-D.ietf-abfab-arch]. There are, however, a few
specific sets of security considerations related to the UI specific sets of security considerations related to the UI
implementation. implementation.
First, as discussed earlier, the Identity Selector should use a Trust First, as discussed earlier, the Identity Selector should use a Trust
Anchor to authenticate the IdP before it sends the users credentials Anchor to authenticate the IdP before it sends the users credentials
to it. Having no Trust Anchor information at all, or an incorrect to it. Having no Trust Anchor information at all, or an incorrect
Trust Anchor, can enable the possibility of someone spoofing the IdP Trust Anchor, can enable the possibility of someone spoofing the IdP
skipping to change at page 18, line 36 skipping to change at page 23, line 8
user. user.
o A pragmatic approach would be leap of faith, whereby no Trust o A pragmatic approach would be leap of faith, whereby no Trust
Anchor information is initially provisioned, and the first time Anchor information is initially provisioned, and the first time
the Identity Selector connects to the IdP it remembers the Trust the Identity Selector connects to the IdP it remembers the Trust
Anchor information for future use. This doesn't mitigate against Anchor information for future use. This doesn't mitigate against
spoofing of an IdP in the first instance, but would enable spoofing of an IdP in the first instance, but would enable
mitigation against it for all future connections. mitigation against it for all future connections.
o Finally, there may be interesting ways to leverage technologies o Finally, there may be interesting ways to leverage technologies
such as DANE to store the Trust Anchor for an IdP in DNS. such as DANE [RFC6698] to store the Trust Anchor for an IdP in
DNS.
Secondly, the storage of the user's credentials by the Identity Secondly, the storage of the user's credentials by the Identity
Selector should be done in a secure manner to mitigate against people Selector should be done in a secure manner to mitigate against people
taking unauthorised control of the device being able to gather these taking unauthorised control of the device being able to gather these
credentials. Use of a secure credential storage mechanism, such as credentials. Use of a secure credential storage mechanism, such as
the GNOME Keyring on Linux, or Keychain on the Mac, are recommended. the GNOME Keyring on Linux, or Keychain on the Mac, are recommended.
14. IANA Considerations 12. Privacy Considerations
Since the ABFAB system facilitates the sharing of identifying
information about a user, the undesired sharing of information is a
real concern. Most of the privacy considerations lie outside the
scope of the Identity Selector UI, which neither controls nor sees
which attributes of an identity will be shared with a service. In
essence, the only control that the Identity Selector has is whether
or not a given identity will be shared with the service.
However, the selection of identity does warrant privacy
considerations. Any automated choice of identity for a service will
share information, potentially inappropriately. Examples of this
include:
o Rules that apply to a service across all realms will cause an
identity choice, even for realms the user would actually prefer to
avoid interacting with at all.
o Storing a default for a particular service and realm will cause
the identity to be selected in that situation going forward, even
if the situation or application does not warrant that. For
instance, a web browser in privacy mode ideally should not know of
any saved identity association choices.
Even appropriate choices of sharing an identity with a service leaks
information about the user. The desired service and the identity
provider must communicate with each other to perform an
authentication. Even if the authentication fails, the service will
know the realm of the user credential, and the Identity Provider will
know the realm, and maybe the service, that the user tried to access.
For services with fallback authentication mechanisms, the system may
try and fail to authenticate the user, thus sharing the realm
information noted above, without the user being aware this has
happened.
13. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
15. Normative References 14. Contributors
[RFC2119] Bradner, S., "Key words for use in RFCs to The following individuals made important contributions to the text of
Indicate Requirement Levels", BCP 14, this document: Sam Hartman (Painless Security LLC), and Maria Turk
RFC 2119, March 1997. (Codethink Ltd).
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 15. Acknowledgements
Eronen, "The Network Access Identifier",
RFC 4282, December 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman,
Boeyen, S., Housley, R., and W. Polk, Alejandro Perez-Mendez, Ken Klingenstein, and Dave Crocker for
"Internet X.509 Public Key Infrastructure feedback and suggestions.
Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofenig, H., 16. References
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 16.1. Normative References
Federated Access Beyond web (ABFAB) Use
Cases", draft-ietf-abfab-usecases-05 (work [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
in progress), September 2012. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, DOI 10.17487/
RFC4282, December 2005,
<http://www.rfc-editor.org/info/rfc4282>.
[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, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[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.
16.2. Informative References
[MS-CS] Brown, K., "The InfoCard Identity Revolution", July 2006,
<https://technet.microsoft.com/en-us/
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 -02 to ietf draft -03
1. Tidying up language throughout.
2. Added the idea of an identity provider object within the identity
selector, and moved the trust anchor property from the identity
to the identity provider.
3. Added restrictions on manual modification of automatically added
identities and identity providers.
4. Added precedence between identity association rules.
5. Incorporated many comments from the mailing list.
6. Added privacy considerations section.
IETF draft -01 to ietf draft -02 IETF draft -01 to ietf draft -02
1. Tidying up language throughout. 1. Tidying up language throughout.
2. Finished remaining TODOs - largely in the error handling section. 2. Finished remaining TODOs - largely in the error handling section.
3. Added security considerations section. 3. Added security considerations section.
IETF draft -00 to ietf draft -01 IETF draft -00 to ietf draft -01
skipping to change at page 21, line 5 skipping to change at page 27, line 46
Draft -00 to draft -01 Draft -00 to draft -01
1. None, republishing to refresh the document. Other than adding 1. None, republishing to refresh the document. Other than adding
this comment... this comment...
Appendix B. Open Issues Appendix B. Open Issues
Note to RFC Editor: please remove this appendix before publication as Note to RFC Editor: please remove this appendix before publication as
an RFC. an RFC.
Author's Address Authors' Addresses
Dr. Rhys Smith Dr. Rhys Smith
Cardiff University Cardiff University
39-41 Park Place 39-41 Park Place
Cardiff CF10 3BB Cardiff CF10 3BB
United Kingdom United Kingdom
Phone: +44 29 2087 0126 Phone: +44 29 2087 0126
EMail: smith@cardiff.ac.uk EMail: smith@cardiff.ac.uk
Mark Donnelly
Painless Security
14 Summer Street
Suite 202
Malden, Massachusetts 02176
United States
EMail: mark@painless-security.com
 End of changes. 66 change blocks. 
211 lines changed or deleted 520 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/