skip to content

In a multi-party login federation, what must be agreed before one member's identity provider is trusted by another?

level: juniorimportance: must knowfreq 50%

answer

  1. pairs grow faster than members
  2. one anchor instead of many agreements
  3. each member publishes a signed self-description
  4. authority_hints names your Superior
  5. the anchor's key is configured out of band

basics

~20 s

Both members must already trust the same third party, a federation Trust Anchor, and each must publish a signed statement about itself under it. The anchor's attestation, not a private agreement between the two, is what makes the other side acceptable.

solid answer

~40 s

Three things: a stable name for each party, the keys each signs with, and someone both sides already trust who vouches for the pairing. Done bilaterally, that is one exchange per pair, and pairs grow far faster than members. Multilateral federation replaces it with a common anchor. In OpenID Federation 1.0 each member publishes a self-signed **Entity Configuration** at its `/.well-known/openid-federation` path, naming its Immediate Superiors in `authority_hints`; a Superior issues signed **Subordinate Statements** about the members below it; anyone configured with the Trust Anchor's Entity Identifier and key can build a **Trust Chain** to a member it has never contacted. The SAML 2.0 equivalent is an operator-signed `<EntitiesDescriptor>` aggregate. What is agreed is who vouches — not how the member logs its users in.

code

xml · 14 lines
xml
<EntitiesDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                    Name="urn:example:schools-network"
                    validUntil="2026-10-19T00:00:00Z"
                    cacheDuration="PT12H">
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- one signature covering the whole aggregate -->
  </ds:Signature>
  <EntityDescriptor entityID="https://idp.trust-a.schools.example/idp">
    <!-- one member's own description -->
  </EntityDescriptor>
  <EntityDescriptor entityID="https://sp.assessment.schools.example/sp">
    <!-- another member's own description -->
  </EntityDescriptor>
</EntitiesDescriptor>

go deeper

for a junior

Recall the shape: both sides trust a common third party, each publishes a signed description of itself, and the third party's attestation replaces a private deal between the two.

for a middle

Explain the mechanics — a self-signed Entity Configuration at a well-known path, a Superior's Subordinate Statement about it, and a Trust Chain assembled up to an anchor the verifier was configured with.

for a senior

Show why the pairwise model fails operationally, not just arithmetically: key changes, endpoint moves and departures all have to be pushed to every holder of a copy.

for a principal

Weigh what you are buying from an operator. A common anchor concentrates a dependency and a governance surface, and the question becomes whether the operator's rules match the contracts you actually hold.

## What has to be settled before any login crosses When your service accepts a login asserted by an organisation you do not run, you are accepting a document signed by a stranger. Four things must be settled first, and none of them is about the login itself. - **A stable name for each party.** In OpenID Federation 1.0 that is an **Entity Identifier**, an HTTPS URL. In SAML 2.0 metadata it is an `entityID`. Everything else hangs off this name. - **Which keys count.** A signature is only evidence if you know which key was supposed to make it. - **What each party is, and what it may do.** An OpenID Federation Entity Statement carries a `metadata` claim keyed by Entity Type Identifier — `openid_provider`, `openid_relying_party`, `oauth_authorization_server`, `oauth_client`, `oauth_resource`, `federation_entity`. - **Who vouches.** The one that actually decides whether this scales. ## Doing it in pairs, and where that stops Bilateral federation answers "who vouches" with "we do, to each other": the two organisations exchange documents out of band, each configures the other's keys, and they maintain that relationship by hand. It is perfectly sound for two parties. The cost is quadratic. A network of 40 members has 780 possible pairs; the 41st joiner needs 40 separate exchanges before it is usable everywhere, and every key change or endpoint move has to be pushed to everyone who holds a copy. A national schools network onboarding academy trusts one at a time meets this wall early: the joining work grows with the size of the network, so the network outgrows the process long before it finishes onboarding. ## The multilateral answer: one anchor everyone already trusts A **Trust Anchor** in OpenID Federation 1.0 is an Entity with no Superior whose Entity Configuration a party is configured, out of band, to trust. It is **not** an X.509 root certificate in a local trust store — the words are the same and the objects are not. The pattern is: 1. Every participant publishes a self-signed **Entity Configuration** at its own `/.well-known/openid-federation` path. Any Entity that has a Superior lists that Superior in `authority_hints`. 2. Each Superior — an **Intermediate Entity**, or the Trust Anchor itself — issues a **Subordinate Statement** about each entity immediately beneath it, and serves it from its `federation_fetch_endpoint`. 3. A relying party that holds only the Trust Anchor's Entity Identifier and key can collect those statements into a **Trust Chain** from the **Leaf Entity** up to the anchor, and decide about a member it has never spoken to. Onboarding becomes one relationship — with the operator — instead of one per counterparty. ## The same move, in the XML world SAML 2.0 gets there with an operator-signed aggregate. The federation operator collects members' `<EntityDescriptor>` elements into a single `<EntitiesDescriptor>`, covers the whole aggregate with one `<ds:Signature>`, and publishes it. A consumer verifies one signature and gains every member inside. A metadata instance's root element must carry `validUntil` or `cacheDuration`, which is how consumers know when to refresh. `<AffiliationDescriptor>`, with `affiliationOwnerID` and its `<AffiliateMember>` entries, names a set of entities that are to be treated as one group. | Approach | What you configure | Cost of the Nth joiner | How change propagates | |---|---|---|---| | Bilateral exchange | Every counterparty's keys | One exchange per existing member | You notify everyone holding your document | | Common Trust Anchor | The anchor's Entity Identifier and key | One Subordinate Statement from your Superior | Chains are rebuilt on expiry, from live endpoints | | Operator-signed aggregate | The operator's signing key and the aggregate URL | One entry added to the aggregate | Consumers refresh on `validUntil` / `cacheDuration` | ## What the agreement does not cover The anchor attests that a member exists under it, under that name, with those keys, within the metadata its rules allow. It does not attest that the member authenticates its users carefully, deprovisions leavers promptly, or releases honest attributes. Those are contractual questions, and where a federation grades them at all it does so with a separate object — a signed trust mark — not with the chain that establishes the party.

  • Why does the joining cost grow so much faster than the membership?
    Because bilateral trust is a property of pairs, not of members. A network of n members has n(n-1)/2 possible pairs, so the 41st joiner in a 40-member network faces 40 separate exchanges, and every key change it makes later has to reach all 40 again. Anchoring the trust makes the joiner's work one statement from its Superior.
  • What does a party have to hold before it can validate anything in a federation?
    The Trust Anchor's Entity Identifier and the keys from the anchor's Entity Configuration, configured out of band — that is the one relationship that cannot itself be bootstrapped from the federation. Everything below it, including members' keys, arrives inside signed statements that chain up to that anchor.
  • In the SAML 2.0 aggregate, what tells a consumer when to refetch?
    The root element's `validUntil` and `cacheDuration` attributes; a metadata instance's root element must carry one of the two. `validUntil` is an absolute expiry after which the document must not be relied on, and `cacheDuration` is how long a consumer may hold it before refreshing. Letting `validUntil` lapse takes every member in the aggregate out at once.

A league where every club vetted every other club's paperwork would spend the season on paperwork. Each club registers once with the league office instead, and a fixture only needs both registrations to be current.

saying these in an interview costs you the question

  • Thinks scale is solved by exchanging documents with each new partner
  • Reads Trust Anchor here as a root certificate in a trust store
  • Believes the anchor's signature vouches for the member's users
  • Says a member can join without publishing anything about itself
  • Claims a TLS connection between the two organisations is the trust agreement