skip to content

Multilateral Trust

11 roadmaps6 questions

Trust reached through a common anchor instead of one agreement at a time: entity statements, trust chains, trust marks, shared key rollover. Asked when partners outgrow swapping metadata in pairs.

part ofFederated identityoverview, primer and where to startread it →
on this pageshow

explore

questions

6

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
open as a page

A Trust Chain of Entity Statements validates up to your configured Trust Anchor — what has that actually proved?

level: seniorimportance: must knowfreq 44%

basics

~20 s

That the anchor, through Superiors it authorised, currently attests this Entity Identifier, these federation keys and this resolved metadata. It proves nothing about any user, any login, or how carefully the member runs its identity provider.

open as a page

In OpenID Federation 1.0, what distinguishes an Entity Configuration from a Subordinate Statement?

level: middleimportance: should knowfreq 38%

basics

~20 s

Both are Entity Statements, but an Entity Configuration is self-issued, with iss equal to sub, and served from the entity's own well-known path. A Subordinate Statement is issued by a Superior about an entity immediately beneath it, so iss and sub differ.

open as a page

In OpenID Federation 1.0, how does a Trust Anchor's metadata_policy change the metadata a member entity below it gets?

level: seniorimportance: should knowfreq 32%

basics

~20 s

The member's declared metadata is input, not output. Policy operators carried in Subordinate Statements merge down the Trust Chain and are applied to it, so what every verifier acts on is the resolved result, which can be narrower than what the member published.

open as a page

As a federation operator publishing a Trust Anchor, how far can your rules actually bind members you do not employ?

level: principalimportance: should knowfreq 28%

basics

~20 s

Only as far as what chains through you: the metadata members resolve to, which names exist beneath you, who may issue which trust mark, and whether you keep attesting a member at all. Conduct behind their login is beyond reach.

open as a page

In OpenID Federation 1.0, how can a Trust Chain signed under a since-retired federation key still be validated?

level: seniorimportance: nice to knowfreq 22%

basics

~20 s

Through the federation_historical_keys_endpoint, where an entity publishes the keys it has used, each retired one marked with revoked_at and a reason of unspecified, compromised or superseded. A verifier can then judge signatures made before the key was withdrawn.

open as a page