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

## Declared metadata is an input, not an answer An entity describes itself in the `metadata` claim of its **Entity Configuration**. In a multilateral federation that description is a *request*: the operator that vouches for the entity also decides what the description is allowed to resolve to. That decision travels as `metadata_policy`, carried **only** in the **Subordinate Statements** a Superior issues, never in the entity's own configuration — which is precisely what stops a member granting itself latitude the federation withheld. Policy is keyed in two levels: first by **Entity Type Identifier** (`openid_relying_party`, `openid_provider`, `oauth_authorization_server`, `oauth_client`, `oauth_resource`, `federation_entity`), then by the metadata parameter it governs. ## The operators | Operator | Effect on the parameter | |---|---| | `value` | Force it to exactly this value, whatever the entity declared | | `add` | Add these values to the entity's list | | `default` | Use this when the entity declared nothing | | `one_of` | The resulting scalar must be one of these | | `subset_of` | The resulting list may contain only these | | `superset_of` | The resulting list must contain at least these | | `essential` | The parameter must be present in the result | Read the list carefully, because two pairs are routinely confused. `add` and `superset_of` both concern values being present, but `add` *puts them there* and `superset_of` *requires them to be there*, failing otherwise. `default` and `value` both supply a value, but `default` yields to what the entity declared and `value` overrides it. ## Merging down the chain A chain can carry policy at several levels: the Trust Anchor's statement about an Intermediate, that Intermediate's statement about the next one down, and so on. Those policies are merged, top-down, before being applied to the leaf's declared metadata. The merge is directional. A Superior nearer the anchor sets the outer bound, and a Superior below it may narrow that bound further — intersecting a `subset_of` with a smaller set, say — but may not widen it. Where two levels cannot be reconciled at all, the correct outcome is a **resolution failure**: the chain does not resolve, rather than resolving to whichever level the implementation happened to apply last. Silent precedence would let an Intermediate quietly undo the anchor's rule, and the whole point of anchoring trust is that it cannot. `metadata_policy_crit` exists for the same reason at the operator level. It lists policy operators that a consumer **must** understand; if a consumer meets one there that it does not implement, it must reject the statement rather than ignore that operator and resolve the rest. An unimplemented restriction silently skipped is worse than no restriction at all, because everyone downstream believes it applied. ## The failure this produces in the field The schools-network version goes like this. An academy trust registers a relying party declaring three grant types. The network's Trust Anchor carries `"grant_types": { "subset_of": [...] }` naming two of them. Every provider in the federation resolves the member's metadata to those two, and the third simply is not there. Nothing errors at registration, because nothing was rejected — the value was narrowed, exactly as designed. The member's operators report that "the registration was ignored", and look for their bug in their own configuration for a week. The diagnostic habit worth building: when a member's declared metadata and the behaviour everyone else sees disagree, resolve the chain yourself and read the merged policy, level by level, before touching either end. ## constraints is a different lever `constraints` also travels in Subordinate Statements and is easy to file mentally under the same heading, but it governs the **shape of the subtree**, not the value of any metadata parameter: - `max_path_length` — how many Intermediates may sit between this Superior and a Leaf Entity; - `naming_constraints` — which Entity Identifiers are permitted or excluded beneath it; - `allowed_entity_types` — which Entity Type Identifiers may appear below it. Policy decides what a member may declare. Constraints decide what may exist below a Superior at all.