TC-09 Federation bridge for existing authorization servers
| Objective | TC-09 |
| Evidence level | Evidence, Integrate |
| Domain | Compatibility fit |
| Owner | ID Partners owns the Ping Federate bridge. Raidiam owns the federation surface it consumes. |
| Phase | Formal Proof of Concept |
| Proven by | content-federation-bridge, with scene 04 demonstrating the consuming half against a conformant authorization server |
On what is claimed here. Where this document describes the demonstration, it states what the Enhanced Vendor Demo of 24 August 2026 is built to prove, not what has already been built, recorded or verified. Status for every scene is tracked in objectives/tc-objectives.yaml.
1. What CBA asked for
Federation bridge capability for existing authorization servers, including trust chain resolution, client metadata resolution and dynamic client onboarding for Agent Identities.
Three distinct capabilities. They are usually discussed as one, and they fail for different reasons, so they are answered separately below.
2. Where the line falls between us
The bridge has two halves and they are owned by different parties.
| Half | What it is | Owner |
|---|---|---|
| The federation surface | Everything a consumer needs in order to resolve an Agent Identity: entity configurations, subordinate statements, metadata policy carrying the capability envelope, trust marks, a status endpoint, and a resolve endpoint at the trust anchor | Raidiam. Built, running, and demonstrated. |
| The consuming bridge | The component that sits with the existing authorization server, resolves the chain, maps the resolved metadata onto that product's client model, and keeps it current | ID Partners. Mina confirmed on 6 August 2026 that ID Partners has a module that walks the trust chain. |
Raidiam's side does not change per authorization server product. There is exactly one federation surface and every consumer resolves the same way. All product specific work is on the consuming side. This is worth stating early in the room, because it is the difference between a compatibility matrix with one row per product on CBA's side and a matrix with one row per product on the vendor's side.
3. Capability one: trust chain resolution
An Agent Identity publishes an entity configuration at its entity identifier, at /.well-known/openid-federation, signed by a key whose private half can be held in CBA's own key management service (TC-26). The entity configuration names its authority. The authority publishes a subordinate statement about it, carrying the authoritative key set and the metadata policy. The chain terminates at the CBA Group trust anchor.
A consumer has three ways to obtain the resolved result, in increasing order of independence:
| Option | What the consumer does | What it needs to implement | When to choose it |
|---|---|---|---|
| A. Ask the anchor to resolve | Calls the trust anchor's resolve endpoint with the subject and the anchor identifier, receives a resolved entity statement | An HTTP client and one signature verification against the anchor key | Fastest route to a working integration. Reasonable for an authorization server with no federation support and a bridge that runs alongside it. |
| B. Walk the chain | Fetches the leaf, follows the authority hints, fetches subordinate statements, verifies each signature, applies metadata policy in order | A federation client. This is what ID Partners' module does. | Where the consumer must not depend on the anchor being reachable on the request path, or must apply its own policy on top |
| C. Native resolution in the authorization server | The authorization server itself resolves at request time and treats the resolved metadata as the client record for the duration of the request | OpenID Federation support in the product | The target state. See content-target-state.md. |
Option A is not a lesser form of federation. The resolved statement is signed by the anchor, so the consumer still verifies rather than trusts. What it gives up is independence from the anchor's availability at request time, which is a legitimate trade for a first integration and a poor one for a steady state.
Fail closed is the default and must stay the default. If the chain cannot be built, or a signature does not verify, or the anchor cannot be reached and no valid cached resolution is in date, the answer is refusal, not admission. Where a bridge is configured to fail open, that is a decision with a named owner, not a default.
4. Capability two: client metadata resolution
This is where the capability envelope lives, and it is the part most often misunderstood as "the directory hands over a JSON blob".
Roles in the directory carry metadata rows. When a role is granted to an Agent Identity, those rows are applied as federation metadata policy in the subordinate statement issued by the authority. Policy from multiple roles is combined, and the result is applied to the leaf's own declared metadata during resolution. The consumer therefore receives client metadata that:
- is derived from governed roles rather than authored by hand against each authorization server,
- is cryptographically bound to the chain, so a consumer can prove the anchor asserted it,
- unions across roles, so granting a further capability is a role grant rather than an edit to a client record, and
- is versioned by the platform, so every change to the envelope has a record and an actor (TC-27).
The practical consequence for the bridge: the bridge does not invent client metadata. It maps the resolved metadata onto the target product's client model. Everything the bridge cannot express is a documented loss, and the list of losses is the compatibility finding, not an implementation detail.
One honest qualification on this section. Whether role metadata rows project into the subordinate statement as described has not yet been proven on the CBA directory instance, and a read only survey on 10 August 2026 observed a case where a row did not appear. It is recorded as open verification item 4.1 in content-gap-register.md, along with the specific test that settles it. The design above is the mechanism as intended and as documented; it should not be read as an observation until that test has been run.
Typical mapping targets and the questions each raises are listed in section 8.
5. Capability three: automatic and dynamic client onboarding
OpenID Federation defines two registration styles, and the bridge pattern is a third that exists only because products lag the specification.
| Style | How a client comes into existence | Persisted record? | Withdrawal takes effect |
|---|---|---|---|
| Automatic registration | The agent presents its entity identifier as the client identifier in the authorization request. The authorization server resolves the trust chain and derives the client metadata at request time. | None required | On the next request |
| Explicit registration | The agent calls the authorization server's federation registration endpoint presenting its signed entity configuration. The server returns a registration response. | Yes | When the record is removed or re resolved |
| Bridge provisioning (the overlay) | A component resolves the chain out of band and creates, updates or disables a native client record through the authorization server's own administration API, keyed on the entity identifier | Yes, and it is a cached copy | When the bridge next runs, or on a pushed signal |
Automatic registration is the shape that makes the architectural argument: an agent presents at a server that has never heard of it, and is admitted on the strength of the chain alone. Scene 04 demonstrates exactly this against a conformant reference authorization server, deployed for the demonstration and labelled as a reference implementation standing in for the CBA estate. No pre shared client record exists anywhere in that scene.
The honest limitation of the overlay
Bridge provisioning reintroduces the thing federation removes: a copy of the truth, held by a consumer, which can be stale. Withdrawal latency is then bounded by the bridge's refresh policy and the authorization server's token lifetime, not by the Trust Controller. This is not a defect in the bridge. It is the definition of a cache, and it should be designed rather than discovered.
Three mitigations, used together, hold the gap to something a risk owner will accept:
- A bounded maximum age on any cached resolution, chosen deliberately and enforced, so the worst case is known rather than unbounded.
- A pushed shared signal (Secure Event Token delivery over HTTP, RFC 8935) so a withdrawal reaches subscribed consumers immediately rather than at the next refresh. Demonstrated in scene 06.
- A status check at presentation (OAuth token status list) so a consumer that subscribes to nothing still fails on the next presentation of an already issued token. Also scene 06.
Scene 06 races all three against a stopwatch on screen, because the acceptance criteria for TC-04 ask about timing and tolerance of stale metadata, and the only credible answer is a measured one.
6. What Raidiam demonstrates in the Enhanced Vendor Demo
| Artefact | Shows | Status |
|---|---|---|
| Scene 04, dynamic onboarding | Automatic registration end to end: agent presents at an authorization server with no record of it, the server resolves through the federation and issues a token | To be recorded |
| Live federation endpoints | Entity configuration, subordinate statement, resolve, trust mark and trust mark status, fetched on screen | To be recorded, scene 02 |
| Metadata policy from roles | A capability role changed, and the resolved client metadata changing for a consumer, with the Agent Identity record untouched | To be recorded, scene 10 |
| Withdrawal propagation | Publication withdrawn, shared signal pushed, status list flipped, timed | To be recorded, scene 06 |
The specification revision we implement is recorded in the integration design supplied with the bridge, not asserted here. It is a version fact, it changes, and it should be read from the artefact.
7. What ID Partners owns
The Ping Federate side, and the Entra side, against the real CBA estate. This is deliberately not in the Enhanced Vendor Demo: it belongs to the Formal Proof of Concept, and David was explicit on 6 August 2026 that the compatibility work belongs in the second presentation.
Raidiam supplies: the federation surface, the written integration design, the endpoint contracts, the key rotation semantics, the trust anchor key distribution model, and a conformant reference consumer that ID Partners can test their module against before touching CBA infrastructure.
8. What we need from ID Partners, as a worklist
These are the questions that decide whether the bridge is a configuration exercise or a build. They are listed so David and Mina receive a brief rather than a blank page.
Product and deployment
- Which Ping Federate versions are in the estate, how many deployments, and who operates each.
- Whether the relevant federation or plugin capability is licensed on those deployments.
- Whether Entra is in scope for agent identities at all, or workforce only.
Resolution
- Does the module resolve on the request path, or on a schedule out of band? If on the request path, what is the latency budget for an authorization request, and what is the timeout?
- What is the caching model, what is the maximum age, and is it shared across replicas or per process? A per process cache where a shared one was intended is a recurring source of production surprise.
- What happens when resolution fails: fail closed, fail open, or serve the last known good, and until when? Where is that configured, and who owns the setting?
- How is the trust anchor key distributed to the module, and what is the rotation procedure?
Client model mapping
- Can the product accept an entity identifier as a client identifier, which is what automatic registration requires?
- Can the client record carry a key set by reference rather than by value, so key rotation at the Agent Identity does not require a write to every authorization server?
- Can it express a DPoP binding requirement, and mutual TLS binding where used?
- Can it express Rich Authorization Requests detail types, which is how the capability envelope is enforced at the token endpoint?
- Can it carry arbitrary additional metadata, so evidence pointers from the manifest survive the mapping (TC-25)?
- Which parts of the resolved metadata cannot be expressed, and what is lost. This list is the compatibility finding.
Lifecycle
- What administration API is used to create, update, disable and delete a client, what authenticates to it, and what privileged access controls wrap that credential (see
content-access-controls.md)? - What is the primary key of the client record, and is it stable across a re resolution?
- Is disable distinct from delete, and does disable take effect on already issued tokens?
- What is the access token lifetime on those deployments? Withdrawal latency cannot be shorter than the token lifetime unless there is introspection or a status check at the resource server.
- Can the deployment subscribe to a shared signal stream, or must withdrawal be polled?
Precedence
- Where a bridge provisioned client record and an entity's own signed statement could both exist for the same identifier, which wins? This must be set deliberately at each deployment. Left at a product default it can allow a record authored by a third party to outrank a statement the entity signed about itself, which is the opposite of the intended trust direction.
9. Status
Not built for the Enhanced Vendor Demo, and deliberately so. The consuming half of the capability is demonstrated against a conformant reference authorization server in scene 04. The CBA specific bridge is Formal Proof of Concept work owned by ID Partners, with the questions above as its starting brief.