idnits 2.17.1 draft-howlett-abfab-trust-router-ps-03.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 11, 2013) is 4058 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB J. Howlett 3 Internet-Draft R. Smith 4 Intended status: Informational Janet 5 Expires: September 12, 2013 M. Wasserman 6 Painless Security 7 March 11, 2013 9 Trust Requirements in a Federated World 10 draft-howlett-abfab-trust-router-ps-03 12 Abstract 14 TODO: This document outlines the requirements for trust in a 15 federated environment, and enumerates the requirements for a trust 16 infrastructure. It also examines existing trust infrastructures 17 given these requirements and concludes that none fulfil all of the 18 requirements, and suggests that maybe a new one is required that 19 does. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 12, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. What is Trust? . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Communities of Trust . . . . . . . . . . . . . . . . . . . 5 60 3.3. Authentication Policy Communities vs Communities of 61 Interest . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Trust in a federated environment . . . . . . . . . . . . . 8 63 4. Trust requirements in a federated world . . . . . . . . . . . 9 64 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 65 4.1.1. Identifying Partners . . . . . . . . . . . . . . . . . 9 66 4.1.2. Connecting to Partners . . . . . . . . . . . . . . . . 9 67 4.1.3. Clearly Delineate Registration from Usage . . . . . . 9 68 4.2. Specific Requirements . . . . . . . . . . . . . . . . . . 10 69 4.2.1. Many IdPs, Many RPs . . . . . . . . . . . . . . . . . 10 70 4.2.2. Frequent changes in Community Membership . . . . . . . 10 71 4.2.3. Costs incurred by community that benefits . . . . . . 10 72 4.2.4. Minimal Costs/Effort for forming new communities 73 of Interest . . . . . . . . . . . . . . . . . . . . . 11 74 4.2.5. Flexible Communities . . . . . . . . . . . . . . . . . 11 75 4.2.6. Flexible Trust Links . . . . . . . . . . . . . . . . . 11 76 4.2.7. Multi-Role participation . . . . . . . . . . . . . . . 12 77 4.2.8. Multi-Purpose communities . . . . . . . . . . . . . . 12 78 5. Analysis of existing Trust infrastructures . . . . . . . . . . 12 79 5.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.2. PGP style web of trust . . . . . . . . . . . . . . . . . . 12 81 5.3. SAML Metadata . . . . . . . . . . . . . . . . . . . . . . 12 82 5.4. FreeRADIUS shared secrets . . . . . . . . . . . . . . . . 13 83 5.5. Other Things? . . . . . . . . . . . . . . . . . . . . . . 13 84 6. The Future of Trust . . . . . . . . . . . . . . . . . . . . . 13 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 Trust is a concept whose exact definition differs depending on the 96 exact scenario in which it is being applied, however, there is a 97 large degree of commonality about the meaning across all contexts - 98 the idea of "trust" usually centres around two entities (be they 99 people, organisations, or whatever) establishing confidence and faith 100 in the reliability, truth, or abilities of each other. 102 In the world of federated technologies, trust typically means exactly 103 that: two federated entities being able to establish confidence in 104 each other. What this means more specifically is that two entities 105 are able to verify that each other is who they think they are (i.e., 106 that it is not another entity pretending to be someone else), that 107 they represent the organisation they say they do (i.e. an entity 108 isn't misrepresenting themselves), and that transactions between the 109 two can be secure, unaltered, and verifiable. 111 This document examines the requirements of a trust infrastructure in 112 this context of the federated world. It then looks at existing trust 113 infrastructures, examining their pros and cons in relation to these 114 defined requirements. It then draws some conclusions about work 115 needed to bridge some missing gaps. 117 2. Terminology 119 This document uses existing terminology that the reader may not be 120 familiar with - and also introduces some new terminology - so a small 121 set of definitions is now included. 123 o Authentication Policy Community (APC): A set of entities that 124 share a common trust infrastructure and a common set of 125 identification requirements for the entities to be admitted to the 126 community. 128 o Community of Interest (CoI): A set of federation-capable entities 129 who want to interact with each other for a common purpose and with 130 a specific set of requirements. 132 o Entity: A general term for IdPs and RPs. 134 o Federation: An agreement between various entities that allows for 135 delegation of trust based a common set of semantics between an RP 136 and an IdP. 138 o Identity Provider (IdP): An entity that asserts identity 139 information about its principals to RPs. 141 o Principal (or Client): An individual (i.e. a real world person) or 142 a computer that is registered with an IdP and is attempting to get 143 service from an RP. 145 o Relying Party (RP): (a.k.a. Service Provider (SP)) The federated 146 entity representing an organisation that consumes identity 147 information about a principal asserted by an IdP in order to 148 provide a service to that principal. 150 o Trust Arbitrator: A central point of trust infrastructure that 151 gathers and passes on crowd-sourced trust recommendations about 152 members of its APC. The entities within the APC provide trust 153 recommendations to the arbitrator: the arbitrator does not make 154 trust recommendations on its won. The entities in the APC trust 155 that the Trust Arbitrator will ensure that recommendations from 156 the APC membership are correctly reflected in the trust rating 157 presented. 159 o Trust Advisor: A central point of trust infrastructure who 160 entities rely on it to (make trust recommendations about other 161 entities and?) trust decisions about who is admitted to a CoR 162 based on a set of advertised criteria. 164 o Web of Trust: A mechanism for extending trust between two 165 different trust infrastructures where an agreement exists that 166 each of the trust infrastructures can use the judgment of the 167 other infrastructure to make its own trust decisions. A Web of 168 Trust can be transitively extended across multiple trust 169 infrastructure. In other words, you and all your friends become 170 my friends. 172 3. Trust 174 3.1. What is Trust? 176 Trust is a word and a concept that can mean many things depending on 177 the context in which it is being discussed, and can encompass a wide 178 range of requirements. For example: 180 o In personal relationships, trust between two friends is usually a 181 mutually established relationship where each can rely on the other 182 for confidentiality and their help in times of need. 184 o In airline travel, trust between a consumer and an airline 185 provider is largely a one way relationship where the trust of the 186 airline by the consumer means the consumer expects the airline to 187 keep their aircraft well maintained, to get them to their 188 destination alive and (roughly) on time, and to (try) not to lose 189 their luggage. 191 o In e-commerce, trust between a consumer and a vendor is also 192 largely a one way relationship where the trust of a vendor by a 193 consumer means that the consumer considers the vendor to be likely 194 to provide good service, a reasonable price, and to fulfil their 195 order after it has been paid for. 197 Many such examples of trust exist in all walks of life and across 198 many contexts. Across most - if not all - of these, some 199 commonalities appear in the meaning of trust. Trust usually centres 200 around two entities being able to prove to each other who they are, 201 and then use that as a basis to transact in some form in a manner 202 that is confidential and secure. Indeed, the OED defines trust as 203 "Confidence in or reliance on some quality or attribute of a person 204 or thing, or the truth of a statement". 206 3.2. Communities of Trust 208 Trust, as defined above, is not something that just appears from 209 nowhere - it must be established somehow. The simplest way is, of 210 course, for two entities to build it bilaterally through a process of 211 slowly increasing the level of trust in each other through a series 212 of transactions over time. This process can be expedited, however, 213 through one of three commonly employed methods: 215 1. Trust can be established transitively through commonly trusted 216 3rd parties who have previously built up a level of trust with 217 each other (i.e. a web of trust, such as is seen in the PGP web 218 of trust) 220 2. Trust can be bootstrapped indirectly by a Trust Arbitrator - an 221 entity that is trusted by all who make use of it to appropriately 222 manage community provided reviews of trust (e.g., recommender 223 systems such as eBay member ratings) 225 3. Trust can be bootstrapped directly by a Trust Advisor - an entity 226 that is trusted by all who make use of it to appropriately manage 227 directly established trust relationships between it and its 228 community members (e.g., X509 Certificate Authorities). 230 In practice, each of these mechanisms can be, and are, used in 231 different contexts. They are typically deployed on a per-community 232 basis, such as the eBay community, a research and education SAML 233 federation, PGP users, web site deployers, etc. - because in a world 234 of billions of people and many millions of organisations, each of 235 whom is a member of many communities, finding a single entity, or a 236 small number of entities, that are commonly trusted by all to be a 237 Trust Arbitrator or a Trust Advisor is simply impossible. So, as a 238 way of tackling this scaling issue, "Communities of Trust" have 239 organically appeared in all three guises of expedited trust 240 establishment: sometimes in a decentralised way (e.g. PGP key 241 management through a web of trust), sometimes arbitrated by a Trust 242 Arbitrator (e.g. Trust management between sellers and buyers on 243 eBay), and sometimes by a Trust Advisor (e.g. X509 CAs, Twitter 244 "verified accounts", SAML federation metadata managed by the 245 federation operators, etc). 247 Within the world of computing, Trust Advisors are a typical way of 248 establishing trust, as it is essentially a method for people or 249 organisations to outsource the problem of trust establishment. 250 However, to achieve this, someone or something needs to set up and 251 manage the Trust Advisor, and users of it typically need to pay for 252 the service. Consequently, this method of solving the trust 253 establishment problem is largely used in business to business and 254 business to consumer communities. However, for those communities 255 where no financial transactions are involved, this method of trust 256 establishment is less appropriate as the community members do not 257 always want to - or are unable to - pay for the service. 259 Trust Arbitrators are less commonly seen, and are usually found where 260 a Trust Arbitrator stands to make financial gain through the use of 261 its services - either directly (e.g. members pay for its trust 262 recommendations) or indirectly (e.g. a chargeable service having more 263 members because of the increased trust these members can have in each 264 other). Again, this method may not be appropriate for those 265 communities where financial transactions are not involved. 267 The Web of Trust method of establishing trust is least seen of the 268 three methods, since while it is decentralised and appropriate for 269 any type of community, including those where no financial 270 transactions are taking place - transitive trust can be built up in a 271 way without paying for it - it is the hardest and most time consuming 272 way of establishing trust. 274 3.3. Authentication Policy Communities vs Communities of Interest 276 In those scenarios where Trust Arbitrators or Trust Advisors are the 277 methods of bootstrapping trust, two separate communities actually 278 exist. However, the two are often conflated as they are typically 279 equal, by accident of design. These two communities are: 281 o The Authentication Policy Communities: the set of entities who are 282 known to a trust infrastructure and for which the trust 283 infrastructure has a notion of trustworthiness. 285 o The Community of Interest: the set of entities who want to 286 interact with each for some particular purpose (e.g. to do B2C to 287 B2B transactions, to collaborate as part of a cross-organisational 288 project, to communicate securely, etc). 290 These two types of communities are often conflated because of the 291 lack of Trust Arbitrators or Trust Advisors that span multiple 292 communities of interest. This results in each community of interest 293 using a single (or small amount of) Trust Arbitrators or Trust 294 Advisors, thus the Authentication Policy Communities and Community of 295 Interest are one and the same. 297 In the real world, however, there are many cases where communities of 298 interest want to span multiple Authentication Policy Communities. 299 For example, SAML entities in the education sector who are part of 300 different Authentication Policy Communities (i.e. SAML Federations) 301 that are often geographically split (each country typically runs its 302 own SAML federation) often desire to communicate; [TODO other 303 examples]. 305 When entities from different communities of interest want to transact 306 in this way, trust has to be established across communities. This 307 can achieved in one of three ways: 309 1. Entities can join multiple communities, if the technology allows 310 this. 312 2. A Trust Bridge can be set up between Trust Arbitrators/Advisors 313 to allow entities from different Authentication Policy 314 Communities to communicate. 316 3. A Trust Arbitrators/Advisors can attempt to become the arbiter of 317 trust for multiple communities. 319 The first of these options is a rather inelegant way of solving the 320 problem, and will likely involve significant organisational effort 321 per community the entity joins, and is therefore not a particularly 322 scalable solution, and is therefore only a workable workaround in 323 limited circumstances. 325 The second option scales much better but requires significant effort 326 by the Trust Arbitrators/Advisors in ensuring that their rules of 327 registration are compatible. 329 The third option has significant drawbacks, however - either the 330 Trust Arbitrators/Advisors has to relax its rules so much to be 331 inclusive for a range of communities of interest that it becomes very 332 limited in the assurances it can offer, or it has to impose a set of 333 standards that many entities will not be willing to opt into due to 334 the high costs it imposes on them to meet these standards. 336 3.4. Trust in a federated environment 338 Given the general view of trust presented above, what does trust look 339 like more specifically in the federated world? 341 In a federated world, there are a few types of entities and trust 342 relationships, to whom trust each means slightly different things. 343 There is: 345 o Principal to IdP, IdP to principal. Trust here is mostly 346 organisational around an existing relationship between principal 347 and their IdP. The principal trusts the IdP to control its data 348 properly and to assert correct information about them. The IdP 349 trusts the principal to keep their credentials confidential so 350 that the IdP can authenticate the principal when required. 352 o Principal to RPs, RPs to principal. Trust here mostly flows 353 through guarantees between the principals and its IdP, and that 354 IdP and the RP, that allow the user to gain access to services 355 offered by the RP. 357 o IdP to RP. Trust here centres on the IdP and RP being able to 358 verify each other's identities, and often associate that 359 identification with an existing business relationship between the 360 organizations. 362 So in a federated world, there are actually two types of trust in 363 play. Firstly, there is technical trust (i.e., is the server I'm 364 talking to really the one I think it is, and are all communications 365 secured?); and secondly there is organisational or behavioural trust 366 (i.e., the trust that allows two entities to know for sure that that 367 the other entity represents a particular organisation that they have 368 a business relationship with, what guarantees are in place with each 369 other about their relationship, etc). 371 The second of these is a real world problem to be addressed and not a 372 technological issue and thus needs to be solved out of band. It 373 might, of course, have technical components to it (e.g. schema 374 definitions so the two understand the semantics of the data 375 transferred back and forth), but those would be part of the out of 376 band negotiation. 378 The first, however, is at the core of federation. The next section 379 looks in more detail at what federation needs from a trust framework 380 to properly establish technical trust. 382 4. Trust requirements in a federated world 384 The requirements of technical trust in a federated world largely 385 centre on entities being able to verify each others identity and 386 establish secure communications channels to allow for signing, 387 encryption, etc. To achieve this, various properties of the trust 388 infrastructure are required. Some of these requirements are 389 absolutely critical, while some are optional requirements to help 390 with scale. These are detailed next. 392 4.1. General Requirements 394 First of all, we will look at the main general requirements. 396 4.1.1. Identifying Partners 398 In most cases, it is necessary for organisations to have confidence 399 that the configuration that they have for their partners actually 400 corresponds to their partners and is not, for example, an attacker 401 claiming to be their partner. This is largely an issue of vetting 402 the claimed identity of organisations when they join a community. 404 An additional requirement here is that organisations need to minimise 405 the cost of validating their partners' identities, and of proving 406 their own identity to their partners. 408 4.1.2. Connecting to Partners 410 This is probably the most obvious requirement. Organisations must be 411 able to establish trust with each other through configuration, i.e., 412 servers representing a particular organisation must be configured to 413 be able to connect to servers representing partners of that 414 organisation in a secure verifiable manner. 416 To be able to connect, the configuration must include such things as 417 specifying the protocols to be used and the cryptographic operations 418 to be used. 420 Additionally, to be able to effectively connect to partners, 421 organisations must have effective tools for managing policies that 422 control the flow of information between the two partners. 424 4.1.3. Clearly Delineate Registration from Usage 426 As detailed earlier, the conflation of Authentication Policy 427 Communities vs Comunities of Interest hinders progress of large scale 428 adoption of federation and transitive trust establishment. 429 Conceptually splitting those two out gives many advantages, not the 430 least of which is the possibility of being able to better support 431 communities of interest that span multiple Authentication Policy 432 Communities. Authentication Policy Communities will provide the 433 technical trust, while Communities of Interest overlain upon one or 434 more Authentication Policy Communities can provide the behavioural 435 trust. 437 4.2. Specific Requirements 439 Alongside the general requirements presented above, there are some 440 more specific requirements. These are discussed next. 442 4.2.1. Many IdPs, Many RPs 444 Entities must be able to establish trust with an arbitrary number of 445 partners - scale should not be an issue. 447 4.2.2. Frequent changes in Community Membership 449 It must be possible to support changes in membership (adding new 450 partners, removing former partners, or changing the configuration of 451 partners) with minimal operational effort, and without requiring 452 manual configuration changes that could result in new partners having 453 delayed or incomplete access to services, or former partners 454 retaining some access to services beyond the end of their membership. 456 Additionally, organisations want to minimise the cost of managing 457 these frequent changes - there should be no requirement for 458 credential exchange between a large number of parties, no manual 459 configuration changes on a large number of systems, etc. 461 This is a requirement for both Authentication Policy Communities and 462 Communities of Interest, though the scale of changes is likely to be 463 different in the two. 465 4.2.3. Costs incurred by community that benefits 467 Typically in federation, the operational cost related to adding and 468 removing partners is born by the RPs, who need to maintain bilateral 469 credentials for each IdP whose users can access the services provided 470 by the RP. This is fine in a case where a single RP provides 471 services to a group of IdPs that pay for membership in the community, 472 or pay for access to specific services. 474 However, in a less-centralised partnership the costs of exchanging 475 credentials with each IdP could serve as a disincentive for 476 organisations to provide services to the community and/or result in 477 cases where an RP is unwilling or unable to incur the costs of 478 providing access to new partners. Therefore, if a trust framework 479 supported a mechanism where the operational costs are distributed to 480 the organisations that are receiving benefit from incurring the 481 costs, it would help drive adoption and usage. 483 4.2.4. Minimal Costs/Effort for forming new communities of Interest 485 To expand the use of federated services, it should be possible for a 486 group of potential partners to form a new Community of Interest with 487 minimal infrastructure and the lowest possible operational expense. 489 In order to minimise start-up costs, it should be possible to 490 leverage existing shared credentials and use those credentials for a 491 new Community of Interest. 493 Practically, this resolves to two problems: 495 o It must be possible to create a new Community of Interest that 496 uses credentials from one or more existing Authentication Policy 497 Communities. 499 o It must be possible for a partner to join multiple Communities of 500 Interest using a shared Authentication Policy Community, and for 501 different entities (such as users or servers) within a partner to 502 participate in different Communities of Interest. Practically, 503 this means that information about the Community of Interest in use 504 needs to be transmitted to an IdP, so it can be used as part the 505 authentication process. 507 4.2.5. Flexible Communities 509 It should be possible for Communities of Interest to grow to 510 encompass more partners, partners in different regions of the world, 511 or partners who have different Authentication Policy Communities 512 available to them. 514 It must, therefore, be possible for a single Community of Interest to 515 be serviced by multiple Authentication Policy Communities. While it 516 might be necessary for any given RP/IdP pair to share at least one 517 Authentication Policy Community, it should not be necessary for all 518 of the partners within a given Community of Interest to share a 519 single Authentication Policy Community. 521 4.2.6. Flexible Trust Links 523 Related to the above, it should be possible for Communities of 524 Interest that span multiple Authentication Policy Communities to be 525 able to support that transitive establishment of trust over these no 526 matter what technology is used for trust establishment in each 527 Authentication Policy Communities. This will help increase the 528 flexibility of communities. 530 4.2.7. Multi-Role participation 532 It must be possible for a single partner to participate as both an RP 533 and an IdP within a single community (either a Community of Interest 534 or a Authentication Policy Communities). 536 4.2.8. Multi-Purpose communities 538 It must be possible for a particular Community of Interest to be 539 equivalent in membership and configuration as an Authentication 540 Policy Community. A use case for this requirement would be an 541 Authentication Policy Community that provides services to its own 542 customers, perhaps for maintenance of their own Authentication Policy 543 Community membership. 545 5. Analysis of existing Trust infrastructures 547 TODO: Intro to this section. N.B. Much more detail needed, should be 548 a decent amount of analysis. Not a huge amount though - severa paras 549 per tech, perhaps. 551 5.1. PKIX 553 TODO: A trust advisor (or small set of trust advisors) in the form of 554 heirarchically signed X509 certs. Only Authentication Policy 555 Communities, not CoI. Costs incurred by the service, not the user. 556 Works well but only when governance and management is done properly. 557 Which it isn't, generally. Can devolve trust establishment a bit 558 with intermediate certs. 560 TODO: Not particularly suitable to federation in the real world as 561 existing X509 heirarchies are usually not run well enough, and 562 running one well enough is a significant cost. 564 5.2. PGP style web of trust 566 TODO: Web of trust style trust establishment, obviously. Works well 567 but not massively deployed because of the technology understanding 568 required of users to sign each others keys and whatnot. 570 5.3. SAML Metadata 572 TODO: Can use PKIX, or directly established public/private keys 573 through metadata, to establish trust. In the former case, all of 574 PKIX drawbacks. In the latter, needs a trust advisor controlling the 575 SAML metadata. Usually conflates APC with CoI (though entity 576 categories allow for CoI in a very limited sense). Doesn't scale 577 well because of it! Interfederation as a point solution to scaling 578 having to be designed. 580 5.4. FreeRADIUS shared secrets 582 TODO: 584 5.5. Other Things? 586 TODO: 588 6. The Future of Trust 590 TODO: Trust is something that needs engineering - trust frameworks 591 and systems are needed that fulfil all of the requirements stated if 592 we want a way of establishing trust between two artibrary federation 593 entities that cross arbitrarily large and diverse communities, and in 594 a way that empowers the actual users of the systems to make best use 595 of it all. No particular solution fulfils all of the requirements 596 above that are necessary for wide adoption of federation in a way 597 that is easy and cost effective for the communities using it. Any 598 new solution should consider all of these needs. 600 7. Acknowledgements 602 TODO: The document authors would like to thanks Jim Schaad and Klaas 603 Wierenga for providing review. 605 8. Security Considerations 607 TODO. 609 9. Privacy Considerations 611 TODO. 613 10. IANA Considerations 615 This document does not require actions by IANA. 617 11. References 618 11.1. Normative References 620 [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., 621 Hirsch, F., Mishra, P., Philpott, R., 622 and E. Maler, "Profiles for the OASIS 623 Security Assertion Markup Language 624 (SAML) V2.0", OASIS 625 Standard OASIS.saml-profiles-2.0-os, 626 March 2005. 628 11.2. Informative References 630 Authors' Addresses 632 Josh Howlett 633 Janet 634 Lumen House 635 Library Avenue 636 Harwell Oxford 637 Didcot OX11 0SG 638 United Kingdom 640 EMail: josh.howlett@ja.net 642 Dr. Rhys Smith 643 Janet 644 Lumen House 645 Library Avenue 646 Harwell Oxford 647 Didcot OX11 0SG 648 United Kingdom 650 EMail: rhys.smith@ja.net 652 Margaret Wasserman 653 Painless Security 654 356 Abbott Street 655 North Andover, MA 01845 656 USA 658 Phone: ++1 781 405 7464 659 EMail: mrw@painless-security.com