The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.
Overview To securely interoperate, partners share metadata in whatever form and by whatever means possible. In any case, at least the following metadata must be shared:
Entity ID Protocol endpoints (bindings and locations)
Every SAML system entity has an entity ID, a globally-unique identifier used in software configurations, relying-party databases, and client-side cookies. On the wire, every SAML protocol message contains the entity ID of the issuer.
For authentication purposes, a SAML message may be digitally signed by the issuer. To verify the signature on the message, the message receiver uses a public key known to belong to the issuer. Similarly, to encrypt a message, a public encryption key belonging to the ultimate receiver must be known to the issuer. In both situations—signing and encryption—trusted public keys must be shared in advance.
Once the message is signed and encrypted, the issuer sends the message to a trusted protocol endpoint, the location of which must be known in advance. Upon receipt, the message receiver decrypts the message (using its own private decryption key) and verifies the signature (using a trusted public key in metadata) before mapping the entity ID in the message to a trusted partner.
The previous scenario requires each party to know the other in advance. To establish a baseline of trust, parties share metadata with each other. Initially, this may be as simple as sharing information via email. Over time, as the number of SAML partners grows, the natural tendency is to automate the metadata sharing process.
To fully automate the metadata sharing process, a standard file format is needed. To this end, the SAML V2.0 Metadata specification defines a standard representation for SAML metadata that simplifies the configuration of SAML software and makes it possible to create secure, automated processes for metadata sharing.
Metadata-driven interoperability As SAML technology has matured, the importance of SAML metadata has steadily increased. Today an implementation that supports SAML web browser requires a schema-valid SAML metadata file for each SAML partner. (See the SAML V2.0 Profiles specification for more information about SAML web browser SSO.)
Static metadata configuration The term static metadata refers to a metadata file that is configured directly into the SAML application by an administrator. In doing so, the administrator becomes responsible for the maintenance of the metadata regardless of how the metadata was obtained in the first place. Thus static metadata contributes to the overall static configuration of the SAML application.
Unfortunately, SAML metadata is inherently non-static as illustrated by the following typical scenario between a SAML identity provider (IdP) and a SAML service provider (SP). Suppose an IdP owner obtains SAML metadata from an SP partner. Perhaps the SP metadata is transmitted to the IdP owner via email, or maybe the IdP owner logs into a protected web app and downloads the SP metadata via a browser. Regardless of how the metadata is obtained, the result is the same: the IdP owner configures the SP metadata directly into the IdP software.
Now suppose the SP metadata contains a public encryption key. Presumably, the corresponding private decryption key is configured into the SP software. If the private decryption key is compromised (or otherwise needs to be replaced), the public encryption key in the SP metadata is no longer trustworthy and must be replaced as well.
Since the SP metadata is statically configured in the IdP software, only the IdP owner can replace the public encryption key in the SP metadata. In this sense, the IdP owner is responsible for the SP metadata. This mismatch leads to interoperability issues.
The same is true on the SP side. By statically configuring IdP metadata into the SP software, the SP owner implicitly accepts the responsibility to maintain the IdP metadata when something changes. Since an IdP (or SP) typically has many partners, static metadata configuration clearly does not scale, and moreover, change management associated with static metadata is difficult at best.
Dynamic metadata exchange Not surprisingly, metadata sharing processes yearn to be automated. Every metadata file that is statically configured into the SAML application by an administrator incurs technical debt. The accumulation of this debt prevents the SAML deployment from scaling to its potential.
To avoid excessive technical debt, the metadata sharing process must be automated. One approach is to enlist the help of a trusted third party whose responsibility it is to collect, curate, and distribute metadata across the network. Curated metadata is consistently formatted, more likely to be free of vulnerabilities (intentional or otherwise), and therefore safe to use.
In the case of SAML metadata, this trusted third party is called a SAML federation. The community of SAML deployers comprising the federation willingly conform to one or more profiles of SAML to promote interoperability and trust. To that end, federation participants often share a central infrastructure for metadata sharing, which allows the federation to scale to thousands of interoperable SAML deployments.
History
Now let's retrace some of the steps that led to the publication of the SAML V2.0 Metadata specification in March 2005. A turning point occurred on 14 November 2003—our story starts there.
Historical origins In response to Microsoft Passport, the Liberty Alliance conceived the Identity Federation Framework, a federation technology developed over a three-year period between 2002 and 2004. (The previously mentioned history of SAML provides context for ID-FF.) On 14 November 2003, Liberty contributed ID-FF 1.2 to OASIS. The contribution included a document entitled Liberty Metadata Description and Discovery Specification Version 1.0, which included the following design goals:
"whois for SAML federations" (based on the Organization and ContactPerson elements in metadata) dynamic discovery of metadata (with resolution via DNS and Well-Known Location) document-level security using XML Signature
As it turns out, all of those goals were preserved in the OASIS SAML V2.0 Metadata Standard described later in this article.
The schema document included with the legacy Liberty ID-FF 1.2 archive is identified as Liberty Metadata Version 1.1 whereas Liberty Metadata Version 1.0 was contributed to OASIS. The apparent contradiction was explained by the schema's author. (Peter Davis, Personal Communication) Between November 2003 (when Version 1.0 was contributed to OASIS) and December 2004 (when Version 1.1 was completed by Liberty), development of the Liberty metadata specification continued in parallel with the OASIS work stream. See the chart below for a visual representation. The arrows in the chart indicate dependencies while the dashed lines indicate equivalencies.
Relevant references into the Liberty work stream are given at the end of this article. The original metadata schema contributed to OASIS is listed in its entirety in section 7 of the Liberty Metadata Version 1.0 specification. Similarly, the specification for Liberty Metadata Version 1.1 includes a listing of the Version 1.1 schema. Both the Version 1.0 schema and the Version 1.1 schema are linked here courtesy of the Internet Archive's Wayback Machine.
Post-November 2003 Over the next thirteen months, from November 2003 to December 2004, the OASIS Security Services (SAML) Technical Committee (SSTC) molded the Liberty metadata specification into what eventually became known as SAML Metadata. During that time, the SSTC generalized the metadata specification to include support for multiple protocols (including non-SAML protocols) but more importantly, the Liberty metadata schema was retrofitted with numerous extension points. Historically, the extensibility of SAML Metadata has had important consequences, as we shall see.
By March 2004, most of the Liberty contribution was incorporated into the OASIS work stream. From that point onward, the Liberty and OASIS work streams progressed concurrently (but not independently since the same people were working on both specifications). Between March and July 2004, the fledgling SAML Metadata specification underwent significant churn.
In July 2004, the SSTC issued a public call for comments covering a complete set of SAML V2.0 draft specifications. Included in that specification set was a working draft of a newly forged SAML V2.0 Metadata specification.
In retrospect, it appears as though the bulk of the SAML V2.0 Metadata specification was developed between March and July 2004, but clearly the SAML V2.0 Metadata Standard sprung from the loins of the Liberty Alliance, specifically Liberty Metadata Version 1.0. Consequently, to understand the origins of SAML Metadata, one must study the provenance of Liberty metadata.
The remaining history of SAML Metadata is mostly OASIS administrative process. After the final Committee Draft was published in November 2004, the SSTC began the standardization process in January 2005. Finally, on 5 March 2005, OASIS announced the newly ratified SAML V2.0 Standard.
The V2.0 specification set (see the References section for a complete list) included the final SAML V2.0 Metadata specification. A decade later, in September 2015, OASIS published a revised SAML Metadata specification with errata. As a result, the original metadata specification was deprecated, as were the other documents in the original 2.0 specification set.
During the intervening decade, between 2005 and 2015, the SSTC developed a number of "Post-V2.0" draft specifications. Some of these draft documents became Committee Specifications. A select subset of these Committee Specifications are listed in the References section at the end of this article.
Pre-November 2003 As it turns out, the influence of the Liberty Identity Federation Framework on SAML Metadata predates the contribution of ID-FF 1.2 in November 2003. Apparently the SSTC was dabbling in metadata in parallel with the Liberty Alliance. An excerpt from a draft metadata specification published in September 2003 bears this out:
This document defines metadata that describe the elements and attributes required to use the SAML Web Browser SSO Profiles. Since the Liberty Alliance Web SSO Profiles are directly based on the SAML Web SSO Profiles, the metadata defined in this document borrows extensively from the metadata definitions in the draft Liberty Alliance 1.2 specifications. (Excerpted from "Metadata for SAML 2.0 Web Browser SSO Profiles")
The revision history at the end of that draft document gives the following characterization of itself: "Initial draft based on Draft 07 of SAML 1.1 Metadata specification." In other words, earlier draft documents were published. Indeed, the revision history at the end of the previous draft shows a trail of metadata specifications dating back to November 2002.
Following the document trail, the influence of Liberty ID-FF on SAML metadata can be traced to a draft specification published in April 2003. This is the first known OASIS document that references Liberty ID-FF, specifically, Liberty Metadata Version 1.0-06, an early version of the Liberty Metadata specification about which little is known. It is, however, clear that "Metadata for SAML 1.1 Web Browser Profiles" was intended to be a companion to the SAML V1.1 Standard but of course we know that V1.1 does not specify the use of metadata. See the next section for relevant conjecture.