Network Working Group D. Poehn
Internet-Draft S. Metzger
Intended status: Informational Leibniz Supercomputing Centre
Expires: December 30, 2016 W. Hommel
M. Grabatin
Universitaet der Bundeswehr Muenchen
June 28, 2016
Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web
Browser SSO Profile
draft-poehn-dame-06
Abstract
This document specifies the integration of Dynamic Automated Metadata
Exchange (DAME) through an intermediate trusted third party into the
Security Assertion Markup Language (SAML) 2.0 Web Browser SSO
Profile. The user-triggered, on-demand, and fully automated metadata
exchange between identity provider (IDP) and service provider (SP) is
intended for scenarios in which the a-priori, e.g., federation-based
exchange of SAML metadata is neither practical, scalable nor
mandatory for non-technical aspects, such as contract-based trust
building between IDP and SP. The main benefit of DAME is the removal
of waiting times for users and manual setup tasks for IDP and SP
administrators before users can access the service. Implementations
of DAME can leverage existing metadata repositories, such as REEP,
and metadata transfer protocols, such as MD Query.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 30, 2016.
Poehn, et al. Expires December 30, 2016 [Page 1]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation and Conventions . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. SAML Profiles and Bindings . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Authentication Request Protocol using a TTP . . . . . . . 7
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Authentication Request Protocol using a TTP . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14
5.3. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 14
5.4. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
In a federated identity management scenario, enabling communication
between an identity provider and a service provider is possible
within trust boundaries, which typically entails joining one or
several federations before the exchange of metadata takes place. The
exchange of SAML metadata is out of scope of the SAML specifications,
Poehn, et al. Expires December 30, 2016 [Page 2]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
but normally done by pre-sharing metadata files of all entities
within the trust boundaries.
This document specifies the HTTP-based [RFC7230] integration of SAML
metadata exchange into the SAML2 Web Browser SSO
[OASIS.saml-profiles-2.0-os] profile. Focusing on the automation and
the on-demand initiation of the metadata exchange between an identity
provider and a service provider to build a form of opportunistic
trust, even if these do not share membership in a common federation
a-priori or if regular federation scenarios are not suitable. This
could be the case in projects containing partners outside regular
federations. The initiation of the metadata exchange starts after
the identity provider discovery in order to keep the user experience
consistent with traditional federation-based service access.
This document specifies the initiation of the metadata exchange but
does not anticipate the use of either a public metadata registry or
the metadata query itself. The metadata exchange is triggered by a
trusted third party, which does not interfere in further
communication once identity provider and service provider have
successfully exchanged their metadata. In contrast to identity
provider proxies, the trusted third party does not cache assertions
nor is it involved in subsequent communication. Integrated identity
provider discovery, the mutual exchange of required SAML metadata,
and user authentication take place in a fully automated, user-
initiated, and on-demand manner. To provide a flexible solution,
either pull-based metadata exchange, such as the SAML Profile for MD
Query [I-D.young-md-query-saml], or any kind of push mechanism can be
used.
The degree of integration chosen for DAME explicitly does not imply
that disclosing personally identifiable information is required from
an identity provider by sending it to any particular service
provider. This is left to appropriate means, e.g., explicitly
acquiring user consent, in compliance with regulations and policies.
The described integration addresses the protocol, content and
processing of SAML messages for interoperability, referring to
[SAML2Int], but also specifies some deployment details and phases for
cross-boundary trust. Fitting in seamlessly with implemented SAML-
based SSO workflows and being scalable for a large number of users
and entities without exceeding administrative procedures, it enables
to participate in dynamically set up federations.
Poehn, et al. Expires December 30, 2016 [Page 3]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
1.1. Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terminology
This document uses identity management terminology from [RFC6973] and
[OASIS.saml-glossary-2.0-os]. In particular, this document uses the
terms identity provider, service provider and identity management.
Furthermore, it uses following terminology:
Entity - A single logical construct for which metadata is provided.
This is usually either a service provider (SP) or an identity
provider (IDP).
Metadata - The SAML metadata specification is a machine-readable
description of certain entity characteristics and contains
information about, e.g., identifiers, endpoints, certificates and
keys.
Trusted Third Party - An intermediate entity facilitating interaction
between different entities, which trust the third party (TTP).
2. SAML Profiles and Bindings
Based on [OASIS.saml-profiles-2.0-os], SAML profiles define rules how
to embed SAML assertions in or combine them with other objects as
files or protocol data units of communication protocols. The profile
defined in this document is based on the existing SAML Web Browser
SSO profile, which implements the SAML Authentication Request
protocol [OASIS.saml-core-2.0-os] enhanced by a trusted entity
between an originating party (IDP) and a receiving party (SP).
A SAML binding [OASIS.saml-bindings-2.0-os] maps request-response
messages of the SAML protocol onto standard communication protocols.
For compliance reasons with the underlying Web Browser SSO profile,
the SAML HTTP Redirect and HTTP POST Bindings MUST be used.
SAML metadata information MUST be extended to support this protocol.
For each entity a MetadataSyncLocation MUST be defined, e.g., for an
IDP idp.example.net. To ensure conformity and uniqueness of the
attribute the URN namespace for GEANT [RFC4926] MUST be used:
Poehn, et al. Expires December 30, 2016 [Page 4]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
https://idp.example.net/idp/profile/SAML2/DAME
3. Protocol
The protocol defined in this document MUST be divided into two
phases:
o Discovery of the appropriate IDP
o User authentication on behalf of the SP through a TTP
A. User authentication to TTP
B. On-demand metadata exchange
C. User authentication to SP
The protocol defined in this document primarily adds the on-demand
metadata exchange between IDP and SP, which is triggered by the user.
The exchange of the metadata itself is explicitly out of scope. The
authentication to the TTP step in the latter phase is required due to
the security considerations discussed below.
3.1. Identifier
entityID - Specifies the unique identity of an entity, whose metadata
is exchanged, as specified in [OASIS.saml-metadata-2.0-os] and
[OASIS.saml-idp-discovery].
3.2. IDP Discovery
A web user attempts to access a secured resource provided by a SP via
an HTTP user agent. Missing an established technical trust
relationship, a certain IDP MUST be discovered by the discovery
functionality that is integrated into or accessible via the TTP.
Poehn, et al. Expires December 30, 2016 [Page 5]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
User agent SP TTP
| | |
|----HTTP Request--->| |
| | |
|---HTTP Redirect----| |
| | |
|--------------------------HTTP Request----->|
| | |
|<------Selection of identity provider ----->|
| | |
|--------------------------HTTP Redirect-----|
| | |
|---HTTP Request---->| |
| | |
Figure 1: Identity provider discovery.
3.2.1. Redirect to trusted third party
Analogous to the SAML identity provider discovery profile
[OASIS.saml-idp-discovery], the SP redirects the user agent to the
TTP with an HTTP GET request including the REQUIRED or OPTIONAL
parameters specified in [OASIS.saml-idp-discovery].
In distinction to the existing discovery profile, the OPTIONAL
"isPassive" parameter, which controls the visible interaction with
the user agent, SHOULD NOT be set to "true" in this profile. If the
parameter "isPassive" is used, the request sent to the TTP MUST
contain the entityID of the IDP as a URL query. The URL query is
indicated by the '?' operator, followed by variable name entityID,
'=', and the variable's value [RFC3986]. This template provides both
a structural description and machine-readable instructions.
The URLs of the participating entities MUST be known to the TTP
through the metadata. The URLs depend on the implementation and MAY
include the literal string "DAME" as query [RFC3986], indicating the
usage of this profile for dynamic automated metadata exchange.
3.2.2. Response to service provider
The TTP MUST respond by redirecting the user agent back to the
requesting SP with an HTTP GET request message to the location
specified in the return parameter of the original request. The
unique identifier of the selected IDP MUST be included as value of
the query string parameter specified as returnIDParam or the entityID
if no parameter was supplied.
Poehn, et al. Expires December 30, 2016 [Page 6]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
3.2.3. Failure processing
If the IDP was not determined or the discovery service cannot answer
or an unspecified communication error occurs, the discovery service
MAY halt further processing, either displaying an error message to
the user agent or redirecting the user agent back to the SP.
3.2.4. Further actions
After receiving the information about the selected IDP it is
RECOMMENDED that the SP verifies acceptance. If the IDP has not been
accepted, the SP halts processing and displays an error message to
the user agent.
3.3. Authentication Request Protocol using a TTP
In the second phase of the protocol user authentication MUST be
performed. The trusted third party relays the SP's authentication
request to the IDP. For this step, the authentication request of the
SP is cached and a new authentication request is sent to the IDP as
both entities do not have previously exchanged their metadata. These
authentication requests are REQUIRED to ensure that a metadata
exchange will be initiated only if the user has successfully been
authenticated by the selected IDP.
Poehn, et al. Expires December 30, 2016 [Page 7]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
User agent SP TTP IDP
| | | |
|--HTTP Redirect-| | |
| | | |
|-----------AuthRequest1------------>| |
| | | |
|--------------------HTTP Redirect---| |
| | | |
|----------------------------------------AuthRequest2--->|
| | | |
|<-----------------User authentication------------------>|
| | | |
| | |<---AuthResponse2--|
| | | |
| | |----MDI Request--->|
| | | |
| | |<---MDI Response---|
| | | |
| |<----MDI Request---| |
| | | |
| |---MDI Response--->| |
| | | |
|--------------------HTTP Redirect---| |
| | | |
|----------------------------------------AuthRequest1--->|
| | | |
| |<-----------AuthResponse1--------------|
| | | |
|<-HTTP Response-| | |
| | | |
Figure 2: User authentication Request Protocol using a TTP.
3.3.1. User authentication to trusted third party
In the first sub-phase the user MUST be authenticated by the selected
identity provider, but in distinction to [OASIS.saml-idp-discovery],
the trusted third party initiates the authentication.
3.3.1.1. Authentication Request of SP to TTP
After accepting the selected IDP, the SP creates and sends a SAML
Authentication Request message (AuthnRequest) to the TTP using an
HTTP Redirect to transfer the message through the user agent. It is
RECOMMENDED that this request message is signed or otherwise
authenticated and integrity-protected by the requesting SP.
Poehn, et al. Expires December 30, 2016 [Page 8]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
3.3.1.2. Store AuthnRequest at TTP
The TTP MUST temporarily store the SAML AuthnRequest message by means
out of scope of this specification.
3.3.1.3. Authentication Request of TTP to IDP
After that, a second SAML AuthnRequest message MUST be sent by the
trusted third party to the selected IDP using a HTTP redirect message
to authenticate the user. The OPTIONAL "ForceAuthn"
[OASIS.saml-core-2.0-os] parameter MAY be included in the request.
The AuthnRequest message SHOULD be signed or otherwise authenticated
and integrity protected by the TTP or by the protocol binding used to
deliver the message.
3.3.1.4. User authentication
The user MUST be identified and authenticated by the IDP by some
means out of scope of this profile. A new authentication SHOULD be
performed unless the IDP can rely on a previously authenticated
session. A previous session MUST NOT be reused if the request
contains a "ForceAuthn" parameter.
3.3.1.5. Authentication Response to TTP
The IDP MUST issue a SAML AuthnResponse message to the TTP containing
one or more assertions or an error message with a status describing
the error occurred. The HTTP POST binding MUST be used to transfer
the message. It is RECOMMENDED that the message is signed by the IDP
or otherwise authenticated or integrity-protected.
3.3.2. Metadata Exchange orchestrated by TTP
In the second sub-phase, the metadata of SP and IDP are exchanged in
a way that is orchestrated and synchronized by the TTP.
3.3.2.1. MDI Request
After the user has been authenticated, the TTP MUST initiate the
metadata integration (MDI) between IDP and SP by a metadata
integration request. The URL [RFC3986] sent to the entities for the
MDI request SHOULD contain the query elements {?action,entityID}. The
variable name 'action' MUST be followed by '=' and the variable's
value 'fetchmetadata'. The variable name 'entityID' is followed by
'=' and the variable's value.
The means used for the metadata exchange are implementation-
dependent. The TTP MAY trigger a metadata query as described by the
Poehn, et al. Expires December 30, 2016 [Page 9]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
work in progress about the Metadata Query Protocol
[I-D.young-md-query] and the SAML Profile for the Metadata Query
Protocol [I-D.young-md-query-saml].
IDP and SP MUST integrate each other's metadata in their
configuration. It is RECOMMENDED that the IDP is triggered regarding
metadata integration before the SP because it MAY object to accepting
certain service providers. But any kind of concurrent operation MAY
be supported.
It is RECOMMENDED that the TTP queries the IDP before the metadata
exchange because it MAY be the case that the IDP has already
integrated the SP's metadata. The IDP SHOULD then indicate the found
metadata by the appropriate HTTP status code according to
[I-D.young-md-query].
3.3.2.2. MDI Response
After each other's metadata is integrated, each entity MUST send a
metadata integration response message to the TTP containing the
status of the integration by the HTTP status code.
If an entity was not able to integrate the metadata before sending
the response, the status MUST indicate this state and a new request
MUST be sent by the entity containing the status after the
integration.
If an error occurs integrating the metadata, the message MUST contain
a HTTP status code describing the error and the TTP MUST halt further
processing by displaying an error message to the user agent. It is
RECOMMENDED to roll back any configuration changes by some means out
of scope of this specification.
3.3.3. User authentication to service provider
In last step the stored AuthnRequest of the SP MUST be presented by
the TTP to the IDP if no error occurred beforehand. Because of the
successful user authentication already initiated by the trusted third
party, the IDP SHOULD respond with an assertion transferred to the
service provider without further act of authentication, except for
the case where the request contains a "ForceAuthn" parameter.
The IDP MUST issue a SAML AuthnResponse message to the services
provider's AssertionConsumerServiceURL. After receiving the
response, the SP MUST decide if the user gets access to the requested
resource based on the information contained within the SAML
assertion.
Poehn, et al. Expires December 30, 2016 [Page 10]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
4. Example
Considering two organizations, SP S (sp.example.com) and identity
provider I (idp.example.net). User U initiates the SAML metadata
exchange between these entities using an user agent through the TTP T
(ttp.example.org).
4.1. IDP Discovery
After requesting access to a secured resource via HTTPS, S redirects
U to the discovery service of T:
GET /discovery/DAME?entityID=https%3A%2F%2Fsp.example.com%2FSSO
&return=https%3A%2F%2Fsp.example.com%2FSSO%2FTTP%3FSAMLDS%3D1
%26target%3Dtarget HTTP/1.x
Host: ttp.example.org
U selects an appropriate IDP I. T redirects U back to S using the
following message:
HTTP/1.x 302 Found
...
Location: https://sp.example.com/SSO/DAME?SAMLDS=1&target=target
&entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
GET /SSO/DAME?SAMLDS=1&target=target
&entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
Host: sp.example.com
4.2. Authentication Request Protocol using a TTP
Receiving U's selection, S redirects the user to T containing a SAML
authentication request (AuthnRequest1):
HTTP/1.x 302 Found
...
Location:
https://ttp.example.org/discovery/DAME?action=authenticate
&idpEntityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
&SAMLRequest=fZHNTsMwEIRfJf.....
...
GET /DAME?action=authenticate
&SAMLRequest=fZHNTsMwEIRfJf.....
&RelayState=target
Host: ttp.example.org
Poehn, et al. Expires December 30, 2016 [Page 11]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
T temporarily stores the authentication request and redirects U to I
sending a second authentication request (AuthnRequest2) containing
the SAML request:
GET /idp/profile/SAML2/Redirect/SSO
?SAMLRequest=lZLBbhshEIZfBXHfh..... HTTP/1.x
Host: idp.example.net
After successful authentication, I issues a SAML authentication
response message to T:
POST /SSO/SAML2/POST HTTP/1.x
POSTDATA
Referer:...
Set-Cookie:...
As U is successfully authenticated, I and S are triggered to fetch
each others metadata by T using the appropriate
TTPMetadataSyncLocation defined in the entity's SAML metadata, e.g.,
/idp/profile/SAML2/DAME:
GET /idp/profile/SAML2/DAME?action=fetchmetadata
?entityID=https%3A%2F%2Fsp.example.com%2FSSO HTTP/1.x
Host: idp.example.net
GET SSO/DAME?action=fetchmetadata
?entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
Host: sp.example.com
The entities download the metadata from T using, e.g., SAML Profile
for Metadata Query Protocol [I-D.young-md-query-saml]. Only I's
messages to download S's metadata are presented here, S's messages
are equivalent:
GET /metadataservice/entities/https%3A%2F%2Fsp.example.com%2F
SSO HTTP/1.x
Host: ttp.example.org
Accept: application/samlmetadata+xml
HTTP/1.x 200 OK
Content-Type: application/samlmetadata+xml
...
T sends a request to I and S in order to receive the status of the
integration:
Poehn, et al. Expires December 30, 2016 [Page 12]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
GET /metadataservice/DAME?action=add&status=status HTTP/1.x
I answeres with:
HTTP/1.x 200 OK
After successful completion T forwards S's authentication request to
I:
GET /idp/profile/SAML2/Redirect/SSO
?SAMLRequest=fZHNTsMwEIRfJf.....
&RelayState=target HTTP/1.x
Host: idp.example.net
I answers to S's AssertionConsumerServiceURL with a SAML Response:
POST /SSO/SAML2/POST HTTP/1.x
POSTDATA
...
Receiving the SAMLResponse, S redirects U to the requested resource:
HTTP/1.x 302 Found
...
Location: sp.example.com/secure
...
GET /secure HTTP/1.x
Cookie...
HTTP/1.x 200 OK
5. Security Considerations
5.1. Integrity
As SAML metadata contains information necessary for the secure
operation of interacting services, it is strongly RECOMMENDED that a
mechanism for integrity checking is provided to clients. This MAY
include the use of SSL/TLS at the transport layer, digital signatures
present within the metadata document, or any other such mechanism.
It is RECOMMENDED that the integrity checking mechanism provided by a
responder is a digital signature embedded in the returned metadata
document, as defined by [OASIS.saml-metadata-2.0-os] section 3:
- SHOULD use an RSA key pair whose modulus is no less than 2048 bits
in length.
Poehn, et al. Expires December 30, 2016 [Page 13]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
- SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest
algorithm.
- MUST NOT use the MD5 cryptographic hash algorithm as a digest
algorithm.
- SHOULD otherwise follow current cryptographic best practices in
algorithm selection.
5.2. Confidentiality
In many cases service metadata is public information and therefore
confidentiality SHOULD NOT be required. In those cases, where such
functionality is required, it is RECOMMENDED that both the requester
and responder support SSL/TLS. Other mechanisms, such as XML
encryption, MAY also be supported for privacy concerns.
5.3. Inappropriate Usage
This protocol mandates the authentication of users before any trust
between SP and IDP is technically established. Although this
requires a further step for users, it protects against inappropriate
usage of the user-initiated trust establishment process. An example
of inappropriate usage is triggering the metadata exchange for an
IDP, where the user has no account. Therefore, the user MUST be
authenticated before the metadata is exchanged.
5.4. Trust
This protocol enables the user to trigger the SAML metadata exchange
between two entities and establish the bi-directional technical trust
relationship. This is a prerequisite of the subsequent exchange of
user information.
For entities, which require a higher level of trust, it is
RECOMMENDED to make use of one ore more additional mechanisms, e.g.,
the usage of flags in metadata, implementation depending mechanisms
in order to secure sensitive information, or to take organizational
measures, such as requiring written contracts between SPs and IDPs.
6. IANA Considerations
This document has no actions for IANA.
Poehn, et al. Expires December 30, 2016 [Page 14]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
7. Acknowledgements
The research leading to these results has received funding from the
European Community's Seventh Framework Programme under grant
agreement no 605243 (GN3plus).
8. References
8.1. Normative References
[OASIS.saml-bindings-2.0-os]
Cantor, S., "Bindings for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[OASIS.saml-core-2.0-os]
Cantor, S., "Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0", March
2005.
[OASIS.saml-idp-discovery]
Cantor, S., "Identity Provider Discovery Service Protocol
and Profile", March 2008.
[OASIS.saml-metadata-2.0-os]
Cantor, S., "Metadata for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[OASIS.saml-profiles-2.0-os]
Cantor, S., "Profiles for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", January 2005.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", June 2014.
8.2. Informative References
[I-D.young-md-query]
Young, I., "Metadata Query Protocol, draft-young-md-
query-05 [work in progress]", April 2015.
Poehn, et al. Expires December 30, 2016 [Page 15]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
[I-D.young-md-query-saml]
Young, I., "SAML Profile for Metadata Query Protocol,
draft-young-md-query-saml-05 [work in progress]", April
2015.
[OASIS.saml-glossary-2.0-os]
Hodges, J., "Glossary for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[RFC4926] Kalin, T. and M. Molina, "A URN Namespace for GEANT", July
2007.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", July 2013.
[SAML2Int]
Solberg, A., "Interoperable SAML2.0 Web Browser SSO
Deployment Profile".
Authors' Addresses
Daniela Poehn
Leibniz Supercomputing Centre
Boltzmannstrasse 1
Garching n. Munich, Bavaria 85748
Germany
Phone: +49 (0) 89 35831 8763
Email: poehn@lrz.de
Stefan Metzger
Leibniz Supercomputing Centre
Boltzmannstrasse 1
Garching n. Munich, Bavaria 85748
Germany
Phone: +49 (0) 89 35831 8846
Email: metzger@lrz.de
Poehn, et al. Expires December 30, 2016 [Page 16]
Internet-Draft Metadata Exchange in SAML Web SSO Profile June 2016
Wolfgang Hommel
Universitaet der Bundeswehr Muenchen, Computer Science Department
Werner-Heisenberg-Weg 39
Neubiberg, Bavaria 85577
Germany
Phone: +49 (0) 89 6004 2495
Email: wolfgang.hommel@unibw.de
Michael Grabatin
Universitaet der Bundeswehr Muenchen, Computer Science Department
Werner-Heisenberg-Weg 39
Neubiberg, Bavaria 85577
Germany
Phone: +49 (0) 89 6004 3992
Email: michael.grabatin@unibw.de
Poehn, et al. Expires December 30, 2016 [Page 17]