idnits 2.17.1 draft-poehn-dame-06.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 (June 28, 2016) is 2859 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-20) exists of draft-young-md-query-05 == Outdated reference: A later version (-20) exists of draft-young-md-query-saml-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Poehn 3 Internet-Draft S. Metzger 4 Intended status: Informational Leibniz Supercomputing Centre 5 Expires: December 30, 2016 W. Hommel 6 M. Grabatin 7 Universitaet der Bundeswehr Muenchen 8 June 28, 2016 10 Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web 11 Browser SSO Profile 12 draft-poehn-dame-06 14 Abstract 16 This document specifies the integration of Dynamic Automated Metadata 17 Exchange (DAME) through an intermediate trusted third party into the 18 Security Assertion Markup Language (SAML) 2.0 Web Browser SSO 19 Profile. The user-triggered, on-demand, and fully automated metadata 20 exchange between identity provider (IDP) and service provider (SP) is 21 intended for scenarios in which the a-priori, e.g., federation-based 22 exchange of SAML metadata is neither practical, scalable nor 23 mandatory for non-technical aspects, such as contract-based trust 24 building between IDP and SP. The main benefit of DAME is the removal 25 of waiting times for users and manual setup tasks for IDP and SP 26 administrators before users can access the service. Implementations 27 of DAME can leverage existing metadata repositories, such as REEP, 28 and metadata transfer protocols, such as MD Query. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 30, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. SAML Profiles and Bindings . . . . . . . . . . . . . . . . . 4 68 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Authentication Request Protocol using a TTP . . . . . . . 7 72 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 11 74 4.2. Authentication Request Protocol using a TTP . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 5.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 78 5.3. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 14 79 5.4. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 8.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 In a federated identity management scenario, enabling communication 90 between an identity provider and a service provider is possible 91 within trust boundaries, which typically entails joining one or 92 several federations before the exchange of metadata takes place. The 93 exchange of SAML metadata is out of scope of the SAML specifications, 94 but normally done by pre-sharing metadata files of all entities 95 within the trust boundaries. 97 This document specifies the HTTP-based [RFC7230] integration of SAML 98 metadata exchange into the SAML2 Web Browser SSO 99 [OASIS.saml-profiles-2.0-os] profile. Focusing on the automation and 100 the on-demand initiation of the metadata exchange between an identity 101 provider and a service provider to build a form of opportunistic 102 trust, even if these do not share membership in a common federation 103 a-priori or if regular federation scenarios are not suitable. This 104 could be the case in projects containing partners outside regular 105 federations. The initiation of the metadata exchange starts after 106 the identity provider discovery in order to keep the user experience 107 consistent with traditional federation-based service access. 109 This document specifies the initiation of the metadata exchange but 110 does not anticipate the use of either a public metadata registry or 111 the metadata query itself. The metadata exchange is triggered by a 112 trusted third party, which does not interfere in further 113 communication once identity provider and service provider have 114 successfully exchanged their metadata. In contrast to identity 115 provider proxies, the trusted third party does not cache assertions 116 nor is it involved in subsequent communication. Integrated identity 117 provider discovery, the mutual exchange of required SAML metadata, 118 and user authentication take place in a fully automated, user- 119 initiated, and on-demand manner. To provide a flexible solution, 120 either pull-based metadata exchange, such as the SAML Profile for MD 121 Query [I-D.young-md-query-saml], or any kind of push mechanism can be 122 used. 124 The degree of integration chosen for DAME explicitly does not imply 125 that disclosing personally identifiable information is required from 126 an identity provider by sending it to any particular service 127 provider. This is left to appropriate means, e.g., explicitly 128 acquiring user consent, in compliance with regulations and policies. 130 The described integration addresses the protocol, content and 131 processing of SAML messages for interoperability, referring to 132 [SAML2Int], but also specifies some deployment details and phases for 133 cross-boundary trust. Fitting in seamlessly with implemented SAML- 134 based SSO workflows and being scalable for a large number of users 135 and entities without exceeding administrative procedures, it enables 136 to participate in dynamically set up federations. 138 1.1. Notation and Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 1.2. Terminology 146 This document uses identity management terminology from [RFC6973] and 147 [OASIS.saml-glossary-2.0-os]. In particular, this document uses the 148 terms identity provider, service provider and identity management. 149 Furthermore, it uses following terminology: 151 Entity - A single logical construct for which metadata is provided. 152 This is usually either a service provider (SP) or an identity 153 provider (IDP). 155 Metadata - The SAML metadata specification is a machine-readable 156 description of certain entity characteristics and contains 157 information about, e.g., identifiers, endpoints, certificates and 158 keys. 160 Trusted Third Party - An intermediate entity facilitating interaction 161 between different entities, which trust the third party (TTP). 163 2. SAML Profiles and Bindings 165 Based on [OASIS.saml-profiles-2.0-os], SAML profiles define rules how 166 to embed SAML assertions in or combine them with other objects as 167 files or protocol data units of communication protocols. The profile 168 defined in this document is based on the existing SAML Web Browser 169 SSO profile, which implements the SAML Authentication Request 170 protocol [OASIS.saml-core-2.0-os] enhanced by a trusted entity 171 between an originating party (IDP) and a receiving party (SP). 173 A SAML binding [OASIS.saml-bindings-2.0-os] maps request-response 174 messages of the SAML protocol onto standard communication protocols. 175 For compliance reasons with the underlying Web Browser SSO profile, 176 the SAML HTTP Redirect and HTTP POST Bindings MUST be used. 178 SAML metadata information MUST be extended to support this protocol. 179 For each entity a MetadataSyncLocation MUST be defined, e.g., for an 180 IDP idp.example.net. To ensure conformity and uniqueness of the 181 attribute the URN namespace for GEANT [RFC4926] MUST be used: 183 184 185 186 https://idp.example.net/idp/profile/SAML2/DAME 187 188 189 191 3. Protocol 193 The protocol defined in this document MUST be divided into two 194 phases: 196 o Discovery of the appropriate IDP 198 o User authentication on behalf of the SP through a TTP 200 A. User authentication to TTP 202 B. On-demand metadata exchange 204 C. User authentication to SP 206 The protocol defined in this document primarily adds the on-demand 207 metadata exchange between IDP and SP, which is triggered by the user. 208 The exchange of the metadata itself is explicitly out of scope. The 209 authentication to the TTP step in the latter phase is required due to 210 the security considerations discussed below. 212 3.1. Identifier 214 entityID - Specifies the unique identity of an entity, whose metadata 215 is exchanged, as specified in [OASIS.saml-metadata-2.0-os] and 216 [OASIS.saml-idp-discovery]. 218 3.2. IDP Discovery 220 A web user attempts to access a secured resource provided by a SP via 221 an HTTP user agent. Missing an established technical trust 222 relationship, a certain IDP MUST be discovered by the discovery 223 functionality that is integrated into or accessible via the TTP. 225 User agent SP TTP 226 | | | 227 |----HTTP Request--->| | 228 | | | 229 |---HTTP Redirect----| | 230 | | | 231 |--------------------------HTTP Request----->| 232 | | | 233 |<------Selection of identity provider ----->| 234 | | | 235 |--------------------------HTTP Redirect-----| 236 | | | 237 |---HTTP Request---->| | 238 | | | 240 Figure 1: Identity provider discovery. 242 3.2.1. Redirect to trusted third party 244 Analogous to the SAML identity provider discovery profile 245 [OASIS.saml-idp-discovery], the SP redirects the user agent to the 246 TTP with an HTTP GET request including the REQUIRED or OPTIONAL 247 parameters specified in [OASIS.saml-idp-discovery]. 249 In distinction to the existing discovery profile, the OPTIONAL 250 "isPassive" parameter, which controls the visible interaction with 251 the user agent, SHOULD NOT be set to "true" in this profile. If the 252 parameter "isPassive" is used, the request sent to the TTP MUST 253 contain the entityID of the IDP as a URL query. The URL query is 254 indicated by the '?' operator, followed by variable name entityID, 255 '=', and the variable's value [RFC3986]. This template provides both 256 a structural description and machine-readable instructions. 258 The URLs of the participating entities MUST be known to the TTP 259 through the metadata. The URLs depend on the implementation and MAY 260 include the literal string "DAME" as query [RFC3986], indicating the 261 usage of this profile for dynamic automated metadata exchange. 263 3.2.2. Response to service provider 265 The TTP MUST respond by redirecting the user agent back to the 266 requesting SP with an HTTP GET request message to the location 267 specified in the return parameter of the original request. The 268 unique identifier of the selected IDP MUST be included as value of 269 the query string parameter specified as returnIDParam or the entityID 270 if no parameter was supplied. 272 3.2.3. Failure processing 274 If the IDP was not determined or the discovery service cannot answer 275 or an unspecified communication error occurs, the discovery service 276 MAY halt further processing, either displaying an error message to 277 the user agent or redirecting the user agent back to the SP. 279 3.2.4. Further actions 281 After receiving the information about the selected IDP it is 282 RECOMMENDED that the SP verifies acceptance. If the IDP has not been 283 accepted, the SP halts processing and displays an error message to 284 the user agent. 286 3.3. Authentication Request Protocol using a TTP 288 In the second phase of the protocol user authentication MUST be 289 performed. The trusted third party relays the SP's authentication 290 request to the IDP. For this step, the authentication request of the 291 SP is cached and a new authentication request is sent to the IDP as 292 both entities do not have previously exchanged their metadata. These 293 authentication requests are REQUIRED to ensure that a metadata 294 exchange will be initiated only if the user has successfully been 295 authenticated by the selected IDP. 297 User agent SP TTP IDP 298 | | | | 299 |--HTTP Redirect-| | | 300 | | | | 301 |-----------AuthRequest1------------>| | 302 | | | | 303 |--------------------HTTP Redirect---| | 304 | | | | 305 |----------------------------------------AuthRequest2--->| 306 | | | | 307 |<-----------------User authentication------------------>| 308 | | | | 309 | | |<---AuthResponse2--| 310 | | | | 311 | | |----MDI Request--->| 312 | | | | 313 | | |<---MDI Response---| 314 | | | | 315 | |<----MDI Request---| | 316 | | | | 317 | |---MDI Response--->| | 318 | | | | 319 |--------------------HTTP Redirect---| | 320 | | | | 321 |----------------------------------------AuthRequest1--->| 322 | | | | 323 | |<-----------AuthResponse1--------------| 324 | | | | 325 |<-HTTP Response-| | | 326 | | | | 328 Figure 2: User authentication Request Protocol using a TTP. 330 3.3.1. User authentication to trusted third party 332 In the first sub-phase the user MUST be authenticated by the selected 333 identity provider, but in distinction to [OASIS.saml-idp-discovery], 334 the trusted third party initiates the authentication. 336 3.3.1.1. Authentication Request of SP to TTP 338 After accepting the selected IDP, the SP creates and sends a SAML 339 Authentication Request message (AuthnRequest) to the TTP using an 340 HTTP Redirect to transfer the message through the user agent. It is 341 RECOMMENDED that this request message is signed or otherwise 342 authenticated and integrity-protected by the requesting SP. 344 3.3.1.2. Store AuthnRequest at TTP 346 The TTP MUST temporarily store the SAML AuthnRequest message by means 347 out of scope of this specification. 349 3.3.1.3. Authentication Request of TTP to IDP 351 After that, a second SAML AuthnRequest message MUST be sent by the 352 trusted third party to the selected IDP using a HTTP redirect message 353 to authenticate the user. The OPTIONAL "ForceAuthn" 354 [OASIS.saml-core-2.0-os] parameter MAY be included in the request. 355 The AuthnRequest message SHOULD be signed or otherwise authenticated 356 and integrity protected by the TTP or by the protocol binding used to 357 deliver the message. 359 3.3.1.4. User authentication 361 The user MUST be identified and authenticated by the IDP by some 362 means out of scope of this profile. A new authentication SHOULD be 363 performed unless the IDP can rely on a previously authenticated 364 session. A previous session MUST NOT be reused if the request 365 contains a "ForceAuthn" parameter. 367 3.3.1.5. Authentication Response to TTP 369 The IDP MUST issue a SAML AuthnResponse message to the TTP containing 370 one or more assertions or an error message with a status describing 371 the error occurred. The HTTP POST binding MUST be used to transfer 372 the message. It is RECOMMENDED that the message is signed by the IDP 373 or otherwise authenticated or integrity-protected. 375 3.3.2. Metadata Exchange orchestrated by TTP 377 In the second sub-phase, the metadata of SP and IDP are exchanged in 378 a way that is orchestrated and synchronized by the TTP. 380 3.3.2.1. MDI Request 382 After the user has been authenticated, the TTP MUST initiate the 383 metadata integration (MDI) between IDP and SP by a metadata 384 integration request. The URL [RFC3986] sent to the entities for the 385 MDI request SHOULD contain the query elements {?action,entityID}. The 386 variable name 'action' MUST be followed by '=' and the variable's 387 value 'fetchmetadata'. The variable name 'entityID' is followed by 388 '=' and the variable's value. 390 The means used for the metadata exchange are implementation- 391 dependent. The TTP MAY trigger a metadata query as described by the 392 work in progress about the Metadata Query Protocol 393 [I-D.young-md-query] and the SAML Profile for the Metadata Query 394 Protocol [I-D.young-md-query-saml]. 396 IDP and SP MUST integrate each other's metadata in their 397 configuration. It is RECOMMENDED that the IDP is triggered regarding 398 metadata integration before the SP because it MAY object to accepting 399 certain service providers. But any kind of concurrent operation MAY 400 be supported. 402 It is RECOMMENDED that the TTP queries the IDP before the metadata 403 exchange because it MAY be the case that the IDP has already 404 integrated the SP's metadata. The IDP SHOULD then indicate the found 405 metadata by the appropriate HTTP status code according to 406 [I-D.young-md-query]. 408 3.3.2.2. MDI Response 410 After each other's metadata is integrated, each entity MUST send a 411 metadata integration response message to the TTP containing the 412 status of the integration by the HTTP status code. 414 If an entity was not able to integrate the metadata before sending 415 the response, the status MUST indicate this state and a new request 416 MUST be sent by the entity containing the status after the 417 integration. 419 If an error occurs integrating the metadata, the message MUST contain 420 a HTTP status code describing the error and the TTP MUST halt further 421 processing by displaying an error message to the user agent. It is 422 RECOMMENDED to roll back any configuration changes by some means out 423 of scope of this specification. 425 3.3.3. User authentication to service provider 427 In last step the stored AuthnRequest of the SP MUST be presented by 428 the TTP to the IDP if no error occurred beforehand. Because of the 429 successful user authentication already initiated by the trusted third 430 party, the IDP SHOULD respond with an assertion transferred to the 431 service provider without further act of authentication, except for 432 the case where the request contains a "ForceAuthn" parameter. 434 The IDP MUST issue a SAML AuthnResponse message to the services 435 provider's AssertionConsumerServiceURL. After receiving the 436 response, the SP MUST decide if the user gets access to the requested 437 resource based on the information contained within the SAML 438 assertion. 440 4. Example 442 Considering two organizations, SP S (sp.example.com) and identity 443 provider I (idp.example.net). User U initiates the SAML metadata 444 exchange between these entities using an user agent through the TTP T 445 (ttp.example.org). 447 4.1. IDP Discovery 449 After requesting access to a secured resource via HTTPS, S redirects 450 U to the discovery service of T: 452 GET /discovery/DAME?entityID=https%3A%2F%2Fsp.example.com%2FSSO 453 &return=https%3A%2F%2Fsp.example.com%2FSSO%2FTTP%3FSAMLDS%3D1 454 %26target%3Dtarget HTTP/1.x 455 Host: ttp.example.org 457 U selects an appropriate IDP I. T redirects U back to S using the 458 following message: 460 HTTP/1.x 302 Found 461 ... 462 Location: https://sp.example.com/SSO/DAME?SAMLDS=1&target=target 463 &entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp 465 GET /SSO/DAME?SAMLDS=1&target=target 466 &entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp 467 Host: sp.example.com 469 4.2. Authentication Request Protocol using a TTP 471 Receiving U's selection, S redirects the user to T containing a SAML 472 authentication request (AuthnRequest1): 474 HTTP/1.x 302 Found 475 ... 476 Location: 477 https://ttp.example.org/discovery/DAME?action=authenticate 478 &idpEntityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp 479 &SAMLRequest=fZHNTsMwEIRfJf..... 480 ... 482 GET /DAME?action=authenticate 483 &SAMLRequest=fZHNTsMwEIRfJf..... 484 &RelayState=target 485 Host: ttp.example.org 487 T temporarily stores the authentication request and redirects U to I 488 sending a second authentication request (AuthnRequest2) containing 489 the SAML request: 491 GET /idp/profile/SAML2/Redirect/SSO 492 ?SAMLRequest=lZLBbhshEIZfBXHfh..... HTTP/1.x 493 Host: idp.example.net 495 After successful authentication, I issues a SAML authentication 496 response message to T: 498 POST /SSO/SAML2/POST HTTP/1.x 499 POSTDATA 500 Referer:... 501 Set-Cookie:... 503 As U is successfully authenticated, I and S are triggered to fetch 504 each others metadata by T using the appropriate 505 TTPMetadataSyncLocation defined in the entity's SAML metadata, e.g., 506 /idp/profile/SAML2/DAME: 508 GET /idp/profile/SAML2/DAME?action=fetchmetadata 509 ?entityID=https%3A%2F%2Fsp.example.com%2FSSO HTTP/1.x 510 Host: idp.example.net 512 GET SSO/DAME?action=fetchmetadata 513 ?entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp 514 Host: sp.example.com 516 The entities download the metadata from T using, e.g., SAML Profile 517 for Metadata Query Protocol [I-D.young-md-query-saml]. Only I's 518 messages to download S's metadata are presented here, S's messages 519 are equivalent: 521 GET /metadataservice/entities/https%3A%2F%2Fsp.example.com%2F 522 SSO HTTP/1.x 523 Host: ttp.example.org 524 Accept: application/samlmetadata+xml 526 HTTP/1.x 200 OK 527 Content-Type: application/samlmetadata+xml 528 529 531 ... 533 T sends a request to I and S in order to receive the status of the 534 integration: 536 GET /metadataservice/DAME?action=add&status=status HTTP/1.x 538 I answeres with: 540 HTTP/1.x 200 OK 542 After successful completion T forwards S's authentication request to 543 I: 545 GET /idp/profile/SAML2/Redirect/SSO 546 ?SAMLRequest=fZHNTsMwEIRfJf..... 547 &RelayState=target HTTP/1.x 548 Host: idp.example.net 550 I answers to S's AssertionConsumerServiceURL with a SAML Response: 552 POST /SSO/SAML2/POST HTTP/1.x 553 POSTDATA 554 ... 556 Receiving the SAMLResponse, S redirects U to the requested resource: 558 HTTP/1.x 302 Found 559 ... 560 Location: sp.example.com/secure 561 ... 563 GET /secure HTTP/1.x 564 Cookie... 566 HTTP/1.x 200 OK 568 5. Security Considerations 570 5.1. Integrity 572 As SAML metadata contains information necessary for the secure 573 operation of interacting services, it is strongly RECOMMENDED that a 574 mechanism for integrity checking is provided to clients. This MAY 575 include the use of SSL/TLS at the transport layer, digital signatures 576 present within the metadata document, or any other such mechanism. 578 It is RECOMMENDED that the integrity checking mechanism provided by a 579 responder is a digital signature embedded in the returned metadata 580 document, as defined by [OASIS.saml-metadata-2.0-os] section 3: 582 - SHOULD use an RSA key pair whose modulus is no less than 2048 bits 583 in length. 585 - SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest 586 algorithm. 588 - MUST NOT use the MD5 cryptographic hash algorithm as a digest 589 algorithm. 591 - SHOULD otherwise follow current cryptographic best practices in 592 algorithm selection. 594 5.2. Confidentiality 596 In many cases service metadata is public information and therefore 597 confidentiality SHOULD NOT be required. In those cases, where such 598 functionality is required, it is RECOMMENDED that both the requester 599 and responder support SSL/TLS. Other mechanisms, such as XML 600 encryption, MAY also be supported for privacy concerns. 602 5.3. Inappropriate Usage 604 This protocol mandates the authentication of users before any trust 605 between SP and IDP is technically established. Although this 606 requires a further step for users, it protects against inappropriate 607 usage of the user-initiated trust establishment process. An example 608 of inappropriate usage is triggering the metadata exchange for an 609 IDP, where the user has no account. Therefore, the user MUST be 610 authenticated before the metadata is exchanged. 612 5.4. Trust 614 This protocol enables the user to trigger the SAML metadata exchange 615 between two entities and establish the bi-directional technical trust 616 relationship. This is a prerequisite of the subsequent exchange of 617 user information. 619 For entities, which require a higher level of trust, it is 620 RECOMMENDED to make use of one ore more additional mechanisms, e.g., 621 the usage of flags in metadata, implementation depending mechanisms 622 in order to secure sensitive information, or to take organizational 623 measures, such as requiring written contracts between SPs and IDPs. 625 6. IANA Considerations 627 This document has no actions for IANA. 629 7. Acknowledgements 631 The research leading to these results has received funding from the 632 European Community's Seventh Framework Programme under grant 633 agreement no 605243 (GN3plus). 635 8. References 637 8.1. Normative References 639 [OASIS.saml-bindings-2.0-os] 640 Cantor, S., "Bindings for the OASIS Security Assertion 641 Markup Language (SAML) V2.0", March 2005. 643 [OASIS.saml-core-2.0-os] 644 Cantor, S., "Assertions and Protocols for the OASIS 645 Security Assertion Markup Language (SAML) V2.0", March 646 2005. 648 [OASIS.saml-idp-discovery] 649 Cantor, S., "Identity Provider Discovery Service Protocol 650 and Profile", March 2008. 652 [OASIS.saml-metadata-2.0-os] 653 Cantor, S., "Metadata for the OASIS Security Assertion 654 Markup Language (SAML) V2.0", March 2005. 656 [OASIS.saml-profiles-2.0-os] 657 Cantor, S., "Profiles for the OASIS Security Assertion 658 Markup Language (SAML) V2.0", March 2005. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", March 1997. 663 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 664 Resource Identifier (URI): Generic Syntax", January 2005. 666 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 667 (HTTP/1.1): Message Syntax and Routing", June 2014. 669 8.2. Informative References 671 [I-D.young-md-query] 672 Young, I., "Metadata Query Protocol, draft-young-md- 673 query-05 [work in progress]", April 2015. 675 [I-D.young-md-query-saml] 676 Young, I., "SAML Profile for Metadata Query Protocol, 677 draft-young-md-query-saml-05 [work in progress]", April 678 2015. 680 [OASIS.saml-glossary-2.0-os] 681 Hodges, J., "Glossary for the OASIS Security Assertion 682 Markup Language (SAML) V2.0", March 2005. 684 [RFC4926] Kalin, T. and M. Molina, "A URN Namespace for GEANT", July 685 2007. 687 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 688 Morris, J., Hansen, M., and R. Smith, "Privacy 689 Considerations for Internet Protocols", July 2013. 691 [SAML2Int] 692 Solberg, A., "Interoperable SAML2.0 Web Browser SSO 693 Deployment Profile". 695 Authors' Addresses 697 Daniela Poehn 698 Leibniz Supercomputing Centre 699 Boltzmannstrasse 1 700 Garching n. Munich, Bavaria 85748 701 Germany 703 Phone: +49 (0) 89 35831 8763 704 Email: poehn@lrz.de 706 Stefan Metzger 707 Leibniz Supercomputing Centre 708 Boltzmannstrasse 1 709 Garching n. Munich, Bavaria 85748 710 Germany 712 Phone: +49 (0) 89 35831 8846 713 Email: metzger@lrz.de 714 Wolfgang Hommel 715 Universitaet der Bundeswehr Muenchen, Computer Science Department 716 Werner-Heisenberg-Weg 39 717 Neubiberg, Bavaria 85577 718 Germany 720 Phone: +49 (0) 89 6004 2495 721 Email: wolfgang.hommel@unibw.de 723 Michael Grabatin 724 Universitaet der Bundeswehr Muenchen, Computer Science Department 725 Werner-Heisenberg-Weg 39 726 Neubiberg, Bavaria 85577 727 Germany 729 Phone: +49 (0) 89 6004 3992 730 Email: michael.grabatin@unibw.de