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

## The question behind the question A federation operator writes rules for organisations it does not employ, cannot audit continuously and cannot fire. The design problem is to make the technical levers line up with the contractual ones, so the rulebook does not promise enforcement the mechanism cannot deliver. ## What the anchor can actually enforce - **What metadata resolves to.** `metadata_policy` in the **Subordinate Statements** you issue narrows members' declared metadata for everyone resolving through you. Strong, and invisible to the member until something it declared does not appear. - **What may exist beneath you.** `constraints` — `max_path_length`, `naming_constraints`, `allowed_entity_types` — bounds the subtree an Intermediate may build under your anchor. - **Who may accredit whom.** A **Trust Anchor** may publish `trust_mark_issuers`, naming which entities may issue a given `trust_mark_type`, and `trust_mark_owners`, naming the party that owns a mark type and the keys under which it signs a `delegation` to an issuer. Both are honoured only in a Trust Anchor's statement and must be ignored on any entity that is not one — otherwise a member could appoint its own accreditor. - **Whether a member is in the federation at all.** Stop issuing its Subordinate Statement and it leaves every **Trust Chain** that runs through you. ## What the anchor cannot reach - **Conduct.** Nothing in a statement measures how a member authenticates its users, how honest its attributes are, or how quickly it deprovisions leavers. Registration is not compliance. - **Relying parties' choices.** Your policy narrows what a member may present; it does not oblige any member to accept any other. A relying party can hold additional local rules, require a particular mark, or simply decline. - **Other anchors.** A member that also sits under a second anchor can present a chain that never touches you, under that anchor's policy rather than yours. - **Immediacy.** Withdrawal is not instantaneous. Statements already issued remain valid until their `exp`, so your statement lifetimes are your enforcement clock, and shortening them costs fetch traffic at every resolution. ## Why trust marks exist alongside all this Anchor-level levers are close to binary: a member is attested or it is not. Real federations need to say more than "in" or "out" — that this member has passed a safeguarding review, or is entitled to receive a certain category of attribute. A **trust mark** carries that: a signed JWT, `typ` `trust-mark+jwt`, whose `iss` is the Trust Mark Issuer, whose `sub` is the member, naming a `trust_mark_type`, optionally with `delegation`, a `ref` pointing at human-readable information, and a `logo_uri`. Members list the marks they hold in the `trust_marks` claim of their **Entity Configuration**. That design separates three roles the operator would otherwise have to fill alone: 1. the **owner** of a mark type, which defines what it means; 2. the **issuer**, which assesses members and signs — possibly a specialist accreditor operating under a `delegation`; 3. the **anchor**, which says whose issuance it will honour. And because an accreditation can lapse between issuance and use, a Trust Mark Issuer should publish a `federation_trust_mark_status_endpoint` so a relying party can ask whether a mark still stands rather than inferring it from the mark's own lifetime. What a given mark *means* — the accreditation grade behind it — is a trust-framework question, not something the federation mechanism defines. ## The judgement to make | Lever | Enforces | Latency | Cost of leaning on it | |---|---|---|---| | `metadata_policy` | Values members may present | Next resolution | Members lose the freedom to vary anything you encode | | `constraints` | Shape of the subtree | Next resolution | Rigid naming and depth limits are painful to change later | | Trust marks | Graded, revisable accreditation | Status check | Needs assessors and a status endpoint that stays up | | Withdrawing attestation | Membership | At statement `exp` | All-or-nothing, and visible to everyone | Most operators over-invest in the first row. It is the lever that feels like control, and it regulates only what members *declare*. The behaviour you actually care about is reached by accreditation plus the credible threat of withdrawal — and, unavoidably, by contract. The design test is that every rule in the rulebook maps to one of these rows, or is honestly labelled as a promise rather than an enforcement.