TC-11 The OpenID Federation target state, and the transition to it

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

Validate the strategic OpenID Federation target state by operating as the authoritative Trust Controller for Agent Identity trust publication, while demonstrating a credible transition from the near term overlay deployment model to native federation.

Two claims are being tested. First, that the target state is real and not a roadmap. Second, that there is a route from where CBA is today to where CBA wants to be, that does not require a leap.

2. The answer, stated directly

Raidiam Connect is already native. It publishes OpenID Federation entity configurations, subordinate statements, metadata policy and trust marks today, in production, in Australia, for a scheme CBA is already a member of. The transition described below is therefore about CBA's authorization servers, not about Raidiam's roadmap. Nothing in the Trust Controller changes between the overlay stage and the native stage, which is the single most important property of the plan: the authoritative source is stood up once and never re platformed.

3. What the native target state is

The last two rows are the ones that change how the estate feels to operate. There is no distribution list, no purge, no "who else has a copy", and no per authorization server onboarding backlog.

The table above describes the target state as designed. One row in it is not yet an observation: whether role metadata rows are applied as metadata policy in the published statement has not been proven on the CBA directory instance, and it is recorded as open verification item 4.1 in content-gap-register.md with the test that settles it. It is called out here rather than left for a reader to assume, because it is the row the capability envelope depends on.

4. The transition, in four stages

The stages are defined by what the consuming authorization server does, because that is the only thing that changes.

Stage 0. Where the estate is today

Client records are configured by hand or by ticket, per authorization server, per environment. There is no common answer to who owns an agent, what it may do, or how to turn it off everywhere. This is the problem statement, recorded here so the transition has a starting point.

Stage 1. Overlay. The Trust Controller becomes authoritative, consumers are unchanged

Raidiam Connect holds and publishes every Agent Identity. A bridge component resolves the trust chain and provisions native client records into the existing authorization servers through their own administration APIs (see content-federation-bridge.md). No authorization server is upgraded, no application is changed, and no agent notices.

What is gained immediately: one authoritative source, one governed capability envelope, one place to approve and one place to withdraw, a complete change history, and a real answer to "how many agents are there and who owns them".

What is not yet gained: withdrawal is not instantaneous, because the consumer now holds a copy. Latency is bounded by the bridge refresh policy plus the access token lifetime. Mitigated by a bounded maximum age, a pushed shared signal, and a status check at presentation, all three demonstrated in scene 06. This is the honest cost of stage 1 and it should be written into the design as a stated number rather than left as an assumption.

Stage 2. Hybrid. Some consumers go native, most do not

New authorization server deployments, and any product that already supports federation, resolve directly. Everything else stays on the bridge. Both consume the identical federation surface, so there is no migration event, no dual publication and no reconciliation. An authorization server moves from stage 1 to stage 3 individually, on its own upgrade cycle, without coordination across the estate.

This stage is likely to last years in an estate the size of CBA's, and that is fine. The design is built for it rather than tolerating it.

Stage 3. Native. Consumers resolve at request time

The authorization server accepts an entity identifier as a client identifier, resolves the chain, applies metadata policy, and issues a token, holding no persisted client record. Withdrawal takes effect on the next request. The bridge is decommissioned for that deployment.

What each stage requires, and from whom

The first column is the argument. Raidiam's deliverable does not change across the transition.

5. Deviations from the standards, stated explicitly

CBA asked for deviations to be explicit. These are the ones we know about. Where a statement is a live observation it carries the environment and the date it was verified, because the correct status of a product limitation is a fact with a timestamp, not an opinion.

1. Directory entity type modelling. The directory models participants as organisations, authorisation servers and software statements. Several OpenID Federation entity types are not first class in that model today, so an entity of one of those types is registered as an authorisation server and describes itself correctly in its own published entity configuration. Verified on a live Raidiam operated directory on 3 August 2026. For agent identities this is not on the critical path: an Agent Identity is a relying party and the software statement is the correct shape for it. It is recorded here because it is real, it is visible to anyone who inspects the register, and it should be read from us rather than discovered.

2. Subordinate listing filters. The specification allows a subordinate list to be filtered by entity type and by trust mark. Filtering by entity type works. Filtering by trust mark is not supported today, so a query of the form "every Agent Identity holding this certification" is answered either by walking the list or by asking the authority per subject. Verified on a live Raidiam operated directory on 3 August 2026. At the agent population CBA is planning for, this is a query CBA will want, and it is listed in the gap register.

3. Trust marks carry an issued at time and no expiry, and no claims body. An issued mark is iat, iss, sub and trust_mark_type, and nothing else. Verified on a live Raidiam operated directory on 3 August 2026, and confirmed again on the CBA directory instance on 10 August 2026.

Two design consequences follow, and both are rules for every consumer rather than things a consumer can be left to discover.

Non renewal is not a withdrawal mechanism, because nothing ages out on its own. Withdrawal is enforced by the issuance guard and by the trust mark status endpoint. So: check trust mark status live at the issuing authority, do not read accreditation out of a published entity configuration. Marks published in a leaf can lag the authority's view, and a consumer that reads the leaf can reach a conclusion the authority does not hold.

A capability envelope cannot ride inside a trust mark, because a mark has no claims body to carry one. A mark asserts that a subject holds a domain role, and nothing more. Capability is delivered as federation metadata policy applied during resolution, which is the correct separation anyway: a capability change does not invalidate an accreditation, and an accreditation change does not silently rewrite a capability. So: a consumer that needs the capability envelope at call time must resolve, not merely read marks. Whether that policy projection is working on the CBA instance is an open verification item, recorded as 4.1 in content-gap-register.md.

4. Registration precedence must be set deliberately. Where a client record authored by the register and a statement the entity signed about itself could both exist for the same identifier, precedence is a deployment setting at the consuming provider. It should be configured so that an entity's own signed statement outranks a record authored about it, with the record as a fallback. This is a configuration decision with a named owner, not a default to be inherited.

5. Publication is public, by design. Entity configurations, subordinate statements and trust marks are served without authentication, because a federation whose statements cannot be fetched is not a federation. This is a deliberate deviation from the enterprise default of authenticating everything, and it is safe for a specific reason: the statements are signed, read only, and carry public trust metadata. See content-data-protection.md.

6. Key algorithm profiles. The platform supports RSA, elliptic curve and ML-DSA profiles for its public key infrastructure. Which profile is in use for federation signing in a given environment is an environment fact, recorded against scene 09 for the demonstration environment, and confirmed per environment during wiring rather than asserted here.

7. Approval workflow is not in the product. By design. See content-gap-register.md, gap 1.

6. Evidence

7. The one thing to hold on to

The transition is a property of CBA's consumers, not of the Trust Controller. That means the sequencing risk sits with work CBA and ID Partners control and can schedule, and there is no vendor roadmap dependency anywhere on the path from stage 1 to stage 3.