SAML Profile for the Metadata Query ProtocolIndependentian@iay.org.ukmetadataSAML
This document profiles the Metadata Query Protocol for use
with SAML metadata.
This document is a product of the Research and Education Federations (REFEDS) Working Group process.
This document profiles the Metadata Query Protocol for use
with SAML metadata.
The Research and Education Federations group ()
is the voice that articulates the mutual needs of research and education
identity federations worldwide. It aims to represent the requirements of
research and education in the ever-growing space of access and identity
management.
From time to time REFEDS
will wish to publish a document in the Internet RFC series. Such
documents will be published as part of the RFC Independent Submission
Stream ; however the REFEDS working group sign-off process will
have been followed for these documents, as described in
the REFEDS Participant's Agreement.
This document is a product of the REFEDS Working Group process.
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 ):
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
transformed by means of SHA-1 hashing would become
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:
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:
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)
Key words for use in RFCs to Indicate Requirement Levels
Harvard Universitysob@harvard.eduUS Secure Hash Algorithm 1 (SHA1)Metadata Query Protocol
Bindings for the Security Assertion Markup Language
(SAML) V2.0
Metadata for the Security Assertion Markup Language
(SAML) V2.0Internet2cantor.2@osu.eduSigabajmoreh@sigaba.comRSA Securityrphilpott@rsasecurity.comSun Microsystemseve.maler@sun.comAugmented BNF for Syntax Specifications: ABNFThe RFC Series and RFC EditorInternet Architecture BoardREFEDS Home PageResearch and Education FederationsREFEDS Participant's AgreementResearch and Education FederationsAssertions and Protocol for the OASIS Security Assertion Markup Language
(SAML) V2.0Internet2cantor.2@osu.eduNokiaJohn.Kemp@nokia.comRSA Securityrphilpott@rsasecurity.comSun Microsystemseve.maler@sun.com
Added REFEDS RFC stream boilerplate.
Initial version.