Skip to main content
Identity Authority
Category: Federation & SSO

Metadata Exchange

Also known as: WS-MetadataExchange, MEX
Simply put

Metadata Exchange refers to the process or protocol by which one system retrieves descriptive information (metadata) about another service, such as how to connect to it and what it supports. In identity and federation contexts, this exchanged metadata typically helps two parties establish trust and interoperate without manual configuration. The specific meaning depends heavily on the standard involved, as the term is used across several unrelated specifications.

Formal definition

Metadata Exchange denotes mechanisms for programmatically publishing and retrieving metadata that describes a service's endpoints, capabilities, and configuration. One formalization is WS-MetadataExchange, a Web services protocol specification (originally published by BEA Systems, IBM, Microsoft, and SAP, with a W3C Recommendation dated 13 December 2011) defining a specialized Web service, addressable via a WS-Addressing endpoint reference or a URL, whose purpose is to expose service metadata. The term is not exclusive to this specification: for example, SDMX (Statistical Data and Metadata Exchange, ISO 17369:2013) is an unrelated international standard for exchanging statistical data and metadata between organisations. Practitioners should confirm which specification or vendor context (for example, WS-MetadataExchange versus a vendor-specific feature) is meant, since exact behavior, message formats, and trust implications vary accordingly; the evidence here does not detail how any of these apply to specific IAM federation standards.

Why it matters

In federation and interoperability, establishing trust between two parties typically requires each side to know how to reach the other, what protocols and bindings it supports, and which keys or certificates to use when validating messages. Metadata Exchange addresses this by letting one system programmatically retrieve descriptive information about another rather than relying on manual, error-prone configuration. Reducing hand-configured trust relationships lowers the operational burden of onboarding new partners and helps keep endpoint and key information current as it changes over time.

The term carries real risk of confusion because it is used across several unrelated specifications. WS-MetadataExchange is a Web services protocol specification (with a W3C Recommendation dated 13 December 2011) for exposing metadata about a Web service, while SDMX (Statistical Data and Metadata Exchange, ISO 17369:2013) is an entirely separate international standard for exchanging statistical data and metadata between organisations. Practitioners who encounter "Metadata Exchange" in a vendor console, protocol trace, or design document should confirm which specification or vendor-specific feature is meant before drawing conclusions about behavior or security properties.

Because the exact message formats, endpoint models, and trust implications differ by specification and by vendor implementation, treating the term as a single well-defined mechanism can lead to incorrect assumptions. The evidence here does not detail how any of these formalizations map onto specific IAM federation standards, so claims about a particular deployment should be verified against that deployment's documentation rather than the generic label.

Who it's relevant to

Security architects designing federation
Architects evaluating how trust and configuration are established between systems need to identify which Metadata Exchange mechanism a given integration relies on, since message formats and trust implications vary by specification and vendor. This affects assumptions about how endpoint and key information is retrieved and kept current.
IAM engineers integrating services
Engineers wiring services together benefit from programmatic metadata retrieval that reduces manual configuration, but they should confirm whether a product's "Metadata Exchange" feature refers to WS-MetadataExchange, a vendor-specific capability, or something else entirely before relying on its behavior.
Standards and interoperability specialists
Those working across multiple specifications must disambiguate the term, as it appears in unrelated standards such as WS-MetadataExchange (a Web services protocol) and SDMX (ISO 17369:2013, for statistical data and metadata). Correctly scoping which standard is meant prevents misapplied assumptions about capabilities and trust.
Compliance and audit reviewers
Reviewers examining how automated trust is established should verify which mechanism is documented and in use, rather than treating "Metadata Exchange" as a single well-defined control, because the evidence does not establish uniform behavior across implementations.

Inside Metadata Exchange

Entity Metadata Document
In SAML 2.0, an XML document describing an entity's role (identity provider or service provider), endpoints, supported bindings, and certificates. Metadata exchange typically refers to the process of sharing and consuming these documents between federation partners.
Endpoint Descriptors
Declarations of the URLs a partner uses for specific operations, such as SAML SSO and single logout service endpoints or, in OpenID Connect discovery, the authorization, token, and userinfo endpoints. These allow a relying party to route protocol messages correctly.
Signing and Encryption Keys
Public keys or certificates published so a partner can verify signatures on incoming assertions or tokens and, where supported, encrypt messages. Publishing a key for verification is distinct from establishing an encrypted channel; a signed metadata document is not necessarily an encrypted one.
OIDC Discovery Document
In OpenID Connect, a JSON document (commonly at a well-known discovery URL, depending on deployment) advertising issuer identity, supported endpoints, scopes, response types, and the location of the JWKS. This is the OIDC analog to SAML metadata rather than an identical mechanism.
JWKS (JSON Web Key Set)
A JSON structure publishing the public keys used to validate signatures on tokens such as ID tokens and, where applicable, JWT access tokens. It is typically referenced from an OIDC discovery document and enables key rotation without manual reconfiguration.
Supported Capabilities and Profiles
Metadata often enumerates supported bindings, name identifier formats, signing algorithms, scopes, or response modes so partners can negotiate compatible behavior. The exact fields available vary by standard (SAML 2.0 versus OIDC) and by deployment configuration.

