TC-12 Overlay compatibility with the current enterprise authorization server landscape
| Objective | TC-12 |
| Evidence level | Evidence, Integrate |
| Domain | Compatibility fit |
| Owner | ID Partners. This document is the frame and the question set, not the answer. |
| Phase | Both, with the substantive assessment in the Formal Proof of Concept |
| Proven by | content-overlay-compatibility |
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
Overlay compatibility with the current enterprise authorization server landscape.
2. Why this document is a frame rather than an answer
Compatibility is a property of the CBA estate, not of the Trust Controller. It is assessed per product, per version, per deployment, against real configuration, by the party with access to that configuration. That party is ID Partners, and David was explicit on 6 August 2026 that this assessment belongs in the second presentation rather than the Enhanced Vendor Demo.
Producing a confident compatibility matrix from outside CBA would be inference presented as fact. The useful contribution instead is the frame it should be assessed against, and the questions whose answers determine the result. Those are set out below so ID Partners begins with a worklist.
3. The frame
Overlay compatibility means one thing: the existing authorization servers keep issuing tokens exactly as they do today, while the Trust Controller becomes authoritative for who an agent is and what it may do. No application changes, no agent changes, no re platforming.
Compatibility is therefore assessed on three questions per deployment, and only three:
- Can it learn? Can this authorization server come to hold a correct client representation of an Agent Identity, derived from the federation, without a human authoring it?
- Can it express? Can its client model carry everything the resolved metadata asserts, and if not, what is lost?
- Can it forget? When the Trust Controller withdraws, how quickly does this deployment stop honouring the agent, and what is the worst case?
Question three is the one that decides the risk position, and it is usually answered last.
Raidiam's side is constant across every row of the resulting matrix. There is one federation surface and every consumer resolves it the same way, whether by asking the trust anchor to resolve, by walking the chain, or natively. The mechanics are in content-federation-bridge.md.
4. The compatibility matrix template
One row per authorization server deployment, not per product. Two deployments of the same product at different versions, with different licensing or different operators, are different rows.
| Column | What it records |
|---|---|
| Deployment | Name, brand or division served, operator, environment |
| Product and version | Including patch level where it matters to the capability |
| Population | Customer facing, workforce, internal service to service |
| Accepts an entity identifier as a client identifier | Yes, no, or with configuration. This decides whether native automatic registration is reachable at all. |
| Federation capability present | Native, module or plugin, none |
| Administration API for client lifecycle | Present, authentication method, rate limits, create, update, disable, delete |
| Key set by reference | Can the client record point at a key set URL rather than embed keys? This decides whether key rotation is one write or many. |
| Sender constrained tokens | DPoP, mutual TLS, neither |
| Rich Authorization Requests | Supported detail types, or scopes only |
| Arbitrary client metadata | Can evidence pointers from the manifest survive the mapping (TC-25)? |
| Client attestation grant | Supported, for instance binding (TC-28) |
| Disable semantics | Does disable affect already issued tokens, or only new ones? |
| Access token lifetime | The floor on withdrawal latency unless there is introspection or a status check |
| Refresh token policy | Whether a withdrawn agent can extend its own access |
| Introspection at the resource server | Present and used, present and unused, absent |
| Shared signal consumption | Can it subscribe to a security event stream, or must withdrawal be polled? |
| Behaviour when the trust anchor is unreachable | Fail closed, fail open, serve last known good and until when |
| Logging | Does it emit enough to answer "why was this agent admitted or refused" (TC-18)? |
| Losses | What the resolved metadata asserts that this deployment cannot express |
| Withdrawal worst case | A measured number, in seconds, from withdrawal at the Trust Controller to refusal at this deployment |
The last two columns are the deliverable. Everything above them is working.
5. Estate scope to confirm
The demonstration models a heterogeneous estate deliberately: a shared enterprise authorization server, segment specific servers inherited from legacy and acquisition history, a separately operated subsidiary, and a workforce server. That model is watermarked as illustrative. The real inventory is ID Partners' to establish, and should cover at least:
- Ping Federate deployments: how many, which versions, operated by whom.
- Microsoft Entra: whether it is in scope for agent identities or workforce only.
- Anything inherited with Bankwest, ASB and CommSec that is not on the strategic platform.
- Any authorization server embedded in a platform rather than run as one, for example an API gateway issuing its own tokens.
- Non production environments, because an agent identity per environment is the model and the transition has to work in development before it works in production.
6. Questions ID Partners must answer
Numbered so they can be worked and reported against.
Inventory and ownership
- The deployment inventory as above, with an accountable operator per deployment.
- Which deployments will host agent traffic in the first twelve months, and which are out of scope.
- Change control route and lead time for a client model change on each deployment.
Capability
- For each deployment, the answers to every row of the section 4 matrix.
- Which deployments can reach stage 3 native resolution on their current version, which need an upgrade, and which have no path.
- Whether the federation module ID Partners holds is supported across all Ping versions in the estate.
Enterprise change required
- What has to change on the CBA side to run the overlay: administration credentials, network paths to the federation endpoints, egress rules, certificate trust, monitoring integration.
- Whether outbound access from an authorization server to a public federation endpoint is permitted under CBA's current network standards, and if not, what the pattern is.
- Who owns the bridge component in production once it exists, and where it runs.
Risk position
- The measured withdrawal worst case per deployment, and whether the risk owner accepts it.
- Whether any deployment fails open on resolution failure today, and whether that is acceptable.
- What happens to in flight sessions and issued refresh tokens when an agent is withdrawn.
7. What Raidiam supplies to support this work
- The federation surface, unchanged across every row of the matrix.
- The written integration design: endpoint contracts, resolution semantics, metadata policy application, key rotation, trust anchor key distribution.
- A conformant reference authorization server that ID Partners can test a bridge against before touching any CBA infrastructure, so integration defects are found outside the change control path.
- Scene 04 as a working demonstration of the native end state on a conformant consumer.
8. Status
Not assessed, by agreement, and owned by ID Partners for the Formal Proof of Concept. This document is the brief.