Summary

  • RFC 9932 describes a federation’s signed metadata and mutually authenticated TLS process, but it is an Independent Informational RFC rather than an IETF standard or proof of deployment.
  • Metadata freshness, a matching certificate pin and a TLS-derived entity_id are inputs to a local authorization decision; they are not evidence that an application action was allowed or completed.

The most tempting sentence in a federation is often the least useful one: “the member is trusted.” It makes a complicated chain sound like a single fact. A federation may vet a member, publish a signed record, distribute a public verification key, tell peers which pin belongs to which entity and require a connection to stop when the pin does not match. Each of those is real work. None of them, alone or together, converts the next application request into an authorized act.

RFC 9932, Mutually Authenticating TLS in the Context of Federations, is unusually clear about the components of that chain. Its status matters before any technical detail does. The document is an Independent Submission published for informational purposes. It does not modify TLS, does not claim IETF consensus and does not establish a standard that a service operator has deployed. That does not make its design trivial. It means its design must be read at its stated scope: a framework for federation members to identify machine-to-machine TLS peers using a centrally managed trust anchor and controlled metadata publication. A document’s publication, like a signature, is a record with a defined meaning. It is not an audit of every system that could cite it.

The first record is federation metadata. RFC 9932 describes a federation operator that aggregates member information and publishes it as a JSON Web Signature. That aggregate can carry entity identifiers, endpoint information, pins, issuer material, issuance and expiry information, and rules by which members refresh their local stores. The signature matters. It lets a participant verify that a particular metadata object came from the signing authority it already trusts. But a valid signature only answers a question about that object and that key.

It does not answer whether the recipient downloaded the newest object, used it for this connection, selected the intended endpoint or still operates under the same local policy.

Freshness is therefore not decorative metadata. RFC 9932 requires rejection after exp, regardless of cache state, and places cache management inside the federation’s operating rules. That creates at least three separate observations: the time stated in the aggregate, the version held in a member’s local store and the version actually consulted by a connecting component. A dashboard that says “metadata valid” may be reporting only the first. It may say nothing about a stalled refresh, a missed key rollover, an unpreloaded replacement pin or a service that chose a different cache. A signature authenticates a statement; it does not make every copy of that statement current.

The second record is peer verification. Before a connection, a member preloads pins for endpoints it has selected or is prepared to accept. During the TLS exchange, each endpoint compares the public key in the peer certificate with a pin published in the federation metadata. A missing match requires the connection to end. This is a disciplined boundary: it can rule out a peer that fails the disclosed pin policy. It does not establish a successful session merely because a pin appears in a file. Nor does it establish what an application will permit after a session, even when the comparison succeeds.

A certificate key, a metadata pin and a network connection are related artifacts, not interchangeable names for authorization.

RFC 9932 makes that distinction visible at the intermediary boundary. If a proxy or other intermediary terminates TLS, the application cannot safely treat arbitrary HTTP headers or peer-supplied fields as the authenticated identity. The intermediary must either validate the pin itself or convey the certificate, derived pin or entity_id to the application over an integrity-protected, endpoint-authenticated channel. The document says that this information is propagated to enable authorization. The phrase is precise. It puts TLS-derived identity before, not inside, the application’s decision. An application still needs to decide whether this entity, acting now, may invoke this route, read this record, create this object or make this change.

That ordering has governance value as well as security value. It prevents the federation operator’s membership process from quietly becoming universal operational authority. A federation can define who may be named in its metadata. It can distribute a key, set refresh expectations and require a peer-verification rule. The resource owner or service operator still carries the cost of the request, the data exposure, the change and the failure. That party needs an explicit policy surface. It may use the resolved entity_id, organization claim or tag as an input. It must not relabel the input as the decision itself.

Key rotation shows why the layers cannot be compressed. RFC 9932 describes a sequence: a member adds a replacement pin to metadata, the operator republishes the signed aggregate, other members refresh and preload the new pin, the member changes its certificate, and only later is the old pin removed. This is not a single “rotate key” event. It is a dependency chain across publisher, cache, verifier and endpoint. A recorded publication does not prove propagation; a refreshed store does not prove a switched TLS stack; a successful handshake does not prove an authorized operation.

Treating those steps as one green status turns the first missing observation into an invisible outage or an unauthorized fallback.

The practical record should therefore preserve its nouns. Keep the signed aggregate and its issuer, expiry and hash. Keep the local-store version and refresh result. Keep the endpoint selected, the presented certificate or derived pin, the verification decision and the component that made it. If identity travels through an intermediary, keep the protected handoff boundary and the application’s source of identity. Then keep the application policy decision separately from the operation request, execution and observed effect. This is not bureaucratic excess. It is the shortest path back to a failure that otherwise becomes impossible to explain.

RFC 9932 does not say that federations are unsafe, that a central trust anchor is illegitimate or that pinning cannot support strong machine-to-machine relationships. It offers a method for a defined federation. Its warning, read carefully, is subtler: no method becomes more authoritative than the facts it actually verifies. A signed membership record can support a local identity check. It cannot sign away the service owner’s authorization responsibility.

Sources