Common questions

Answers to the questions practitioners most commonly ask about Metadata Exchange.

Is metadata exchange itself an authentication or authorization step in a federation?
No. Metadata exchange is a configuration and trust-establishment activity that occurs before any authentication or authorization takes place at runtime. It communicates the technical details each party needs to interact, such as endpoint locations, supported bindings, and signing or encryption keys, but it does not itself verify who a principal is or determine what a principal may do. Those steps happen later, during actual protocol flows, and rely on the trust and configuration that metadata exchange helped establish.
Does exchanging metadata by itself establish trust between an identity provider and a relying party?
Not on its own. Metadata exchange conveys the information needed to configure a relationship, but trust typically depends on how that metadata is validated and how the associated keys are obtained and protected. Depending on configuration, trust may rest on verifying signatures on metadata documents, on out-of-band key exchange, or on a trusted metadata source. Simply importing a metadata document without validating its authenticity does not, by itself, constitute a trustworthy relationship.
What does a SAML 2.0 metadata document typically contain, and how is it consumed?
A SAML 2.0 metadata document typically describes entity identifiers, roles (such as identity provider or service provider descriptors), endpoint URLs and supported bindings, and the signing and encryption keys or certificates used by the entity. In most deployments it is consumed by importing the document into the partner's configuration, either manually or through an automated fetch. The exact elements present and how strictly they are enforced can vary by product and by the SAML profile in use.
How can metadata be kept current when endpoints or signing keys change?
In many deployments metadata is retrieved from a published URL so that consumers can refresh it periodically rather than relying on a one-time manual import. This can help propagate changes such as new endpoints or rotated signing keys. Whether refresh is automatic, how often it occurs, and whether the refreshed document is re-validated depend on the specific product and configuration. Where automated refresh is not available, key rotation and endpoint changes typically require a coordinated manual update on both sides.
What should be validated when importing a metadata document from a partner?
Depending on configuration, considerations typically include verifying any signature on the metadata document, confirming the authenticity and expiry of embedded certificates, checking that the entity identifier matches the expected partner, and reviewing the declared endpoints and bindings against what is expected. Because a signed metadata document is signed rather than necessarily encrypted, integrity and origin can be checked via the signature, but the transport channel and source of the document should also be considered. The rigor of these checks varies by product.
How does metadata handling differ between SAML 2.0 and OpenID Connect deployments?
The two use different mechanisms. SAML 2.0 relies on XML-based metadata documents describing entities, endpoints, bindings, and keys. OpenID Connect, built on OAuth 2.0, commonly uses a discovery document and a separate keys endpoint to publish provider configuration and signing keys, so relying parties can retrieve current settings and keys programmatically. The specific fields, endpoints, and how strictly they are enforced depend on the standard profile and the product in use, and details beyond these general patterns are out of scope for this entry.

Common misconceptions

Metadata exchange authenticates users or is part of the runtime authentication flow.
Metadata exchange is a configuration and trust-establishment concern between entities, not an authentication of end users. It supplies the endpoints and keys that later enable authentication (in OIDC/SAML) and message validation, but identifying and authenticating a principal happens as a separate runtime step.
A signed metadata or discovery document is confidential because it is signed.
Signing provides integrity and origin assurance, not confidentiality. Metadata documents are frequently published at public URLs. A document being signed is not the same as it being encrypted, and most metadata is intended to be readable by partners.
SAML metadata and OIDC discovery documents are interchangeable formats.
SAML 2.0 uses XML entity metadata, while OpenID Connect uses a JSON discovery document backed by a JWKS. They serve analogous purposes of advertising endpoints and keys but are distinct mechanisms tied to different standards and are not directly interoperable.

Best practices

Retrieve partner metadata over an authenticated, integrity-protected channel and, where supported, verify signatures on the metadata document rather than trusting content fetched over an untrusted path.
Automate periodic refresh of metadata and JWKS so signing key rotation by a partner does not silently break signature validation, while accounting for caching behavior that varies by deployment.
Pin or explicitly validate the entity identifier or issuer value in consumed metadata to avoid trusting a document that impersonates a legitimate partner.
Separate verification keys from any encryption keys in configuration, and confirm whether message-level encryption is actually required for your profile rather than assuming signed metadata implies confidentiality.
Restrict and review which endpoints, bindings, algorithms, and scopes you accept from partner metadata instead of enabling everything advertised, tightening to the minimum your deployment requires.
Track expiration and validity windows on published certificates and metadata, and coordinate key rollover with federation partners ahead of expiry to prevent authentication outages.
Promotional banner for the Pentest Readiness checklist download