Federation metadata

Before an identity provider and a relying party can federate, each needs facts about the other: a unique identifier, the addresses where requests and responses are sent, the protocol options it supports, and the public keys or certificates that check its signatures. SAML defines a standard metadata format, and OpenID Connect providers commonly publish the equivalent through a discovery document and a published key set. NIST SP 800-63C-4 treats this as identifier and key establishment, which can be manual or dynamic, and requires identifiers to be established manually at FAL3.

Metadata is where federation trust is configured, so its integrity matters as much as the assertions it validates. If an attacker can substitute a signing certificate in a relying party’s copy, that relying party will accept assertions the attacker signs. Metadata is therefore commonly obtained over a trusted channel or signed by a party both sides trust. There is an operational side too: when an identity provider replaces its signing certificate, relying parties that have not refreshed their metadata can start rejecting valid sign-ins.

Exam relevance: a scenario is likely to describe a partner federation being set up, or sign-ins failing after a certificate change, and ask what must be exchanged or updated. Candidates are expected to recognise metadata as the pre-arranged configuration that establishes trust, distinct from the per-login SAML assertion.