SAML Profile for the Metadata Query Protocol

This document profiles the Metadata Query Protocol for use with SAML metadata.

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 RFC 2119. This document makes use of the Augmented BNF metalanguage defined in .

Requests compliant with this profile MUST include the following HTTP header to indicate that the metadata returned should be SAML metadata (see Appendix A of ):

Accept: application/samlmetadata+xml

Each identifier in a request may be either: The unique identifier of an entity, corresponding to the entityID attribute of the entity's EntityDescriptor element in SAML metadata, or The responder-defined identifier of an arbitrary group of entities. SAML 2.0 includes profiles based on the transfer of an "artifact" containing the unique identifier of a SAML entity transformed by means of the SHA-1 hash algorithm (see sections 3.6 and 3.6.4). In order to support use cases in which clients may be in possession of only such a transformed representation of a SAML entity's unique identifier without any way to establish the original entity identifier, a responder compliant with this profile MUST accept an extended identifier matching the sha1id production in the following ABNF grammar as as equivalent to the corresponding untransformed identifier:

In the above, the sha1hex component encodes the 20-octet (160-bit) binary SHA-1 hash value as a sequence of 40 lower case hexadecimal digits. For example, the identifier

http://example.org/service transformed by means of SHA-1 hashing would become

{sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb Malformed SHA-1 transformed extended identifiers, for example where the string of characters following the "}" contains characters other than hexadecimal digits, or is other than exactly 40 characters in length, MUST result in an HTTP status code of 400 ("bad request").

A request may return information for any number of entities, including none. Responses compliant with this profile MUST use the appropriate representation described below depending on the number of EntityDescriptor elements returned.

A response which returns no EntityDescriptor elements MUST be represented by an HTTP status code of 404 ("not found").

A response which returns a single EntityDescriptor element MUST use that element as its document element. The responder MUST NOT make use of a EntitiesDescriptor element in this situation (see section 2.3). Such a response MUST include the following HTTP header to indicate that the metadata returned is SAML metadata:

Content-Type: application/samlmetadata+xml

A response which returns more than one EntityDescriptor element MUST consist of a document element which is an EntitiesDescriptor element, containing the returned EntityDescriptor elements as children. Responses MUST NOT contain nested EntitiesDescriptor elements. Such a response MUST include the following HTTP header to indicate that the metadata returned is SAML metadata:

Content-Type: application/samlmetadata+xml

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. 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 section 3. Such digital signatures: SHOULD use an RSA keypair whose modulus is no less than 2048 bits in length. 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.

This profile mandates the availability of a identifier synonym mechanism based on the SHA-1 cryptographic hash algorithm. Although SHA-1 is now regarded as weak enough to exclude it from use in new cryptographic systems, its use in this profile is necessary for full support of the SAML 2.0 standard. Because the SHA-1 cryptographic hash is not being used within this profile in the context of a digital signature, it is not believed to introduce a security concern over and above that which already exists in SAML due to the possibility of a post-hash collision between entities whose entityID attributes hash to the same value. Implementations may guard against this possibility by treating two entities whose entityID values have the same SHA-1 equivalent as an indicator of malicious intent on the part of the owner of one of the entities.

This document has no actions for IANA.

The editor would like to acknowledge the following individuals for their contributions to this document: Scott Cantor (The Ohio State University) Leif Johansson (SUNET) Joe St Sauver (University of Oregon) Tom Scavo (Internet2)