idnits 2.17.1 draft-ietf-abfab-usability-ui-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB R. Smith 3 Internet-Draft Cardiff University 4 Intended status: Informational July 6, 2015 5 Expires: January 7, 2016 7 Application Bridging for Federated Access Beyond web (ABFAB) Usability 8 and User Interface Considerations 9 draft-ietf-abfab-usability-ui-considerations-02 11 Abstract 13 The real world use of ABFAB-based technologies requires that any 14 identity that is to be used for authentication has to be configured 15 on the ABFAB-enabled client device. Achieving this requires software 16 on that device (either built into the operating system or a 17 standalone utility) that will interact with the user, managing their 18 identity information and identity-to-service mappings. All designers 19 of software to fulfil this role will face the same set of challenges. 20 This document aims to document these challenges with the aim of 21 producing well-thought out UIs with some degree of consistency 22 between implementations. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 7, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Considerations around Terminology . . . . . . . . . . . . . . 6 63 5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 7 66 6. Considerations around Management of Identities . . . . . . . . 7 67 6.1. Information associated with each Identity . . . . . . . . 7 68 6.2. Storage of Identity Information . . . . . . . . . . . . . 8 69 6.3. Adding/Association of an Identity . . . . . . . . . . . . 8 70 6.3.1. Manual Addition . . . . . . . . . . . . . . . . . . . 9 71 6.3.2. Manually Triggered Automated Addition . . . . . . . . 10 72 6.3.3. Fully Automated Addition . . . . . . . . . . . . . . . 11 73 6.4. Modifying Identity Information . . . . . . . . . . . . . . 11 74 6.4.1. Manual Modification . . . . . . . . . . . . . . . . . 11 75 6.4.2. Automated Modification . . . . . . . . . . . . . . . . 11 76 6.5. Verifying an identity . . . . . . . . . . . . . . . . . . 12 77 6.6. Removing an Identity . . . . . . . . . . . . . . . . . . . 12 78 6.6.1. Manual Removal . . . . . . . . . . . . . . . . . . . . 12 79 6.6.2. Automated Removal . . . . . . . . . . . . . . . . . . 12 80 6.7. Storing an Identity with or without credentials . . . . . 12 81 7. Considerations around Management of Service to Identity 82 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.1. Associating a Service with an Identity . . . . . . . . . . 13 84 7.1.1. User-driven Manual Association . . . . . . . . . . . . 13 85 7.1.2. Automated Rules-based Association . . . . . . . . . . 14 86 7.2. Disassociating a Service with an Identity . . . . . . . . 14 87 7.3. Listing Services and Identities . . . . . . . . . . . . . 14 88 7.4. Showing the Service that is requesting Authentication . . 14 89 7.5. Showing the Identity currently in use . . . . . . . . . . 15 90 7.6. Multiple Identities for a Particular Service . . . . . . . 15 91 7.7. Not using ABFAB for a Particular Service . . . . . . . . . 15 92 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . . 15 93 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 16 94 9.1. Reporting Authentication Success on First Use of 95 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 9.2. Reporting Authentication Success . . . . . . . . . . . . . 17 98 10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 10.1. Identity Selector Taking Focus . . . . . . . . . . . . . . 17 100 10.2. Import/Export of Credentials . . . . . . . . . . . . . . . 17 101 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 103 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 104 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 105 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 107 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 109 1. Introduction 111 The use of ABFAB-based technologies requires that any identity that 112 is to be used for authentication has to be configured on the client 113 device. Achieving this requires software on that device (either 114 built into the operating system or a standalone utility) that will 115 interact with the user, and manage the user's identities and 116 credential-to-service mappings. Anyone designing that software will 117 face the same set of challenges. 119 This document does not intend to supplant evidence-based UI design 120 guidelines; implementers of identity selectors are strongly 121 encouraged to understand the latest in HCI and UX thought and 122 practice. Instead, it aims to document the common challenges faced 123 by implementers with the aim of providing a common starting point for 124 implementers in the hope that this aids in producing well-thought out 125 UIs with some degree of consistency. 127 2. Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Terminology 135 Various items of terminology used in the document are heavily 136 overloaded in that they mean a variety of different things to 137 different people. In an attempt to minimise this problem, this 138 section gives a brief description of the main items of terminology 139 used in order to aid a consistent understanding of this document. 141 o NAI: Network Access Identifier - a standard way of identifying a 142 user and assisting in the routing of an authentication request 143 (see [RFC4282]). 145 o Identity: In this context, an identity is a credential given to a 146 user by a particular organisation with which they have an 147 association. A user may have multiple identities - potentially 148 multiple identities per organisation, and also across multiple 149 organisations. Each identity will consist of an NAI, alongside 150 other information that supports authentication. Note that in 151 other contexts the usual use of "identity" would match our use of 152 "user", whereas the usual use of "identifier" matches our use of 153 identity. 155 o Service: The thing that the user is attempting to authenticate to 156 via ABFAB technology. See [I-D.ietf-abfab-usecases] for some 157 example ABFAB use cases. Also known as the Relying Party. 159 o Identity Selector: A piece of software that enables the process by 160 which the GSS-API acquires the identity to use with a particular 161 service. An Identity Selector typically would allow the user to 162 configure a set of identities along with service to identity 163 mappings. 165 o Trust anchor: An authoritative source of verification of a 166 particular ABFAB service or Identity Provider, used to allow 167 authentication of a server using X.509 [RFC5280]. Typically a 168 commercial CA to allow authentication via chain of trust, or a 169 preconfigured non-commercial certificate (e.g. self-signed). 171 4. Context 173 When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to 174 perform federated authentication to some service, a user will need to 175 provide identity information that they wish to use to authenticate to 176 that particular service. This will happen through a process of the 177 application calling the GSS-API, which will in turn gather the user's 178 credentials through some process. We will call this process the 179 "identity selector" in this document (though note that this is not a 180 recommendation on terminology for the process). 182 The simplest way to achieve the desired effect would be a process 183 that simply takes the credentials from the currently logged in user 184 (e.g. the Windows Domain Credentials) and uses those for all services 185 that request authenticate through ABFAB. This approach gives 186 ultimate simplicity in terms of UI (it wouldn't have one) but the 187 least flexibility (the user has to use a single identity for 188 everything). If there is ever to be a requirement for a user to use 189 a different set of credentials for a service, then something more 190 complex will be needed. 192 Where there is a requirement for multiple credentials to be 193 supported, there are at least two methods that could be employed to 194 configure identities and associated information: 196 o They could be configured manually by the user in a configuration 197 file that could be edited by hand or some such simple process, and 198 read by the GSS-API mechanism. While this could work very well 199 functionally, in practice only a small subset of users would be 200 happy with - and able to - configure their identities in such a 201 manner. 203 o They could be configured through some interactive process. For 204 ease of use this should have a simple UI, although to support some 205 use cases a headless mode (i.e. a way of interacting with the 206 identity selector when there is no GUI present) may need to be 207 supported. 209 When designing an identity selector with a UI (or indeed, with a 210 headless mode), any implementer will share a common set of usability 211 considerations inherent to the context. This document aims to 212 explore these considerations, and provide advice and guidance on 213 addressing them where possible. 215 5. Considerations around Terminology 217 Anyone designing an identity selector will have to grapple with 218 choosing terminology that the average user has some chance of 219 understanding. This terminology can split into a few main functional 220 areas, as discussed next. 222 5.1. Identity 224 The first area where terminology is needed is around the identity/ 225 identities of the user. Users are typically used to seeing a variety 226 of terms for aspects of their identity in the federated sense, and an 227 even larger variety in the wider internet sense. For example, in the 228 federated sense some of these terms include "username", "login", 229 "network account", "institutional account", "home organisation 230 account", "credentials", and a myriad of other such terms. However, 231 NAI - the technically correct name for their identity in an ABFAB 232 sense - is highly unlikely to be one of these terms that users are 233 used to seeing. Further, given that the NAI superficially looks like 234 an email address, there is a definite potential for confusion. 236 Implementers of an identity selector will need to carefully consider 237 their intended audience for both their level of technical capability 238 and the existing terminology that they may have been exposed to. 240 Beyond terminology, careful thought needs to be given to the paradigm 241 to use when presenting identity to users, as identities and services 242 are abstract concepts that some users may not find is easily 243 understandable. Implementers may wish to keep such abstract 244 concepts, or may wish to examine attempts to map to real world 245 paradigms, e.g. the idea of using "Identity Cards" that are held in 246 the user's "Wallet", as used by Microsoft Cardspace. 248 5.2. Services 250 Terminology around services is likely to be less of a problem than 251 identity, but it will actually depend on what the service is. For 252 example, each service could be simply described as "server", 253 "system", etc. But for simplicity just the word "service" will 254 probably usually suffice. 256 5.3. Identity to Service Mapping 258 Depending on your perspective either each identity may be mapped to 259 multiple services, or each service has multiple identities mapped to 260 it. Thus any UI could present either perspective, or both. 262 6. Considerations around Management of Identities 264 One of the core features of an identity selector is the management of 265 a user's identities. This section first looks at what information 266 associated with an identity will need to managed, and then looks in 267 detail at various usability considerations of this area. 269 6.1. Information associated with each Identity 271 The bare minimum set of information that MUST be stored about each 272 identity to allow ABFAB authentication to take place is a single 273 item: 275 o NAI: The user's Network Access Identifier (see [RFC4282]) for this 276 particular credential. For example, "joe@example.com". Note that 277 the identity selector MUST NOT store different identities that use 278 the same NAI. This is required as the NAI is the unique key that 279 is used by the identity selector when interacting with the GSS-API 280 mechanism for various reasons, for example, to allow the GSS-API 281 mechanism to report back error or success statuses. 283 Next up is a small set of information that SHOULD be stored about 284 each identity to allow the user to effectively select a particular 285 identity: 287 o Trust anchor: For the identity selector to be able to verify that 288 the server it is going to talk to and attempt to authenticate 289 against is the server that it is expecting, and that it is not 290 being spoofed in some way. This is likely to be an X.509 291 certificate [RFC5280], or a tuple of (trusted root certificate, 292 servername in Subject or subjectAltName). Storing a credential 293 without a relevant trust anchor allows for the possibility of a 294 malicious attacker intercepting traffic and masquerading as the 295 server in question. 297 o Credential: Whatever is used by the user to authenticate 298 themselves with a particular NAI. What exactly this will be will 299 be dependent on the EAP method being used, but is likely to be 300 something like a password or a certificate. Note that this is a 301 SHOULD, rather than a MUST, because there are use cases where a 302 user may specifically opt for this not to be "remembered". 304 Finally, there is a set of optional information that MAY be stored 305 about each identity that represent useful information for the user to 306 have and could make an identity selector more usable. Note that this 307 list is neither intended to be exhaustive or even particularly 308 correct; any implementer is free to use whatever make sense in their 309 implementation and conforms to good HCI/UX guidelines. Instead, it 310 is simply a suggested starting point. 312 o Friendly name for identity: To allow the user to differentiate 313 between the set of identities represented in the Identity 314 Selector. This should be editable by the user. The only 315 restriction on this name is that it MUST be unique within that 316 particular user's set of identities. For example: "My 317 University", "Google Account", "Work Login", etc. 319 o Friendly icon for identity: To allow the user to differentiate 320 between the set of identities they have they should be able to set 321 an icon for that particular identity. 323 o Password changing URL: The URL the user should visit should they 324 need to change their password for this particular identity. For 325 example, "http://www.example.com/passwordreset". 327 o Helpdesk URL: The URL the user should visit to get contact details 328 for the helpdesk of the organisation that issued this particular 329 identity for when the user encounters issues and needs help. For 330 example, https://www.example.com/helpdesk. 332 6.2. Storage of Identity Information 334 Since some of the information that makes up the identity is sensitive 335 in nature (e.g. containing passwords), then this information SHOULD 336 be stored and accessed securely. This might involve ensuring the 337 credential information is held in encrypted form on device and 338 accessed using a passphrase. For deeper integration into the system, 339 this could be done by using existing secure storage on the system 340 such as Keychain on a Mac or the GNOME keyring on a GNOME based Linux 341 device. 343 6.3. Adding/Association of an Identity 345 Users will have one or more identities given to them by organisations 346 that they have a relationship with. One of the core tasks of an 347 identity selector will be to learn about these identities in order to 348 use them when it comes to authenticating to services on behalf of the 349 user. Adding these identities could be done in one of three ways: 350 manual addition, automated addition that is manually triggered, or 351 automated addition that is automatically triggered. Each of these 352 are discussed in more detail next. 354 Note that the term "association" or "addition" of an identity is used 355 rather than "provisioning" of an identity, because while we actually 356 are provisioning identities into the UI, provisioning is an 357 overloaded term in the identity and access management space and could 358 easily be confused with identity provisioning in the sense of the 359 creation of the identity by the home organisation's identity 360 management procedures. 362 6.3.1. Manual Addition 364 Allowing users to manually add an identity is technically the easiest 365 method to get this information, but it is a method that has the 366 greatest usability drawbacks - including some that create potential 367 security issues. Most of the information required is relatively 368 technical and finding some way of explaining what each field is to an 369 non-technical audience is challenging (to say the least). This 370 especially is the case for trust anchor information. Thus this 371 method should be considered as a power-user option only, or as a 372 fall-back should the other methods not be applicable. Implementers 373 may well decide not to offer the manual option due to these 374 drawbacks. 376 When this method is used, careful consideration should be given to 377 the UI presented to the user. The UI will have to ask for all of the 378 information detailed in Section 6.1. 380 There are two points at which a user could manually add an identity: 382 o Asynchronously: the user could be allowed to, at any time, trigger 383 a workflow of manually adding an identity. This represents the 384 most flexible way of adding an identity since a user can perform 385 this at any time. It does, however, also have inherent issues 386 when it comes to verifying the newly added identity - see 387 Section 6.5. 389 o Just In Time: when connecting to a service which has no mapping to 390 an existing identity, the user could be given an option to add a 391 new one, as well as associating with an existing one. This seems 392 to present a better user experience when it comes to verifying the 393 newly added identity (see Section 6.5), however, it represents a 394 less direct method of adding an identity. Users who have not yet 395 added the appropriate identity to their identity selector may find 396 it difficult to understand that they must try to access a 397 particular service in order to add an identity. 399 Of course, implementers could support both styles of identity 400 addition to gain the benefits of both and give flexibility to the 401 user. 403 Finally, the area of verification of trust anchors is very important. 404 An Identity Selector that allows for manual addition of identity 405 information SHOULD try to ensure that trust anchor information is 406 gathered and checked in a secure a manner as possible - where users 407 have to enter and confirm all trust anchor information, or be 408 required to explicitly agree to an insecure configuration if this is 409 not done properly. 411 6.3.2. Manually Triggered Automated Addition 413 One way to bypass the need for manual addition of a user's identity - 414 and all of the usability and security issues inherent with that 415 approach - is to provide some sort of manually triggered, but 416 automated, addition process. 418 One approach to accomplishing this, for example, could be for an 419 organisation to have a section on their website where their users 420 could visit, enter the user part of their NAI, and be given piece of 421 data that contains much or all of the relevant identity information 422 for importing into the identity selector. 424 It is reasonable to assume that any such automated addition service 425 is likely to be organisation specific, so that the Issuing 426 Organisation and realm part of the NAI will be constant, as would be 427 the trust anchor information. The user part of their NAI will have 428 been input on the web service. The password could be provided as a 429 part of the provided data or the identity selector could prompt the 430 user to enter it. 432 Additionally, the user SHOULD be given the opportunity to: 434 o Supply or change the default friendly name for that identity - to 435 allow the user to customise the identifier they use for that 436 identity; 438 o Indicate whether or not the identity selector should always ask 439 before using services with this identity - to customise the way in 440 which the identity selector interacts with the user with this 441 particular identity; 443 o Reject the addition of the identity completely - to allow the user 444 to back out of the association process in an intuitive way. 446 In this case, trust anchors could be directly provided through the 447 automated addition process to help establish the trust relationship 448 in a secure manner. 450 6.3.3. Fully Automated Addition 452 Many organisations manage the machines of their users using 453 enterprise management tools. Such organisations may wish to be able 454 to automatically add a particular user's identity to the identity 455 selector on their machine/network account so that the user has to do 456 nothing. 458 This represents the best usability for the user - who wouldn't 459 actually have to do anything. However, it can only work on machines 460 centrally managed by the organisation. 462 Additionally, having an identity automatically provided, including 463 its password, does have some particular usability issues. Users are 464 used to having to provide their username and password to access 465 remote services. When attempting to access services, authenticating 466 to them completely transparently to the user could represent a source 467 of confusion. User training within an organisation to explain that 468 automated population of their identity has been enabled is the only 469 way to counter this. 471 6.4. Modifying Identity Information 473 This process is conceptually fairly similar to adding an identity, 474 and thus shares many of the usability issues with that process. Some 475 particular things are discussed here. 477 6.4.1. Manual Modification 479 An identity selector may allow a user to manually modify some or all 480 of the information associated with each identity. The obvious item 481 that SHOULD be allowed to be changed by the user is the password 482 associated with the identity. 484 6.4.2. Automated Modification 486 To ease usability, organisations may wish to automatically provide 487 updates to identity information. For example, if the user's password 488 changes it could automatically update the password for the identity 489 in the user's identity selector, or if the trust anchor information 490 changes (e.g. if a certificate is changed) it could be automatically 491 pushed out to all users. 493 6.5. Verifying an identity 495 An inherent by-product of the ABFAB architecture is that an identity 496 cannot be verified during the addition process; it can only be 497 verified while it is in use with a real service. This represents a 498 definite usability issue no matter which method of identity addition 499 is used (see Section 6.3): 501 o If the user has manually added the identity (see Section 6.3) they 502 may have gone through the whole manual process with no errors and 503 so believe the identity has been set up correctly. However, when 504 they attempt to access a service, they may be given an error 505 message, thus causing some amount of confusion. 507 o If the user has had the identity populated into their identity 508 selector, then there is a much greater chance of the identity 509 information being correct. However, if any of the information is 510 not correct, then there is the potential for confusion as the user 511 did not add the information in the first place. 513 Also, if the identity information is incorrect the user may not know 514 where the error lies, and the error messages provided by the process 515 may not be helpful enough to indicate the error and how to fix it 516 (see Section 8). 518 6.6. Removing an Identity 520 This is fairly similar to adding or modifying an identity, and thus 521 shares many of the usability issues with those processes. Some 522 particular things are discussed here. 524 6.6.1. Manual Removal 526 Allowing the user to manually delete an identity is probably the best 527 way to achieve the goal. Any UI should allow for this option. 529 6.6.2. Automated Removal 531 While automated removal of an identity is a way of achieving the goal 532 without having to interact with the user, the consequence is that 533 things may disappear from the user's identity selector without them 534 realising. 536 6.7. Storing an Identity with or without credentials 538 Sometimes, a user may wish to have the identity they wish to use with 539 a service stored by the identity selector, but not the credential 540 (e.g. password) that goes along with that Identity. The consequence 541 of this is that when a user attempts to authenticate to a service for 542 which an identity, but no credential, is stored, then the user would 543 need to be prompted to manually enter the credential. 545 7. Considerations around Management of Service to Identity Mappings 547 A service to identity mapping tells the identity selector which 548 identity should be used for a particular service. There is 549 potentially a many-to-many association between identities and 550 services since a user may wish to use one of their identities for 551 many services, or more than one identity for a single service (e.g. 552 if they have multiple roles on that service). 554 This potentially complex many-to-many association between identities 555 and services is not easily comprehended by the user, and allowing the 556 user to both manipulate it and control can be challenging. These 557 obstacles are especially common when errors occur after an 558 association has been made. In this scenario it is important that an 559 identity can be disassociated with a service. 561 To further complicate the picture, users may wish for: 563 1. The identity to service mapping to be stored along with the 564 credential, i.e. the user should always be authenticated to a 565 particular service with a particular identity with no prompting. 567 2. The identity to service mapping to be stored but not the 568 credential, i.e. the user should not be prompted to choose the 569 identity for a particular service, but should be prompted to 570 enter their credential for that identity. 572 3. The identity to service mapping to not be stored, i.e. the user 573 should be asked which identity to use every time they 574 authenticate to a particular service. 576 7.1. Associating a Service with an Identity 578 There needs to be a way for the user to create the service to 579 identity association. It is advisable that this link be made only 580 after the identity in question has authenticated with the service 581 without any error. 583 There are a few ways this association could happen. 585 7.1.1. User-driven Manual Association 587 There are two ways in which manual association of an identity to a 588 service could happen: 590 1. The user could manually associate a particular service with a 591 particular identity using the identity selector before they first 592 attempt to use the service. In order to do so, however, the user 593 would need to know all the required technical details of that 594 service beforehand, such as its GSS Acceptor Name. 596 2. On encountering a service new to the identity selector, the 597 identity selector could pop up a dialogue box to the user asking 598 if they would like to use an existing identity for this service 599 (and might also allow them to create a new identity and use 600 that). 602 7.1.2. Automated Rules-based Association 604 It would be beneficial from a usability perspective to minimise - or 605 avoid entirely - situations where the user has to pick an identity 606 for a particular service. This could be accomplished by having rules 607 to describe services and their mapping to identities. Such a rule 608 could match, for example, a particular identity for all IMAP servers, 609 or a particular identity for all services in a given service realm. 610 These rules could be configured as a part of the automated identity 611 addition process described in Section 6.3.2 or Section 6.3.3 613 7.2. Disassociating a Service with an Identity 615 A user MUST be able to disassociate an identity with a service - that 616 is, to be able to remove the mapping without having to remove the 617 identity. 619 There should also be provision for the automated disassociation of an 620 identity with a service for appropriate types of authentication 621 failures. 623 7.3. Listing Services and Identities 625 A service listing should be considered in the identity selector which 626 is both searchable and editable by the user. 628 7.4. Showing the Service that is requesting Authentication 630 When a user is attempting to authenticate to a service for the first 631 time, there should be some indication given to the user as to which 632 service is requesting authentication. In many cases, the service may 633 be obvious (where the user has started the process of attempting to 634 authenticate to a particular service), but in other cases this may 635 not be obvious (e.g. if an authentication attempt is triggered by a 636 timer or a specific event), and for this scenario some indication as 637 to the requesting service is necessary. 639 7.5. Showing the Identity currently in use 641 It would be beneficial if, when using a service, the identity 642 currently in use could be made visible to the user while they are 643 using a specific service. This allows the user to identify which 644 identity is used with a particular service at a particular time (the 645 user may have more than one identity that they could use with a 646 particular service) - so that they can then disassociate the pairing. 648 Implementing such a feature may be hard, however, due to the layered 649 nature of the ABFAB transaction - the identity selector will 650 certainly know when successful (or failed) authentications to a 651 particular service have happened, but after that it typically plays 652 no further part in the use of the service. Therefore, knowing that a 653 particular service is still using a particular identity in order to 654 indicate this to the user would be challenging. 656 7.6. Multiple Identities for a Particular Service 658 An Identity Selector should be able to deal with the case where a 659 user has multiple identities associated with a single service. For 660 example, upon receiving a request for authentication to a service 661 that multiple identities are configured for, ask the user which of 662 the identities should be used in this instance. 664 7.7. Not using ABFAB for a Particular Service 666 There may be cases where a user does not wish to use ABFAB based 667 authentication at all to a particular service, even though it is 668 ABFAB enabled. To support this, the identity selector would have to 669 allow the user to choose not to use ABFAB when they attempt to 670 authenticate to a service. It would be desirable if the user could 671 also flag that this should be remembered. 673 8. Handling of Errors 675 Errors during the ABFAB authentication process can happen at any of 676 the many layers - they could be GSS-API errors, EAP errors, RADIUS/ 677 RadSec errors, SAML errors, application errors, etc. ABFAB based 678 technologies are limited in error handling by the limitations in the 679 protocols used. 681 For example, all GSS-API calls are necessarily instantiated from 682 within the calling application. For this reason, when an error 683 occurs the error is passed back to the application in order for it to 684 deal with it. To retry, the application needs to re-initiate the 685 GSS-API call. Unless the application has been written to deal with 686 this properly, this process can be very tedious for a user and cause 687 them opt out of what they are trying to accomplish. In addition to 688 this, the error messages themselves may not be useful enough for the 689 user to decipher what has gone wrong. 691 Absent an improvement to the error handling of these protocols, 692 implementors of an ABFAB Identity Selector will need to work around 693 these limitations. Possible error conditions need to be considered, 694 and decisions about what errors should be presented to the user, and 695 how, need to be made. 697 To give an idea of the range of errors that might be seen, consider 698 the following non-exhaustive set of potential errors. 700 Identity Association/Verification Errors: 702 o The credentials presented to the IdP were not able to be verified 703 - e.g. wrong username/password. 705 o The Trust Anchor for the IdP was invalid. 707 Service Errors: 709 o The Identity might have been successfully authenticated by the 710 IdP, but the user might not have authorisation to use the service 711 they are attempting to use. 713 Other Errors: 715 o The IdP didn't respond to the Service. 717 o The IdP didn't respond to the Client. 719 o Network errors. 721 o Timing errors. 723 9. Handling of Successes 725 It is of course hoped that the identity selector will have to 726 occasionally handle successes as well as errors. This section has 727 some brief discussion about some areas you might want to think about. 729 9.1. Reporting Authentication Success on First Use of Identity 731 The first time an identity is used with a service, it would be good 732 practice to visually indicate in some way that the process has been 733 successful, in order that the user understands what is happening and 734 is then prepared for future authentication attempts. 736 9.2. Reporting Authentication Success 738 On an on-going basis you may or may not wish to indicate visually to 739 the user a successful authentication to a service. This relates to 740 Section 7.5. 742 10. Other Considerations 744 This section briefly discusses other considerations that you might 745 want to think about that don't fit in any of the other categories. 747 10.1. Identity Selector Taking Focus 749 When an ABFAB authentication request is triggered, and where it needs 750 input from the user, the Identity Selector should take focus in some 751 way so that it is clear to the user that they need to do something to 752 proceed. 754 10.2. Import/Export of Credentials 756 For various reasons, an identity selector implementation might want 757 to include functionality that allows for the export/import of 758 identities and service to identity mappings. This could be for 759 backup purposes, to allow a degree of mobility between identity 760 selector instances, etc. 762 If providing this functionality, it would be advisable that the 763 credential store that is the result of the export should be secure - 764 encrypted and password protected - given the nature of the 765 information. 767 11. Contributors 769 The following individuals made important contributions to the text of 770 this document: Sam Hartman (Painless Security LLC), and Maria Turk 771 (Codethink Ltd). 773 12. Acknowledgements 775 Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, 776 Mark Donally, and Dave Crocker, for feedback and suggestions. 778 13. Security Considerations 780 Most security considerations are ones relevant to the use of GSS-EAP 781 and are detailed in [I-D.ietf-abfab-arch]. There are, however, a few 782 specific sets of security considerations related to the UI 783 implementation. 785 First, as discussed earlier, the Identity Selector should use a Trust 786 Anchor to authenticate the IdP before it sends the users credentials 787 to it. Having no Trust Anchor information at all, or an incorrect 788 Trust Anchor, can enable the possibility of someone spoofing the IdP 789 and harvesting credentials sent to it. So, how this Trust Anchor is 790 configured and managed can have major security implications: 792 o The most secure way for a Trust Anchor to be configured is to have 793 it provisioned alongside the other identity information in an 794 enterprise provisioning scenario. This allows for the correct 795 Trust Anchor to be configured with no user input required. 796 However, thought needs to be given to Trust Anchor expiry and 797 consequent requirement for regular reprovisioning of identity 798 information. 800 o Another way that is potentially secure would be to allow the user 801 to discover the Trust Anchor information out of band and manually 802 input this information into the Identity Selector. This is only 803 secure, however, for those users who understand what they're doing 804 in this scenario; pragmatically, this is unlikely to be the case 805 for many users so is not a recommended approach for the average 806 user. 808 o A pragmatic approach would be leap of faith, whereby no Trust 809 Anchor information is initially provisioned, and the first time 810 the Identity Selector connects to the IdP it remembers the Trust 811 Anchor information for future use. This doesn't mitigate against 812 spoofing of an IdP in the first instance, but would enable 813 mitigation against it for all future connections. 815 o Finally, there may be interesting ways to leverage technologies 816 such as DANE to store the Trust Anchor for an IdP in DNS. 818 Secondly, the storage of the user's credentials by the Identity 819 Selector should be done in a secure manner to mitigate against people 820 taking unauthorised control of the device being able to gather these 821 credentials. Use of a secure credential storage mechanism, such as 822 the GNOME Keyring on Linux, or Keychain on the Mac, are recommended. 824 14. IANA Considerations 826 This document does not require actions by IANA. 828 15. Normative References 830 [RFC2119] Bradner, S., "Key words for use in RFCs to 831 Indicate Requirement Levels", BCP 14, 832 RFC 2119, March 1997. 834 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 835 Eronen, "The Network Access Identifier", 836 RFC 4282, December 2005. 838 [RFC5280] Cooper, D., Santesson, S., Farrell, S., 839 Boeyen, S., Housley, R., and W. Polk, 840 "Internet X.509 Public Key Infrastructure 841 Certificate and Certificate Revocation 842 List (CRL) Profile", RFC 5280, May 2008. 844 [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofenig, H., 845 Lear, E., and J. Schaad, "Application 846 Bridging for Federated Access Beyond Web 847 (ABFAB) Architecture", 848 draft-ietf-abfab-arch-12 (work in 849 progress), February 2014. 851 [I-D.ietf-abfab-usecases] Smith, R., "Application Bridging for 852 Federated Access Beyond web (ABFAB) Use 853 Cases", draft-ietf-abfab-usecases-05 (work 854 in progress), September 2012. 856 Appendix A. Change Log 858 Note to RFC Editor: if this document does not obsolete an existing 859 RFC, please remove this appendix before publication as an RFC. 861 IETF draft -01 to ietf draft -02 863 1. Tidying up language throughout. 865 2. Finished remaining TODOs - largely in the error handling section. 867 3. Added security considerations section. 869 IETF draft -00 to ietf draft -01 871 1. Tidying up language throughout 873 2. Doing some of the TODOs 875 3. Added language that tries to explain that this document is not a 876 substitute for good HCI/UX design. 878 4. Changed terminology slightly to avoid confusion between an 879 identity selector "mechanism" and a GSS-API mechanism. 881 5. Added a caveat about the potential for the UI to show the 882 identity currently in use for a particular service. 884 6. Added a requirement that the identity selector must not store the 885 same NAI for multiple identities. 887 7. Stopped talking about "provisioning" after saying that I wouldn't 888 talk about "provisioning". 890 Draft -04 to ietf draft -00 892 1. Adding brief discussion of identities vs identifiers (Ken). 894 2. Changing assumption about credentials having a password in favour 895 of more generic text for other auth types. 897 3. Adding discussion of storage of identity information. 899 4. Added sections on dealing with multiple identities per service, 900 remembering credentials, remembering not to use ABFAB. 902 5. Added small section on ID selector needing to take focus in some 903 way. 905 Draft -03 to draft -04 907 1. Addressing various comments from Jim and Stefan. 909 Draft -02 to draft -03 911 1. Bumping version to keep it alive. 913 Draft -01 to draft -02 915 1. Completed the major consideration sections, lots of rewording 916 throughout. 918 Draft -00 to draft -01 920 1. None, republishing to refresh the document. Other than adding 921 this comment... 923 Appendix B. Open Issues 925 Note to RFC Editor: please remove this appendix before publication as 926 an RFC. 928 Author's Address 930 Dr. Rhys Smith 931 Cardiff University 932 39-41 Park Place 933 Cardiff CF10 3BB 934 United Kingdom 936 Phone: +44 29 2087 0126 937 EMail: smith@cardiff.ac.uk