idnits 2.17.1 draft-ietf-abfab-usability-ui-considerations-04.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 (March 21, 2016) is 2959 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 M. Donnelly 5 Expires: September 22, 2016 Painless Security 6 March 21, 2016 8 Application Bridging for Federated Access Beyond web (ABFAB) Usability 9 and User Interface Considerations 10 draft-ietf-abfab-usability-ui-considerations-04 12 Abstract 14 The real world use of ABFAB-based technologies requires that any 15 identity that is to be used for authentication has to be configured 16 on the ABFAB-enabled client device. Achieving this requires software 17 on that device (either built into the operating system or a 18 standalone utility) that will interact with the user, managing their 19 identity information and identity-to-service mappings. All designers 20 of software to fulfil this role will face the same set of challenges. 21 This document aims to document these challenges with the aim of 22 producing well-thought out UIs with some degree of consistency 23 between implementations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 22, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Considerations around Terminology . . . . . . . . . . . . . . 5 64 5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Services . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.3. Identity to Service Mapping . . . . . . . . . . . . . . . 6 67 6. Considerations around Management of Identities . . . . . . . 7 68 6.1. Information associated with each Identity . . . . . . . . 7 69 6.2. Information associated with each Identity Provider . . . 8 70 6.3. Storage of Identity Information . . . . . . . . . . . . . 9 71 6.4. Adding/Association of an Identity . . . . . . . . . . . . 10 72 6.4.1. Identity Provider Addition . . . . . . . . . . . . . 10 73 6.4.2. Identity Addition . . . . . . . . . . . . . . . . . . 12 74 6.5. Modifying Identity Information . . . . . . . . . . . . . 14 75 6.5.1. Manual Modification . . . . . . . . . . . . . . . . . 14 76 6.5.2. Automated Modification . . . . . . . . . . . . . . . 15 77 6.6. Verifying an identity . . . . . . . . . . . . . . . . . . 15 78 6.7. Removing an Identity . . . . . . . . . . . . . . . . . . 15 79 6.7.1. Manual Removal . . . . . . . . . . . . . . . . . . . 15 80 6.7.2. Automated Removal . . . . . . . . . . . . . . . . . . 16 81 6.8. Storing an Identity with or without credentials . . . . . 16 82 7. Considerations around Management of Service to Identity 83 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. Associating a Service with an Identity . . . . . . . . . 17 85 7.1.1. User-driven Manual Association . . . . . . . . . . . 17 86 7.1.2. Automated Rules-based Association . . . . . . . . . . 17 87 7.1.3. Association Conflicts . . . . . . . . . . . . . . . . 17 88 7.2. Disassociating a Service with an Identity . . . . . . . . 18 89 7.3. Listing Services and Identities . . . . . . . . . . . . . 19 90 7.4. Showing the Service that is requesting Authentication . . 19 91 7.5. Showing the Identity currently in use . . . . . . . . . . 19 92 7.6. Multiple Identities for a Particular Service . . . . . . 20 93 7.7. Not using ABFAB for a Particular Service . . . . . . . . 20 94 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . 20 95 8.1. Errors in GSS-API . . . . . . . . . . . . . . . . . . . . 20 96 8.1.1. Log of Errors . . . . . . . . . . . . . . . . . . . . 21 98 8.2. Examples of errors . . . . . . . . . . . . . . . . . . . 21 99 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 22 100 9.1. Reporting Authentication Success on First Use of Identity 22 101 9.2. Reporting Authentication Success . . . . . . . . . . . . 22 102 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 22 103 10.1. Identity Selector Taking Focus . . . . . . . . . . . . . 22 104 10.2. Import/Export of Credentials . . . . . . . . . . . . . . 22 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 107 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 109 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 110 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 111 16.1. Normative References . . . . . . . . . . . . . . . . . . 25 112 16.2. Informative References . . . . . . . . . . . . . . . . . 26 113 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 114 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 117 1. Introduction 119 The use of ABFAB-based technologies requires that any identity that 120 is to be used for authentication has to be configured on the client 121 device. Achieving this requires software on that device (either 122 built into the operating system or a standalone utility) that will 123 interact with the user, and manage the user's identities and 124 credential-to-service mappings. Anyone designing that software will 125 face the same set of challenges. 127 This document does not intend to supplant evidence-based UI design 128 guidelines; implementers of identity selectors are strongly 129 encouraged to understand the latest in HCI and UX thought and 130 practice. Instead, it aims to document the common challenges faced 131 by implementers with the aim of providing a common starting point for 132 implementers in the hope that this aids in producing well-thought out 133 UIs with some degree of consistency. 135 2. Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Terminology 143 Various items of terminology used in the document are heavily 144 overloaded in that they mean a variety of different things to 145 different people. In an attempt to minimise this problem, this 146 section gives a brief description of the main items of terminology 147 used in order to aid a consistent understanding of this document. 149 o NAI: Network Access Identifier - a standard way of identifying a 150 user and assisting in the routing of an authentication request 151 (see [RFC4282]). 153 o Identity: In this context, an identity is a credential given to a 154 user by a particular organisation with which they have an 155 association. A user may have multiple identities - potentially 156 multiple identities per organisation, and also across multiple 157 organisations. Each identity will consist of an NAI, alongside 158 other information that supports authentication. Note that in 159 other contexts the usual use of "identity" would match our use of 160 "user", whereas the usual use of "identifier" matches our use of 161 identity. 163 o Service: The thing that the user is attempting to authenticate to 164 via ABFAB technology. See [I-D.ietf-abfab-usecases] for some 165 example ABFAB use cases. Also known as the Relying Party. 167 o Identity Provider: The thing able to make access management 168 decisions about the Identity. 170 o Identity Selector: A piece of software that enables the process by 171 which the GSS-API acquires the identity to use with a particular 172 service. An Identity Selector typically would allow the user to 173 configure a set of identities along with service to identity 174 mappings. 176 o Trust anchor: An authoritative source of verification of a 177 particular ABFAB Identity Provider, used to allow authentication 178 of an Identity Provider using X.509 [RFC5280]. Typically this 179 will be a commercial CA to allow authentication via chain of 180 trust, or a preconfigured non-commercial certificate (e.g. self- 181 signed). 183 o Credential: Whatever is used by the user to authenticate 184 themselves with a particular NAI. What exactly this will be will 185 be dependent on the EAP method being used, but is likely to be 186 something like a password or a certificate. 188 4. Context 190 When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to 191 perform federated authentication to some service, a user will need to 192 provide identity information that they wish to use to authenticate to 193 that particular service. This will happen through a process of the 194 application calling the GSS-API, which will in turn gather the user's 195 credentials through some process. We will call this process the 196 "identity selector" in this document (though note that this is not a 197 recommendation on terminology for the process). 199 The simplest way to achieve the desired effect would be a process 200 that simply takes the credentials from the currently logged in user 201 (e.g. the Windows Domain Credentials) and uses those for all services 202 that request authenticate through ABFAB. This approach gives 203 ultimate simplicity in terms of UI (it wouldn't have one) but the 204 least flexibility (the user has to use a single identity for 205 everything). If there is ever to be a requirement for a user to use 206 a different set of credentials for a service, or a requirement for 207 the user to use ABFAB to authenticate to the operating system, then 208 something more complex will be needed. 210 Where there is a requirement for multiple credentials to be 211 supported, there are at least two methods that could be employed to 212 configure identities and associated information: 214 o They could be configured manually by the user in a configuration 215 file that could be edited by hand or some such simple process, and 216 read by the GSS-API mechanism. While this could work very well 217 functionally, in practice only a small subset of users would be 218 happy with - and able to - configure their identities in such a 219 manner. 221 o They could be configured through some interactive process. For 222 ease of use this should have a simple UI, although to support some 223 use cases a headless mode (i.e. a way of interacting with the 224 identity selector when there is no GUI present) may need to be 225 supported. 227 When designing an identity selector with a UI (or indeed, with a 228 headless mode), any implementer will share a common set of usability 229 considerations inherent to the context. This document aims to 230 explore these considerations, and provide advice and guidance on 231 addressing them where possible. 233 5. Considerations around Terminology 235 Anyone designing an identity selector will have to grapple with 236 choosing terminology that the average user has some chance of 237 understanding. This terminology can split into a few main functional 238 areas, as discussed next. 240 5.1. Identity 242 The first area where terminology is needed is around the identity/ 243 identities of the user. Users are typically used to seeing a variety 244 of terms for aspects of their identity in the federated sense, and an 245 even larger variety in the wider Internet sense. For example, in the 246 federated sense some of these terms include "username", "login", 247 "network account", "institutional account", "home organisation 248 account", "credentials", and a myriad of other such terms. However, 249 NAI - the technically correct name for their identity in an ABFAB 250 sense - is highly unlikely to be one of these terms that users are 251 used to seeing. Further, given that the NAI superficially looks like 252 an email address, there is a definite potential for confusion. 254 Implementers of an identity selector will need to carefully consider 255 their intended audience for both their level of technical capability 256 and the existing terminology that they may have been exposed to. 258 Beyond terminology, careful thought needs to be given to the paradigm 259 to use when presenting identity to users, as identities and services 260 are abstract concepts that some users may not find easily 261 understandable. Implementers may wish to keep such abstract concepts 262 despite this, or may wish to examine attempts to map to real world 263 paradigms, e.g. the idea of using "Identity Cards" that are held in 264 the user's "Wallet", as used by the now defunct Microsoft Cardspace 265 ([MS-CS]). 267 5.2. Services 269 Terminology around services is likely to be less of a problem than 270 identity, but it will actually depend on what the service is. For 271 example, each service could be simply described as "server", 272 "system", etc. But for simplicity just the word "service" will 273 probably usually suffice. 275 5.3. Identity to Service Mapping 277 The basic functionality of the Identity Selector is to create the 278 correct combination of Identity and Service, so that the correct 279 identity is chosen to create the credential for the GSS-EAP 280 connection with the given service. Mapping is the process of 281 creating this relationship between identity and service. 283 Depending on your perspective either each identity may be mapped to 284 multiple services, or each service has multiple identities mapped to 285 it. Thus any UI could present either perspective, or both. 287 6. Considerations around Management of Identities 289 One of the core features of an identity selector is the management of 290 a user's identities. This section first looks at what information 291 associated with an identity will need to manage, and then looks in 292 detail at various usability considerations of this area. 294 6.1. Information associated with each Identity 296 The bare minimum set of information that MUST be stored about each 297 identity to allow ABFAB authentication to take place is a single 298 item: 300 o NAI: The user's Network Access Identifier (see [RFC4282]) for this 301 particular credential. For example, "joe@example.com". Note that 302 the identity selector MUST NOT store different identities that use 303 the same NAI. This is required as the NAI is the unique key that 304 is used by the identity selector when interacting with the GSS-API 305 mechanism for various reasons, for example, to allow the GSS-API 306 mechanism to report back error or success statuses or to allow the 307 application to request the use of a specific identity. 309 Next up is a small set of information that SHOULD be stored about 310 each identity to allow the user to effectively select a particular 311 identity: 313 o Identity provider realm: The ABFAB realm of the identity provider. 314 This is used as a key to look up the identity provider from the 315 identity selector's list of identity providers, in order to access 316 the trust anchor during verification of the identity provider. 318 o Credential: Whatever is used by the users to authenticate 319 themselves with a particular NAI. What exactly this will be will 320 be dependent on the EAP method being used, but is likely to be 321 something like a password or a certificate. Note that the 322 identity selector SHOULD allow a user to store the credential. 323 However, there are use cases where a user may specifically opt for 324 this not to be "remembered", so the identity selector MUST NOT 325 store the credential without confirmation from the user. 327 Finally, there is a set of optional information that MAY be stored 328 about each identity that represent useful information for the user to 329 have and could make an identity selector more usable. Note that this 330 list is neither intended to be exhaustive or even particularly 331 correct; any implementer is free to use whatever make sense in their 332 implementation and conforms to good HCI/UX guidelines. Instead, it 333 is simply a suggested starting point. 335 o Friendly name for identity: To allow the user to differentiate 336 between the set of identities represented in the Identity 337 Selector. This should be editable by the user. The only 338 restriction on this name is that it MUST be unique within that 339 particular user's set of identities. For example: "Student 340 username", "Google Account", "Work Login", etc. 342 o Friendly icon for identity: To allow the user to differentiate 343 between the set of identities they have they should be able to set 344 an icon for that particular identity. 346 o Password changing URL: The URL the user should visit should they 347 need to change their password for this particular identity. For 348 example, "http://www.example.com/passwordreset?identifier=myId". 350 o Helpdesk URL: The URL this particular identity should visit to get 351 contact details for the helpdesk of the organisation that issued 352 this particular identity for when the user encounters issues and 353 needs help. For example, https://www.example.com/ 354 helpdesk?identifier=myId. 356 6.2. Information associated with each Identity Provider 358 Identity providers are entities that may be shared across multiple 359 identities. For instance, a person at a university may have one 360 identity as a student and another identity as an employee, but a 361 single identity provider makes access management decisions about 362 both. In these cases, the identity selector MUST consider it an 363 error if the trust anchor for the identity provider is different 364 between the various identities managed by the single identity 365 provider. 367 The bare minimum set of information that MUST be stored about each 368 identity provider is: 370 o Realm: The realm of the identity provider. This will uniquely 371 identify the identity realm. 373 o Trust anchor: For the identity selector to be able to verify that 374 the Identity Provider it is going to talk to and attempt to 375 authenticate against is the Identity Provider that it is 376 expecting, and that it is not being spoofed in some way. This is 377 likely to be an X.509 certificate [RFC5280], or a tuple of 378 (trusted root certificate, servername in Subject or 379 subjectAltName). Storing a credential without a relevant trust 380 anchor allows for the possibility of a malicious attacker 381 intercepting traffic and masquerading as the Identity Provider in 382 question. 384 Identity providers also have a set of optional information that MAY 385 be stored about each identify provider. This set includes, but is 386 not limited to: 388 o Friendly name for the identity provider: To allow the user to 389 differentiate between the set of identity providers represented in 390 the Identity Selector. This should be editable by the user. The 391 only restriction on this name is that it MUST be unique within 392 that particular user's set of identity providers. For example: 393 "My University", "Google", etc. 395 o Friendly icon for the identity provider: To allow the user to 396 differentiate between the set of identity providers they have they 397 should be able to set an icon for that particular identity 398 provider. 400 o Password changing URL: The URL the user should visit should they 401 need to change passwords for identities in this realm. For 402 example, "http://www.example.com/passwordreset". 404 o Helpdesk URL: The URL the user should visit to get contact details 405 for the helpdesk of the organisation that issued this particular 406 identity for when the user encounters issues and needs help. For 407 example, https://www.example.com/helpdesk. 409 Note that the password changing URL and helpdesk URL somewhat mirror 410 the definitions of the same fields in the identity. The distinction 411 is that the URLs in the identity SHOULD apply to the individual 412 identity, whereas the URLs in the identity provider SHOULD apply to 413 all identities that the identity provider defines. For example, an 414 identity password change URL would provide a personalized experience 415 of changing the password for the given identity, but the identity 416 provider password change URL would direct the user to a page where 417 the user would need to enter the individual identity that needs a new 418 password. 420 If the identity contains no password change URL or helpdesk URL, the 421 identity selector MAY present any corresponding URL from the identity 422 selector instead. However, if the identity contains the URL, the 423 identity selector SHOULD present the URL from the identity. 425 6.3. Storage of Identity Information 427 Since some of the information that makes up the identity is sensitive 428 in nature (e.g. containing passwords), then this information SHOULD 429 be stored and accessed securely. This might involve ensuring the 430 credential information is held in encrypted form on device and 431 accessed using a passphrase. For deeper integration into the system, 432 this could be done by using existing secure storage on the system 433 such as Keychain on a Mac, the GNOME keyring on a GNOME based Linux 434 device, or the Credentials Manager on Windows. 436 6.4. Adding/Association of an Identity 438 Users will have one or more identities given to them by organisations 439 that they have a relationship with. One of the core tasks of an 440 identity selector will be to learn about these identities and their 441 identity providers in order to use them when it comes to 442 authenticating to services on behalf of the user. Adding these 443 identities could be done in one of three ways: manual addition, 444 automated addition that is manually triggered, or automated addition 445 that is automatically triggered. Each of these are discussed in more 446 detail next. 448 Note that the term "association" or "addition" of an identity is used 449 rather than "provisioning" of an identity, because while we actually 450 are provisioning identities into the UI, provisioning is an 451 overloaded term in the identity and access management space and could 452 easily be confused with identity provisioning in the sense of the 453 creation of the identity by the home organisation's identity 454 management procedures. 456 6.4.1. Identity Provider Addition 458 6.4.1.1. Manual Identity Provider Addition 460 Allowing users to add an identity provider manually is technically 461 the easiest method to get this information, but it is a method that 462 has the greatest usability drawbacks - including some that create 463 potential security issues. Most of the information required is 464 relatively technical and finding some way of explaining what each 465 field is to an non-technical audience is challenging (to say the 466 least). This especially is the case for trust anchor information. 467 Thus this method should be considered as a power-user option only, or 468 as a fall-back should the other methods not be applicable. 469 Implementers may well decide not to offer the manual option due to 470 these drawbacks. 472 When this method is used, careful consideration should be given to 473 the UI presented to the user. The UI will have to ask for all of the 474 information detailed in Section 6.2. 476 Trust anchors present a particularly onerous challenge for the user 477 to enter. For this reason, many identity selectors will want to 478 implement a leap-of-faith acquisition of the trust anchor. For these 479 leap of faith acquisitions, the identity selector SHOULD present the 480 user with the name of the realm that the identity selector is 481 attempting to reach, the subject of the trust anchor certificate, 482 details of the certification chain, and a fingerprint of the 483 certificate. If the realm does not match the subject of the 484 certificate, the identity selector MUST inform the user of the 485 discrepency. The identity selector MAY reject the leap-of-faith on 486 its own, or MAY allow the user to proceed anyway. If the user 487 proceeds anyway, the identity selector SHOULD urge the user to reject 488 the leap-of-faith. 490 The area of verification of trust anchors is very important. An 491 Identity Selector that allows for manual addition of identity 492 provider information SHOULD try to ensure that trust anchor 493 information is gathered and checked in a secure a manner as possible 494 - where users have to enter and confirm all trust anchor information, 495 or be required to explicitly agree to an insecure configuration if 496 this is not done properly. 498 6.4.1.2. Manually Triggered Automated Identity Provider Addition 500 One way to bypass the need for manual addition of an identity 501 provider - and all of the usability and security issues inherent with 502 that approach - is to provide some sort of manually triggered, but 503 automated, addition process. One approach to accomplishing this, for 504 example, could be for an organisation to have a section on their 505 website where their users could visit and be given piece of data that 506 contains much or all of the relevant identity provider information 507 for importing into the identity selector. 509 Additionally, the user SHOULD be given the opportunity to: 511 o Supply or change the default friendly name and friendly icon for 512 that identity provider - to allow the user to customise the 513 identifier they use for that identity provider; 515 o Reject the addition of the identity provider completely - to allow 516 the user to back out of the association process in an intuitive 517 way. 519 In this case, trust anchors would be directly provided through the 520 automated addition process to help establish the trust relationship 521 in a secure manner. 523 6.4.1.3. Fully Automated Identity Provider Addition 525 Many organisations manage the machines of their users using 526 enterprise management tools. Such organisations may wish to be able 527 to automatically add a particular user's identity provider to the 528 identity selector on their machine/network account so that the user 529 has to do nothing. 531 This represents the best usability for the user - who wouldn't 532 actually have to do anything. However, it can only work on machines 533 centrally managed by the organisation. 535 6.4.2. Identity Addition 537 6.4.2.1. Manual Identity Addition 539 Allowing users to add an identity manually is relatively easy in 540 comparison to adding an identity provider manually. If the identity 541 provider is already known in the identity selector, then the identity 542 selector can construct the NAI from the identity provider and a 543 username. Thus the manual addition of an identity in a known realm 544 needs to prompt the user only to pick the realm, to enter the 545 username, and to enter the credential. If the identity provider is 546 not known to the identity selector, the identity selector will 547 provide the user with a way to define a new one as part of the 548 identity addition. 550 There are two points at which a user could manually add an identity: 552 o Asynchronously: the user could be allowed to, at any time, trigger 553 a workflow of manually adding an identity. This represents the 554 most flexible way of adding an identity since a user can perform 555 this at any time. It does, however, also have inherent issues 556 when it comes to verifying the newly added identity - see 557 Section 6.6. 559 o Just In Time: when connecting to a service which has no mapping to 560 an existing identity, the user could be given an option to add a 561 new one, as well as associating with an existing one. This seems 562 to present a better user experience when it comes to verifying the 563 newly added identity (see Section 6.6), however, it represents a 564 less direct method of adding an identity. Users who have not yet 565 added the appropriate identity to their identity selector may find 566 it difficult to understand that they must try to access a 567 particular service in order to add an identity. 569 Of course, implementers could support both styles of identity 570 addition to gain the benefits of both and give flexibility to the 571 user. 573 6.4.2.2. Manually Triggered Automated Identity Addition 575 Much like in the case of the manually triggered automated identity 576 provider addition Section 6.4.1.2, an identity could be added to the 577 identity selector through a user-initiated mechanism. To follow the 578 example in the identity provider section above, the organization 579 could enhance the identity provider addition web service to prompt 580 for the user part of the NAI. The web service could then generate 581 all of the data needed for adding both the identity provider and the 582 identity. 584 It is reasonable to assume that any such automated addition service 585 is likely to be organisation specific, so that the Issuing 586 Organisation and realm part of the NAI will be constant, as would be 587 the trust anchor information. The user part of their NAI will have 588 been input on the web service. The password could be provided as a 589 part of the provided data or the identity selector could prompt the 590 user to enter it. 592 If the identity provider data contained in this identity to be added 593 conflicts with an existing identity provider known to the identity 594 selector, the identity selector SHOULD present the discrepency to the 595 user. The identity selector MAY reject the identity provider and 596 identity on its own, or MAY allow the user to proceed anyway. If the 597 identity selector allows the user to proceed anyway, the identity 598 selector SHOULD urge the user to reject the leap-of-faith, and 599 require the user to confirm the intent to proceed before proceeding. 601 Additionally, the user SHOULD be given the opportunity to: 603 o Supply or change the default friendly name for that identity - to 604 allow the user to customise the identifier they use for that 605 identity; 607 o Indicate whether or not the identity selector should always ask 608 before using services with this identity - to customise the way in 609 which the identity selector interacts with the user with this 610 particular identity; 612 o Reject the addition of the identity completely - to allow the user 613 to back out of the association process in an intuitive way. 615 6.4.2.3. Fully Automated Identity Addition 617 Section Section 6.4.1.3 introduced the concept of using enterprise 618 management tools to add an identity provider to the identity 619 selector. These enterprise management tools could be used to add an 620 identity that uses the identity provider added in the above manner. 622 The user would not need to decipher difficult to understand data 623 entry screens. 625 However, having an identity automatically provided, including its 626 password, does have some particular usability issues. Users are used 627 to having to provide their username and password to access remote 628 services. When attempting to access services, authenticating to them 629 completely transparently to the user could represent a source of 630 confusion. User training within an organisation to explain that 631 automated population of their identity has been enabled is the only 632 way to counter this. 634 6.5. Modifying Identity Information 636 This process is conceptually fairly similar to adding an identity, 637 and thus shares many of the usability issues with that process. Some 638 particular things are discussed here. 640 6.5.1. Manual Modification 642 An identity selector may allow a user to manually modify some or all 643 of the information associated with each identity. The obvious items 644 that SHOULD be allowed to be changed by the user are the friendly 645 name, the friendly icon, and the credential, or password, associated 646 with the identity. 648 The identity selector should restrict other modification of the 649 information: 651 o Identity Selectors SHOULD NOT allow the editing of the NAI of an 652 identity or the trust anchor of an identity provider for items 653 that have been added through automated means (Section 6.4.1.2, 654 Section 6.4.1.3, Section 6.4.2.2 and Section 6.4.2.3). 656 o Identity Selectors MAY allow the update of the trust anchor of 657 identity providers that have stored the trust anchor through just 658 in time manual addition, using another just in time retrieval of 659 the trust anchor. Any identity selector that allows this update 660 MUST inform the user of the change in the trust anchor, and advise 661 the user that any unexpected change should be assumed to be an 662 attack. 664 o Identity Selectors SHOULD NOT allow manual modification of the 665 password changing URL. 667 o Identity Selectors SHOULD NOT allow manual modification of the 668 helpdesk URL. 670 6.5.2. Automated Modification 672 To ease usability, organisations may wish to automatically provide 673 updates to identity provider or identity information. For example, 674 if the user's password changes it could automatically update the 675 password for the identity in the user's identity selector, or if the 676 trust anchor information changes (e.g. if a certificate is changed) 677 it could be automatically pushed out to all users. 679 6.6. Verifying an identity 681 An inherent by-product of the ABFAB architecture is that an identity 682 cannot be verified during the addition process; it can only be 683 verified while it is in use with a real service. This represents a 684 definite usability issue no matter which method of identity addition 685 is used (see Section 6.4): 687 o If the user has manually added the identity (see Section 6.4) they 688 may have gone through the whole manual process with no errors and 689 so believe the identity has been set up correctly. However, when 690 they attempt to access a service, they may be given an error 691 message, thus causing some amount of confusion. 693 o If the user has had the identity populated into their identity 694 selector, then there is a much greater chance of the identity 695 information being correct. However, if any of the information is 696 not correct, then there is the potential for confusion as the user 697 did not add the information in the first place. 699 Also, if the identity information is incorrect the user may not know 700 where the error lies, and the error messages provided by the process 701 may not be helpful enough to indicate the error and how to fix it 702 (see Section 8). 704 6.7. Removing an Identity 706 This is fairly similar to adding or modifying an identity, and thus 707 shares many of the usability issues with those processes. Some 708 particular things are discussed here. 710 6.7.1. Manual Removal 712 Allowing the user to manually delete an identity is probably the best 713 way to achieve the goal. Any UI should allow for this option. 715 6.7.2. Automated Removal 717 While automated removal of an identity is a way of achieving the goal 718 without having to interact with the user, the consequence is that 719 things may disappear from the user's identity selector without them 720 realising. 722 6.8. Storing an Identity with or without credentials 724 Sometimes, a user may wish to have the identity they wish to use with 725 a service stored by the identity selector, but not the credential 726 (e.g. password) that goes along with that Identity. The consequence 727 of this is that when a user attempts to authenticate to a service for 728 which an identity, but no credential, is stored, then the user would 729 need to be prompted to manually enter the credential. 731 7. Considerations around Management of Service to Identity Mappings 733 A service to identity mapping tells the identity selector which 734 identity should be used for a particular service. There is 735 potentially a many-to-many association between identities and 736 services since a user may wish to use one of their identities for 737 many services, or more than one identity for a single service (e.g. 738 if they have multiple roles on that service). 740 This potentially complex many-to-many association between identities 741 and services is not easily comprehended by the user, and allowing the 742 user to both manipulate it and control can be challenging. These 743 obstacles are especially common when errors occur after an 744 association has been made. In this scenario it is important that an 745 identity can be disassociated with a service. 747 To further complicate the picture, users may wish for: 749 1. The identity to service mapping to be stored along with the 750 credential, i.e. the user should always be authenticated to a 751 particular service with a particular identity with no prompting. 753 2. The identity to service mapping to be stored but not the 754 credential, i.e. the user should not be prompted to choose the 755 identity for a particular service, but should be prompted to 756 enter their credential for that identity. 758 3. The identity to service mapping to not be stored, i.e. the user 759 should be asked which identity to use every time they 760 authenticate to a particular service. 762 7.1. Associating a Service with an Identity 764 There needs to be a way for the user to create the service to 765 identity association. It is advisable that this link be made only 766 after the identity in question has authenticated with the service 767 without any error. 769 There are a few ways this association could happen. 771 7.1.1. User-driven Manual Association 773 There are two ways in which manual association of an identity to a 774 service could happen: 776 1. The identity selector MAY allow the user to associate a 777 particular service with a particular identity manually, using the 778 identity selector before they first attempt to use the service. 779 This method is inadvisable, however, because not only might the 780 identity in question not yet have authenticated successfully, the 781 user would also need to know all the required technical details 782 of that service beforehand, such as its GSS Acceptor Name. 784 2. On encountering a service new to the identity selector, the 785 identity selector SHOULD pop up a dialogue box to the user asking 786 if they would like to use an existing identity for this service 787 (and might also allow them to create a new identity and use 788 that). 790 7.1.2. Automated Rules-based Association 792 It would be beneficial from a usability perspective to minimise - or 793 avoid entirely - situations where the user has to pick an identity 794 for a particular service. This could be accomplished by having rules 795 to describe services and their mapping to identities. Such a rule 796 could match, for example, a particular identity for all IMAP servers, 797 or a particular identity for all services in a given service realm. 798 These rules could be configured as a part of the automated identity 799 addition process described in Section 6.4.2.2 or Section 6.4.2.3. 801 7.1.3. Association Conflicts 803 The presence of rules-based associations brings with it potential 804 conflicts in the rules. A non-exhaustive list of conflicts includes: 806 o One rule applies to all services of a particular type, while 807 another rule applies to all services within a particular domain. 808 For example, one rule applies identity A to all IMAP services, 809 while another rule applies identity B to all services in the 810 example.com domain. 812 o One rule originates from enterprise management tools as described 813 in Section 6.4.2.3, and another rule originates from manual 814 addition. 816 o The user has associated an identity with a service upon 817 encountering the service for the first time, and later creates a 818 rule that matches all services within that service's realm. 820 Identity selectors MUST order the precedence of rules as follows: 822 1. Manually created rules matching specific services and realms 824 2. Enterprise created rules matching specific services and realms 826 3. Manually created rules matching any service in a single realm 828 4. Enterprise created rules matching any service in a single realm 830 5. Manually created rules matching a single service in any realm 832 6. Enterprise created rules matching a single service in any realm 834 Identity selectors SHOULD notify the user whenever a new rule will 835 take precedence over an existing rule. 837 7.2. Disassociating a Service with an Identity 839 A user MUST be able to disassociate an identity with a service - that 840 is, to be able to remove the mapping without having to remove the 841 identity. 843 For serious authentication errors, the identity selector SHOULD 844 prompt the user to choose whether to disassociate the identity from 845 the service or retain the association. The prompt SHOULD explain the 846 nature of the error. 848 When such a serious authentication error occurs and the identity is 849 selected by a rules-based association (Section 7.1.2), any 850 disassociation prompt MUST inform the user that the identity was 851 selected by a rule. The prompt SHOULD allow the user to retain the 852 association, or to disassociate the rule altogether. The prompt MAY 853 include a third choice, to create an exception so that the rule does 854 not apply to this specific service. 856 As of this writing, there are no authentication failures that should 857 cause the disassociation of an identity from a service. 859 7.3. Listing Services and Identities 861 A service listing should be considered in the identity selector which 862 is both searchable and editable by the user. 864 7.4. Showing the Service that is requesting Authentication 866 When a user is attempting to authenticate to a service for the first 867 time, there should be some indication given to the user as to which 868 service is requesting authentication. In many cases, the service may 869 be obvious (where the user has started the process of attempting to 870 authenticate to a particular service), but in other cases this may 871 not be obvious (e.g. if an authentication attempt is triggered by a 872 timer or a specific event), and for this scenario some indication as 873 to the requesting service is necessary. 875 7.5. Showing the Identity currently in use 877 It would be beneficial if, when using a service, the identity 878 currently in use could be made visible to the user while they are 879 using a specific service. This allows the user to identify which 880 identity is used with a particular service at a particular time (the 881 user may have more than one identity that they could use with a 882 particular service) - so that they can then disassociate the pairing. 883 This is especially useful when the identity is selected without any 884 user prompt, because of a previous association. 886 Implementing such a feature may be hard, however, due to the layered 887 nature of the ABFAB transaction - the identity selector will 888 certainly know when successful (or failed) authentications to a 889 particular service have happened, but after that it typically plays 890 no further part in the use of the service. Therefore, knowing that a 891 particular service is still using a particular identity in order to 892 indicate this to the user would be challenging. 894 One approach that could be used would be to display OS notifications 895 when an identity is used. The notification could include information 896 such as the application requesting the identity, the service 897 receiving the identity, and the identity used. Another approach 898 could be for the identity selector to maintain a history of identity 899 use. 901 7.6. Multiple Identities for a Particular Service 903 An Identity Selector should be able to deal with the case where a 904 user has multiple identities associated with a single service. For 905 example, upon receiving a request for authentication to a service 906 that multiple identities are configured for, ask the user which of 907 the identities should be used in this instance. 909 7.7. Not using ABFAB for a Particular Service 911 There may be cases where a user does not wish to use ABFAB based 912 authentication at all to a particular service, even though it is 913 ABFAB enabled. To support this, the identity selector would have to 914 allow the user to choose not to use ABFAB when they attempt to 915 authenticate to a service. It would be desirable if the user could 916 also flag that this should be remembered. 918 8. Handling of Errors 920 Errors during the ABFAB authentication process can happen at any of 921 the many layers - they could be GSS-API errors, EAP errors, RADIUS/ 922 RadSec errors, SAML errors, application errors, etc. ABFAB based 923 technologies are limited in error handling by the limitations in the 924 protocols used. 926 8.1. Errors in GSS-API 928 All GSS-API calls are necessarily instantiated from within the 929 calling application. For this reason, when an error occurs the error 930 is passed back to the application in order for it to deal with it. 931 To retry, the application needs to re-initiate the GSS-API call. 932 Unless the application has been written to deal with this properly, 933 this process can be very tedious for a user and cause them opt out of 934 what they are trying to accomplish. In addition to this, the 935 application may not display the error messages to the user. Even 936 when the application does display the errors, the messages themselves 937 may not be useful enough for the user to decipher what has gone 938 wrong. 940 Two extensions to GSS-API are suggested for the consideration of the 941 kitten working group: 943 o GSS-API should provide a method for applications to invoke to 944 indicate that the application has displayed the last error to the 945 user. 947 o GSS-API should provide a method for applications to invoke to 948 indicate that the authentication succeeded, but is insufficient 949 for the task at hand and needs to be retried. 951 8.1.1. Log of Errors 953 The Identity Selector can improve the general GSS-API error reporting 954 experience by displaying a list of errors experienced by ABFAB 955 applications. When an application error occurs, the EAP mechanism 956 MAY record that error. If the mechanism records these errors, the 957 Identity Selector MAY display these errors to the user. Thus, the 958 user will have a single place to go to view all of the errors that a 959 user experiences across all applications. Therefore, an Identity 960 Selector that implements an error display SHOULD present the user 961 with the context of the error, including the calling application and 962 the time. 964 8.2. Examples of errors 966 To give an idea of the range of errors that might be seen, consider 967 the following non-exhaustive set of potential errors. 969 Identity Association/Verification Errors: 971 o The credentials presented to the IdP were not able to be verified 972 - e.g. wrong username/password. 974 o The Trust Anchor for the IdP was invalid. 976 Service Errors: 978 o The IdP recognizes the client, but decides not to authorize it for 979 this service. 981 o The EAP session succeeds, but the RADIUS system sends access- 982 reject to the Relying Party 984 o The RADIUS system succeeds, but the Relying Party rejects the 985 session. For instance, the SAML part of the session could contain 986 an error that causes the Relying Party to reject the client. 988 o The Identity might have been successfully authenticated, but the 989 user might not have authorisation to use the service or privilege 990 levels within the service they are attempting to use. For 991 instance, the Identity could authorise the use of an operating 992 system as an unprivileged user, which would prevent the user's 993 goal of managing the hard drives. 995 Other Errors: 997 o The IdP didn't respond to the Service. 999 o The IdP didn't respond to the Client. 1001 o Network errors. 1003 o Timing errors. 1005 9. Handling of Successes 1007 It is of course hoped that the identity selector will have to 1008 occasionally handle successes as well as errors. This section has 1009 some brief discussion about some areas you might want to think about. 1011 9.1. Reporting Authentication Success on First Use of Identity 1013 The first time an identity is used with a service, it would be good 1014 practice to visually indicate in some way that the process has been 1015 successful, in order that the user understands what is happening and 1016 is then prepared for future authentication attempts. 1018 9.2. Reporting Authentication Success 1020 On an on-going basis you may or may not wish to indicate visually to 1021 the user a successful authentication to a service. This relates to 1022 Section 7.5. 1024 10. Other Considerations 1026 This section briefly discusses other considerations that you might 1027 want to think about that don't fit in any of the other categories. 1029 10.1. Identity Selector Taking Focus 1031 When an ABFAB authentication request is triggered, and where it needs 1032 input from the user, the Identity Selector should take focus in some 1033 way so that it is clear to the user that they need to do something to 1034 proceed. 1036 10.2. Import/Export of Credentials 1038 For various reasons, an identity selector implementation might want 1039 to include functionality that allows for the export/import of 1040 identities and service to identity mappings. This could be for 1041 backup purposes, to allow a degree of mobility between identity 1042 selector instances, etc. 1044 If providing this functionality, it would be advisable that the 1045 credential store that is the result of the export should be secure - 1046 encrypted and password protected - given the nature of the 1047 information. 1049 11. Security Considerations 1051 Most security considerations are ones relevant to the use of GSS-EAP 1052 and are detailed in [I-D.ietf-abfab-arch]. There are, however, a few 1053 specific sets of security considerations related to the UI 1054 implementation. 1056 First, as discussed earlier, the Identity Selector should use a Trust 1057 Anchor to authenticate the IdP before it sends the users credentials 1058 to it. Having no Trust Anchor information at all, or an incorrect 1059 Trust Anchor, can enable the possibility of someone spoofing the IdP 1060 and harvesting credentials sent to it. So, how this Trust Anchor is 1061 configured and managed can have major security implications: 1063 o The most secure way for a Trust Anchor to be configured is to have 1064 it provisioned alongside the other identity information in an 1065 enterprise provisioning scenario. This allows for the correct 1066 Trust Anchor to be configured with no user input required. 1067 However, thought needs to be given to Trust Anchor expiry and 1068 consequent requirement for regular reprovisioning of identity 1069 information. 1071 o Another way that is potentially secure would be to allow the user 1072 to discover the Trust Anchor information out of band and manually 1073 input this information into the Identity Selector. This is only 1074 secure, however, for those users who understand what they're doing 1075 in this scenario; pragmatically, this is unlikely to be the case 1076 for many users so is not a recommended approach for the average 1077 user. 1079 o A pragmatic approach would be leap of faith, whereby no Trust 1080 Anchor information is initially provisioned, and the first time 1081 the Identity Selector connects to the IdP it remembers the Trust 1082 Anchor information for future use. This doesn't mitigate against 1083 spoofing of an IdP in the first instance, but would enable 1084 mitigation against it for all future connections. 1086 o Finally, there may be interesting ways to leverage technologies 1087 such as DANE [RFC6698] to store the Trust Anchor for an IdP in 1088 DNS. 1090 Secondly, the storage of the user's credentials by the Identity 1091 Selector should be done in a secure manner to mitigate against people 1092 taking unauthorised control of the device being able to gather these 1093 credentials. Use of a secure credential storage mechanism, such as 1094 the GNOME Keyring on Linux, or Keychain on the Mac, are recommended. 1096 12. Privacy Considerations 1098 Since the ABFAB system facilitates the sharing of identifying 1099 information about a user, the undesired sharing of information is a 1100 real concern. Most of the privacy considerations lie outside the 1101 scope of the Identity Selector UI, which neither controls nor sees 1102 which attributes of an identity will be shared with a service. In 1103 essence, the only control that the Identity Selector has is whether 1104 or not a given identity will be shared with the service. 1106 However, the selection of identity does warrant privacy 1107 considerations. Any automated choice of identity for a service will 1108 share information, potentially inappropriately. Examples of this 1109 include: 1111 o Rules that apply to a service across all realms will cause an 1112 identity choice, even for realms the user would actually prefer to 1113 avoid interacting with at all. 1115 o Storing a default for a particular service and realm will cause 1116 the identity to be selected in that situation going forward, even 1117 if the situation or application does not warrant that. For 1118 instance, a web browser in privacy mode ideally should not know of 1119 any saved identity association choices. 1121 Even appropriate choices of sharing an identity with a service leaks 1122 information about the user. The desired service and the identity 1123 provider must communicate with each other to perform an 1124 authentication. Even if the authentication fails, the service will 1125 know the realm of the user credential, and the Identity Provider will 1126 know the realm, and maybe the service, that the user tried to access. 1127 For services with fallback authentication mechanisms, the system may 1128 try and fail to authenticate the user, thus sharing the realm 1129 information noted above, without the user being aware this has 1130 happened. 1132 13. IANA Considerations 1134 This document does not require actions by IANA. 1136 14. Contributors 1138 The following individuals made important contributions to the text of 1139 this document: Sam Hartman (Painless Security LLC), and Maria Turk 1140 (Codethink Ltd). 1142 15. Acknowledgements 1144 Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, 1145 Alejandro Perez-Mendez, Ken Klingenstein, and Dave Crocker for 1146 feedback and suggestions. 1148 16. References 1150 16.1. Normative References 1152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1153 Requirement Levels", BCP 14, RFC 2119, 1154 DOI 10.17487/RFC2119, March 1997, 1155 . 1157 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1158 Network Access Identifier", RFC 4282, 1159 DOI 10.17487/RFC4282, December 2005, 1160 . 1162 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1163 Housley, R., and W. Polk, "Internet X.509 Public Key 1164 Infrastructure Certificate and Certificate Revocation List 1165 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1166 . 1168 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1169 of Named Entities (DANE) Transport Layer Security (TLS) 1170 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1171 2012, . 1173 [I-D.ietf-abfab-arch] 1174 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1175 Schaad, "Application Bridging for Federated Access Beyond 1176 Web (ABFAB) Architecture", draft-ietf-abfab-arch-12 (work 1177 in progress), February 2014. 1179 [I-D.ietf-abfab-usecases] 1180 Smith, R., "Application Bridging for Federated Access 1181 Beyond web (ABFAB) Use Cases", draft-ietf-abfab- 1182 usecases-05 (work in progress), September 2012. 1184 16.2. Informative References 1186 [MS-CS] Brown, K., "The InfoCard Identity Revolution", July 2006, 1187 . 1190 Appendix A. Change Log 1192 Note to RFC Editor: if this document does not obsolete an existing 1193 RFC, please remove this appendix before publication as an RFC. 1195 IETF draft -03 to ietf draft -04 1197 1. Document service errors. 1199 2. Document GSS error handling, including a request for a couple of 1200 new GSS methods, and maintaining a log of all GSS errors for 1201 later viewing. 1203 IETF draft -02 to ietf draft -03 1205 1. Tidying up language throughout. 1207 2. Added the idea of an identity provider object within the identity 1208 selector, and moved the trust anchor property from the identity 1209 to the identity provider. 1211 3. Added restrictions on manual modification of automatically added 1212 identities and identity providers. 1214 4. Added precedence between identity association rules. 1216 5. Incorporated many comments from the mailing list. 1218 6. Added privacy considerations section. 1220 IETF draft -01 to ietf draft -02 1222 1. Tidying up language throughout. 1224 2. Finished remaining TODOs - largely in the error handling section. 1226 3. Added security considerations section. 1228 IETF draft -00 to ietf draft -01 1230 1. Tidying up language throughout 1232 2. Doing some of the TODOs 1234 3. Added language that tries to explain that this document is not a 1235 substitute for good HCI/UX design. 1237 4. Changed terminology slightly to avoid confusion between an 1238 identity selector "mechanism" and a GSS-API mechanism. 1240 5. Added a caveat about the potential for the UI to show the 1241 identity currently in use for a particular service. 1243 6. Added a requirement that the identity selector must not store the 1244 same NAI for multiple identities. 1246 7. Stopped talking about "provisioning" after saying that I wouldn't 1247 talk about "provisioning". 1249 Draft -04 to ietf draft -00 1251 1. Adding brief discussion of identities vs identifiers (Ken). 1253 2. Changing assumption about credentials having a password in favour 1254 of more generic text for other auth types. 1256 3. Adding discussion of storage of identity information. 1258 4. Added sections on dealing with multiple identities per service, 1259 remembering credentials, remembering not to use ABFAB. 1261 5. Added small section on ID selector needing to take focus in some 1262 way. 1264 Draft -03 to draft -04 1266 1. Addressing various comments from Jim and Stefan. 1268 Draft -02 to draft -03 1270 1. Bumping version to keep it alive. 1272 Draft -01 to draft -02 1274 1. Completed the major consideration sections, lots of rewording 1275 throughout. 1277 Draft -00 to draft -01 1279 1. None, republishing to refresh the document. Other than adding 1280 this comment... 1282 Appendix B. Open Issues 1284 Note to RFC Editor: please remove this appendix before publication as 1285 an RFC. 1287 Authors' Addresses 1289 Dr. Rhys Smith 1290 Cardiff University 1291 39-41 Park Place 1292 Cardiff CF10 3BB 1293 United Kingdom 1295 Phone: +44 29 2087 0126 1296 EMail: smith@cardiff.ac.uk 1298 Mark Donnelly 1299 Painless Security 1300 14 Summer Street 1301 Suite 202 1302 Malden, Massachusetts 02176 1303 United States 1305 EMail: mark@painless-security.com