idnits 2.17.1 draft-smith-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 (September 25, 2013) is 3866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 w 3 ABFAB R. Smith 4 Internet-Draft Cardiff University 5 Intended status: Informational September 25, 2013 6 Expires: March 29, 2014 8 Application Bridging for Federated Access Beyond web (ABFAB) Usability 9 and User Interface Considerations 10 draft-smith-abfab-usability-ui-considerations-04 12 Abstract 14 The use of ABFAB-based technologies requires that each user's device 15 is configured with the user's identities that they wish to use in 16 ABFAB transactions. This will require something on that device, 17 either built into the operating system or a standalone utility, that 18 will manage the user's identities and identity to service mappings. 19 Anyone designing that "something" will face the same set of 20 challenges. This document aims to document these challenges with the 21 aim of producing well-thought out UIs with some degree of 22 consistency. 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 March 29, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . 6 66 6. Considerations around Management of Identities . . . . . . . . 7 67 6.1. Information associated with each Identity . . . . . . . . 7 68 6.2. Adding/Association of an Identity . . . . . . . . . . . . 8 69 6.2.1. Manual Addition . . . . . . . . . . . . . . . . . . . 8 70 6.2.2. Manually Triggered Automated Addition . . . . . . . . 9 71 6.2.3. Fully Automated Addition . . . . . . . . . . . . . . . 10 72 6.3. Modifying Identity Information . . . . . . . . . . . . . . 10 73 6.3.1. Manual Modification . . . . . . . . . . . . . . . . . 10 74 6.3.2. Automated Modification . . . . . . . . . . . . . . . . 11 75 6.4. Verifying an identity . . . . . . . . . . . . . . . . . . 11 76 6.5. Removing an Identity . . . . . . . . . . . . . . . . . . . 11 77 6.5.1. Manual Removal . . . . . . . . . . . . . . . . . . . . 11 78 6.5.2. Automated Removal . . . . . . . . . . . . . . . . . . 11 79 7. Considerations around Management of Service to Identity 80 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. Listing Services and Identities . . . . . . . . . . . . . 12 82 7.2. Showing the Identity currently in use . . . . . . . . . . 12 83 7.3. Associating a Service with an Identity . . . . . . . . . . 12 84 7.3.1. User-driven Manual Association . . . . . . . . . . . . 12 85 7.3.2. Automated Rules-based Association . . . . . . . . . . 13 86 7.4. Disassociating a Service with an Identity . . . . . . . . 13 87 8. Handling of Errors . . . . . . . . . . . . . . . . . . . . . . 13 88 8.1. Identity Association/Verification Errors . . . . . . . . . 14 89 8.2. Service Errors . . . . . . . . . . . . . . . . . . . . . . 14 90 8.3. Other Errors. . . . . . . . . . . . . . . . . . . . . . . 14 91 9. Handling of Successes . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Reporting Authentication Success on First Use of 93 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 9.2. Reporting Authentication Success . . . . . . . . . . . . . 14 95 10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 14 96 10.1. Import/Export of Credentials . . . . . . . . . . . . . . . 14 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 100 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 101 15. Normative References . . . . . . . . . . . . . . . . . . . . . 15 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 103 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 105 1. Introduction 107 The use of ABFAB-based technologies requires that a user's device is 108 configured with their identities that they wish to use in ABFAB 109 transactions. Achieving this will require something on that device, 110 either built into the operating system or a standalone utility, that 111 will manage the user's identities and identity to service mappings. 112 Anyone designing that "something" will face the same set of 113 challenges. This document aims to document these challenges with the 114 aim of producing well-thought out UIs with some degree of 115 consistency. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Terminology 125 Various items of terminology used in the document are heavily 126 overloaded and thus could mean a variety of different things to 127 different people. In an attempt to minimise this problem, this 128 section gives a brief description of the main items of terminology 129 used in order to aid with a consistent understanding of this 130 document. 132 o NAI: Network Access Identifier - a standard way of identifying a 133 user. See [RFC4282]. 135 o Identity: In this context, an identity is a credential given to a 136 user by a particular organisation with which they have an 137 association. A user MAY have multiple identities. The identity 138 will consist of an NAI, alongside other information that supports 139 authentication. 141 o Service: The thing that the user is attempting to authenticate to 142 via ABFAB technology. See [TODO: Link to ABFAB-Use-Cases] for 143 example use cases of what these services could be. 145 o Identity Selector: The mechanism by which the GSS-API acquires the 146 identity to use with a particular service. An Identity Selector 147 typically would allow the user to configure a set of identities 148 along with service to identity mappings. 150 o Trust anchor: An authoritative source of verification of a 151 particular service, used to allow authentication of a server using 152 X.509 [TODO: link]. Typically a commercial CA to allow 153 authentication via chain of trust, or a preconfigured non- 154 commercial certificate. 156 4. Context 158 When using the ABFAB architecture to perform federated authentication 159 to some service, when a user attempts to authenticate to an ABFAB 160 secured application they will need to provide identity information 161 that they wish to authenticate to that particular service with. This 162 will happen through a process of the application calling the GSS-API, 163 which will in turn gather the users credentials through whatever 164 mechanism it has been configured to do so. We will call this 165 mechanism the "identity selector" in this document, though note that 166 this is not a recommendation on terminology for the mechanism! 168 The simplest way to achieve the desired effect would be a mechanism 169 that simply takes the credentials from the currently logged in user 170 (e.g. the Windows Domain Credentials) and uses those for all services 171 that request authenticate through ABFAB. This approach gives 172 ultimate simplicity in terms of UI - i.e. it wouldn't have one - but 173 the least flexibility. If there is ever to be a requirement for a 174 user to use a different set of credentials for a service, then 175 something more complex will be needed. 177 Where there is a requirement for multiple credentials to be 178 supported, there are of course two methods that could be employed to 179 configure identities and associated information: 181 o They could be configured manually by a user in a configuration 182 file that could be edited by hand or some such simple mechanism, 183 and read by the GSS-API mechanism. While this could work very 184 well functionally, in practice only a small subset of users would 185 be happy with - and able to - configure their identities in such a 186 manner. 188 o They could be configured through some interactive mechanism. For 189 ease of use this should have a simple UI, although a headless mode 190 may need to be supported for those not using a GUI. 192 When designing an identity selector with a UI (or indeed, with a 193 headless mode), any implementer will share a common set of usability 194 considerations inherent to the context. This document aims to 195 explore these considerations, and provide advice and guidance on 196 addressing them where possible. 198 5. Considerations around Terminology 200 Anyone designing an identity selector will have to grapple with 201 choosing terminology that the average user has some chance of 202 understanding. This terminology can split into a few main functional 203 areas, as discussed next. 205 5.1. Identity 207 The first area where terminology is needed is around the identity/ 208 identities of the user. Users are typically used to seeing a variety 209 of terms for aspects of their identity in the federated sense, and an 210 even larger variety in the wider internet sense. For example, in the 211 federated sense some of these terms include "username", "login", 212 "network account", "institutional account", "home organisation 213 account", "credentials", and a myriad of other such terms. However, 214 NAI - the technically correct name for their identity in an ABFAB 215 sense - is highly unlikely to be one of these terms that users are 216 used to seeing. 218 Implementers of an identity selector will need to carefully consider 219 their intended audience for both their level of technical capability 220 and the existing terminology that they may have been exposed to. 222 Beyond terminology, careful thought needs to be given to the paradigm 223 to use when presenting identity to users, as identities and services 224 are abstract concepts that some users may not find is easily 225 understandable. Implementers may wish to keep such abstract 226 concepts, or may wish to examine attempts to map to real world 227 paradigms, e.g. the idea of using "Identity Cards" that are held in 228 the user's "Wallet", as used by Microsoft Cardspace. 230 5.2. Services 232 Terminology around services is likely to be less of a problem than 233 identity, but it will actually depend on what the service is. For 234 example, each service could be simply described as "server", 235 "system", etc. But for simplicity just the word "service" will 236 probably suffice. 238 5.3. Identity to Service Mapping 240 Depending on your perspective either each identity may be mapped to 241 multiple services, or each service has multiple identities mapped to 242 it. Thus any UI could present either perspective, or both. 244 6. Considerations around Management of Identities 246 One of the core features of an identity selector is the management of 247 a user's identities. This section first looks at what information 248 associated with an identity will need to managed, and then looks in 249 detail at various usability considerations of this area. 251 6.1. Information associated with each Identity 253 There is firstly a minimal set of information that MUST be stored 254 about each identity to allow ABFAB authentication to take place: 256 o NAI: The user's Network Access Identifier (see [RFC4282]) for this 257 particular credentials. For example, "joe@example.com". 259 o Password: The password associated with this particular NAI. 261 o Trust anchor: For the identity selector to be able to verify that 262 the server it is going to talk to and attempt to authenticate 263 against is the server that it is expecting, and that it is not 264 being spoofed in some way. This is likely to be an X.509 265 certificate [TODO X509 ref], or a tuple of (trusted root 266 certificate, servername in Subject or subjectAltName). 268 Next up is a small set of information that SHOULD be stored about 269 each identity to allow the user to effectively select a particular 270 identity: 272 o Friendly name for identity: To allow the user to differentiate 273 between the set of identities represented in the Identity 274 Selector. This should be editable by the user. The only 275 restriction on this name is that it MUST be unique within that 276 particular user's set of identities. For example: "My 277 University", "Google Account", "Work Login", etc. 279 o Friendly icon for identity: To allow the user to differentiate 280 between the set of identities they have they should be able to set 281 an icon for that particular identity. 283 Finally, there is a set of optional information that MAY be stored 284 about each identity that represent useful information for the user to 285 have. Note that this list is not intended to be exhaustive; any 286 implementer is free to add any more items to their identity selector 287 that make sense in their implementation. 289 o Password changing URL: The URL the user should visit should they 290 need to change their password for this particular identity. For 291 example, "http://www.example.com/passwordreset". 293 o Helpdesk URL: The URL the user should visit to get contact details 294 for the helpdesk of the organisation that issued this particular 295 identity for when the user encounters issues and needs help. For 296 example, https://www.exmaple.com/helpdesk. 298 6.2. Adding/Association of an Identity 300 Users will have one or more identities given to them by organisations 301 that they have a relationship with. One of the core tasks of an 302 identity selector will be to learn about these identities in order to 303 use them when it comes to authenticating to services on behalf of the 304 user. Adding these identities could be done in one of three ways: 305 manual addition, automated addition that is manually triggered, or 306 automated addition that is automatically triggered. Each of these 307 are discussed in more detail next. 309 Note that the term "association" or "addition" of an identity is used 310 rather than "provisioning" of an identity, because while we actually 311 are provisioning identities into the UI, provisioning is an 312 overloaded term in the identity and access management space and could 313 easily be confused with identity provisioning in the sense of the 314 creation of the identity by the home organisation's identity 315 management procedures. 317 6.2.1. Manual Addition 319 Allowing users to manually add an identity is technically the easiest 320 method to get this information, but it is a method that has the 321 greatest usability drawbacks. Most of the information required is 322 relatively technical and finding some way of explaining what each 323 field is to an non-technical audience is challenging (to say the 324 least). This especially is the case for trust anchor information. 325 Thus this method should be considered as a power-user option only, or 326 as a fall-back should the other methods not be applicable. 328 When this method is used, careful consideration should be given to 329 the UI presented to the user. The UI will have to ask for all of the 330 information detailed in Section 6.1. 332 There are two points at which a user could manually add an identity: 334 o Asynchronously: the user could be allowed to, at any time, trigger 335 a workflow of manually adding an identity. This represents the 336 most flexible way of adding an identity since a user can perform 337 this at any time. It does, however, have inherent issues when it 338 comes to verifying the newly added identity - see Section 6.4. 340 o Just In Time: when connecting to a service which has no mapping to 341 an existing identity, the user could be given an option to add a 342 new one, as well as associating with an existing one. This 343 presents a better user experience when it comes to verifying the 344 newly added identity (see Section 6.4), however, represents a less 345 direct method of adding an identity. Users who have not yet added 346 the appropriate identity to their identity selector may find it 347 difficult to understand that they must try to access a particular 348 service in order to add an identity. 350 Of course, implementers could support both styles of identity 351 addition to gain the benefits of both and give flexibility to the 352 user. 354 One item worthy of discussion here is the area of verification of 355 trust anchors. An Identity Selector SHOULD try to ensure that manual 356 addition of an identity and checking of the relevant trust anchors is 357 done as securely as possible, whereby users have to enter and confirm 358 all trust anchor information, or be required to explicitly agree to 359 an insecure configuration if this is not done properly. 361 6.2.2. Manually Triggered Automated Addition 363 One way to bypass the need for manual addition of a user's identity - 364 and all of the usability issues inherent with that approach - is to 365 provide some sort of manually triggered, but automated, provisioning 366 process. 368 One approach to accomplishing this, for example, could be for an 369 organisation to have a section on their website where their users 370 could visit, enter the user part of their NAI, and be given piece of 371 provisioning data that contains much or all of the relevant identity 372 information for importing into the identity selector. 374 It is reasonable to assume that any such provisioning service is 375 likely to be organisation specific, so that the Issuing Organisation 376 and realm part of the NAI will be constant, as would be the trust 377 anchor information. The user part of their NAI will have been input 378 on the web service. The password could be provided as a part of the 379 provisioning file or the identity selector could prompt the user to 380 enter it. 382 Additionally, the user SHOULD be given the opportunity to: 384 o Supply or change the default friendly name for that identity - to 385 allow the user to customise the identifier they use for that 386 identity; 388 o Indicate whether or not the identity selector should always ask 389 before using services with this identity - to customise the way in 390 which the identity selector interacts with the user with this 391 particular identity; 393 o Reject the addition of the identity completely - to allow the user 394 to back out of the association process in an intuitive way. 396 In this case, trust anchors could be directly provided through the 397 provisioning mechanism to help establish the trust relationship in a 398 secure manner. 400 6.2.3. Fully Automated Addition 402 Many organisations manage the machines of their users using 403 enterprise management tools. Such organisations may wish to be able 404 to automatically add a particular user's identity to the identity 405 selector on their machine/network account so that the user has to do 406 nothing. 408 This represents the best usability for the user - who wouldn't 409 actually have to do anything. However, it can only work on machines 410 centrally managed by the organisation. 412 Additionally, having an identity automatically provided, including 413 its password, does have some particular usability issues. Users are 414 used to having to provide their username and password to access 415 services. When attempting to access services, authenticating to them 416 completely transparently to the user could represent a source of 417 confusion. User training within an organisation to explain that 418 automated provisioning of their identity has been enabled is the only 419 way to counter this. 421 6.3. Modifying Identity Information 423 This process is conceptually fairly similar to adding an identity, 424 and thus shares many of the usability issues with that process. Some 425 particular things are discussed here. 427 6.3.1. Manual Modification 429 An identity selector may allow a user to manually modify some or all 430 of the information associated with each identity. The obvious item 431 that MUST be allowed to be changed by the user is the password 432 associated with the identity. 434 6.3.2. Automated Modification 436 To ease usability, organisations may wish to automatically provide 437 updates to identity information. For example, if the user's password 438 changes, it could automatically update the password for the identity 439 in the user's identity selector. 441 6.4. Verifying an identity 443 An inherent by-product of the ABFAB architecture is that an identity 444 cannot be verified during the addition process; it can only be 445 verified while it is in use with a real service. This represents a 446 definite usability issue no matter which method of identity addition 447 is used (see Section 6.2): 449 o If the user has manually added the identity (see Section 6.2) they 450 may have gone through the whole manual process with no errors and 451 so believe the identity has been set up correctly. However, when 452 they attempt to access a service, they may be given an error 453 message, thus causing some amount of confusion. 455 o If the user has had the identity provisioned into their identity 456 selector, then there is a much greater chance of the identity 457 information being correct. However, if any of the information is 458 not correct, then there is the potential for confusion as the user 459 did not add the information in the first place. 461 Also, if the identity information is incorrect the user may not know 462 where the error lies, and the error messages provided by the 463 mechanism may not be helpful enough to indicate the error and how to 464 fix it (see Section 8). 466 6.5. Removing an Identity 468 This is fairly similar to adding or modifying an identity, and thus 469 shares many of the usability issues with those processes. Some 470 particular things are discussed here. 472 6.5.1. Manual Removal 474 Allowing the user to manually delete an identity is probably the best 475 way to achieve the goal. Any UI should allow for this option. 477 6.5.2. Automated Removal 479 While automated removal of an identity is a way of achieving the goal 480 without having to interact with the user, the consequence is that 481 things may disappear from the user's identity selector without them 482 realising. 484 7. Considerations around Management of Service to Identity Mappings 486 A service to identity mapping tell the identity selector which 487 identity should be used for a particular service. There is 488 potentially a many-to-many association between identities and 489 services since a user may wish to use one of their identities for 490 many services, or more than one identity for a single service (e.g. 491 if they have multiple roles on that service). 493 This potentially complex many-to-many association between is not 494 easily comprehended by the user, and allowing the user to both 495 manipulate it and control can be challenging. These obstacles are 496 especially common when errors occur after an association has been 497 made. In this scenario it is important that an identity can be 498 disassociated with a service. 500 7.1. Listing Services and Identities 502 A service listing should be considered in the identity selector which 503 is both searchable and editable by the user. 505 7.2. Showing the Identity currently in use 507 It would be beneficial if, when using a service, the identity 508 currently in use could be made visible to the user while he/she is 509 using a specific service. This allows the user to identify which the 510 identity is used with a particular service at a particular time (the 511 user may have more than one identity that they could use with a 512 particular service) - so that they can then disassociate the pairing. 514 7.3. Associating a Service with an Identity 516 There needs to be a way for the user to create the service to 517 identity association. It is advisable that this link be made only 518 after the identity in question has authenticated with the service 519 without any error. 521 There are a few ways this association could happen. 523 7.3.1. User-driven Manual Association 525 There are two ways in which manual association of an identity to a 526 service could happen: 528 1. The user could manually associate a particular service with a 529 particular identity using the identity selector before they first 530 attempt to use the service. In order to do so, however, the user 531 would need to know all the required technical details of that 532 service beforehand, such as its GSS Acceptor Name. 534 2. On encountering a service new to the identity selector, the 535 identity selector could pop up a dialogue box to the user asking 536 if they would like to use an existing identity for this service 537 (and might also allow them to create a new identity and use 538 that). 540 7.3.2. Automated Rules-based Association 542 It would be beneficial from a usability perspective to minimise - or 543 avoid entirely - situations where the user has to pick an identity 544 for a particular service. This could be accomplished by having rules 545 to describe services and their mapping to identities. Such a rule 546 could match, for example, a particular identity for all IMAP servers, 547 or a particular identity for all services in a given service realm. 548 These rules could be configured as a part of the automated identity 549 addition process described in Section 6.2.2 or Section 6.2.3 551 7.4. Disassociating a Service with an Identity 553 A user MUST be able to disassociate an identity with a service - that 554 is, to be able to remove the mapping without having to remove the 555 identity. 557 There should also be provision for the automated disassociation of an 558 identity with a service for appropriate types of authentication 559 failures. 561 8. Handling of Errors 563 All GSS-API calls need to be instantiated from the application. For 564 this reason when an error occurs the user needs to be sent back to 565 the application to re-initiate the GSS-API call. This can get 566 tedious and cause the user to opt out of what they are trying to 567 accomplish. In addition to this the error messages themselves may 568 not be useful enough for the user to decipher what has gone wrong. 570 It is important to try and avoid error cases all together while using 571 GSS-API as error messages and error handling can really effect 572 usability. Another solution would be to alter the application to 573 handle the errors as it is instantiating the GSS-API communication. 575 TODO: Lots more to discuss here... 577 8.1. Identity Association/Verification Errors 579 TODO: e.g. wrong password, bad trust anchors, etc. TODO. 581 8.2. Service Errors 583 TODO: e.g. identity is correct but no authorisation. TODO. 585 8.3. Other Errors. 587 TODO: e.g. network errors. TODO. 589 9. Handling of Successes 591 It is of course hoped that the identity selector will have to 592 occasionally handle successes as well as errors. This section has 593 some brief discussion about some areas you might want to think about. 595 9.1. Reporting Authentication Success on First Use of Identity 597 The first time an identity is used with a service, it would be good 598 practice to visually indicate in some way that the process has been 599 successful, in order that the user understands what is happening and 600 is then prepared for future authentication attempts. 602 9.2. Reporting Authentication Success 604 On an on-going basis you may or may not wish to indicate visually to 605 the user a successful authentication to a service. This relates to 606 Section 7.2. 608 10. Other Considerations 610 This section briefly discusses other considerations that you might 611 want to think about that don't fit in any of the other categories. 613 10.1. Import/Export of Credentials 615 For various reasons, an identity selector implementation might want 616 to include functionality that allows for the export/import of 617 identities and service to identity mappings. This could be for 618 backup purposes, to allow a degree of mobility between identity 619 selector instances, etc. 621 If providing this functionality, it would be advisable that the 622 credential store that is the result of the export should be secure - 623 encrypted and password protected - given the nature of the 624 information. 626 11. Contributors 628 The following individuals made important contributions to the text of 629 this document: Sam Hartman (Painless Security LLC), and Maria Turk 630 (Codethink Ltd). 632 12. Acknowledgements 634 Jim, Stefan. 636 13. Security Considerations 638 TODO 640 14. IANA Considerations 642 This document does not require actions by IANA. 644 15. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 650 Network Access Identifier", RFC 4282, December 2005. 652 Appendix A. Change Log 654 Note to RFC Editor: if this document does not obsolete an existing 655 RFC, please remove this appendix before publication as an RFC. 657 Draft -03 to draft -04 659 1. Addressing various comments from Jim and Stefan. 661 Draft -02 to draft -03 663 1. Bumping version to keep it alive. 665 Draft -01 to draft -02 667 1. Completed the major consideration sections, lots of rewording 668 throughout. 670 Draft -00 to draft -01 672 1. None, republishing to refresh the document. Other than adding 673 this comment... 675 Appendix B. Open Issues 677 Note to RFC Editor: please remove this appendix before publication as 678 an RFC. 680 Author's Address 682 Dr. Rhys Smith 683 Cardiff University 684 39-41 Park Place 685 Cardiff CF10 3BB 686 United Kingdom 688 Phone: +44 29 2087 0126 689 EMail: smith@cardiff.ac.uk