TC-24 Gap register: what is not available out of the box

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

Implementation gap severity and internal build effort for capability not available out of the box.

2. How to read this document

This register is written first and deliberately. A vendor who lets a bank discover the gaps has already lost the argument about whether the rest of the answer can be trusted, and every gap below would be found inside a fortnight of a real proof of concept.

Three things are stated for every gap: what is missing, whether it is missing by design or by absence, and who has to close it. Where a gap is by design, the design reason is given, because "we chose not to build this" and "we cannot do this" are different statements and CBA is entitled to know which one it is looking at.

The register has two halves and they should not be read as the same thing. Section 3 is gaps, which is capability known to be absent. Section 4 is open verification items, which is capability we believe works but have not yet proven on the deployment in use. Section 4 is the shorter list and the more uncomfortable one, which is a reason to publish it rather than a reason not to.

Severity is severity to CBA's outcome, not to Raidiam:

Effort is an indication of CBA or delivery partner build effort, in the sense CBA asked for. It is not a quotation, a scope or a price. Anything requiring vendor services routes to ID Partners (content-commercial.md).

3. The register

3.1 Approval and rejection workflow is external, by design

Approval is a business process with a CBA specific control, evidence and audit requirement attached to it. Rebuilding that inside an identity product produces a second approval system that is worse than the one the bank already runs, sits outside the bank's existing control testing, and has to be separately evidenced to an auditor.

The correct boundary is that the Trust Controller exposes its entire state through an API, and the approval decision is taken wherever CBA already takes approval decisions: Jira, GitHub, Jenkins, or a CBA specific workflow. What the Trust Controller guarantees is that no state changes without an authenticated, attributed, versioned action, and that the resulting change history is complete.

How this is evidenced rather than asserted. Scene 01 runs a working governance pipeline: a manifest is committed, a pull request is opened, a merge applies the change to the Trust Controller through the API, and a rejected manifest produces a rejected outcome with a reason. The approval gate in that scene is a pull request review, which is a real approval control. Scene 07 carries a single correlation identifier from the committed manifest, through the change record, into token issuance and the resource server decision, which is what makes the externalised approval auditable end to end.

What CBA must decide: which system holds the approval, and what evidence that system must retain. The pipeline is built against that answer and the answer is CBA's, not ours.

3.2 The agent marketplace or catalogue is not a Raidiam product

content-domain-boundary.md sets out at length why the marketplace and the identity control plane must not be the same system, so this is a boundary rather than an omission. The consequence is nonetheless real: CBA needs a registration and discovery channel and it will not come from Raidiam.

The mitigating fact is that the interface between the two is narrow. The Trust Controller needs a stable agent identifier, an owning organisation, an environment, a requested capability set and a change reason. Anything that can emit that document can drive the Trust Controller, including a service catalogue CBA already runs. This is a deliberately low bar to clear.

3.3 The Agent Identity Manifest schema is not defined by Raidiam

There is no industry standard Agent Identity Manifest at the time of writing, and adopting a vendor specific one would be a lock in CBA should refuse. Raidiam's position is that the schema is CBA's to own and version.

What Raidiam demonstrates instead is that the receiving side does not constrain it: scene 08 records arbitrary attributes against a software statement, including owner, environment, version, repository link, software bill of materials reference and image digest, and reads them back. Whatever fields the manifest carries, the Trust Controller can hold them and return them, and they become part of the versioned change history.

Honest caveat: arbitrary attribute storage means the Trust Controller will not validate CBA specific manifest semantics for you. Validation of the manifest against its schema belongs in the pipeline, and scene 01 shows it there. Attributes stored as evidence are stored as supplied.

3.4 SPIFFE and SPIRE binding is an integration, not a product feature

Stated plainly: the Enhanced Vendor Demo does not integrate with SPIFFE or SPIRE and no claim is made that it does. Scene 11 shows the architecturally analogous mechanism, which is honest but is not the same thing. An agent provider attests a running instance, the instance authenticates with a client attestation grant, and the instance identity is bound to the approved Agent Identity that the Trust Controller published.

Why that is a credible basis for the integration rather than a substitute for it: the binding step takes an attestation from a source it trusts and joins it to a governed identity. A SPIFFE verifiable identity document is another attestation from another trusted source. The work to close the gap is teaching the binding to accept and verify that document and to map the SPIFFE identifier to the Agent Identity. That is integration work with a known shape, and ID Partners owns it.

What ID Partners must confirm for the CBA estate: which SPIRE deployment is authoritative, what the trust domain naming convention is, and whether the mapping from SPIFFE identifier to Agent Identity is one to one or many to one. None of these are known to Raidiam and none should be assumed.

3.5 The bridge to the existing authorization server estate is not Raidiam's to prove

This is the biggest gap in the register and it deserves to be labelled as such. content-federation-bridge.md sets out the federation surface Raidiam publishes and the integration design against it, and content-overlay-compatibility.md sets out the questions ID Partners must answer about the estate.

Two things are true at once and both should be stated. ID Partners confirmed on 6 August 2026 that it has a module which walks the trust chain, which is a materially better starting position than a blank page. And Raidiam has not tested that module, has not seen the CBA authorization server estate, and will not claim compatibility it has not observed. What Raidiam demonstrates is the other half: an authorization server that has never seen an agent resolving it through the federation and issuing a token, with no pre shared client record anywhere (scene 04). The reference implementations in that scene stand in for the CBA estate; they are not the CBA estate.

3.6 Policy enforcement at the resource server is a CBA responsibility

Scenes 03 and 05 show enforcement working: a resource server publishes what it requires, an agent resolves that requirement, obtains a token, and is admitted or refused with the reason rendered. Those resource servers are reference implementations built for this demonstration. They show what enforcement looks like against a resolvable capability envelope; they are not a product CBA receives.

The gap is therefore real but bounded: the enforcement logic is short, because the envelope arrives already resolved and already trustworthy, and the work is repeating it at each enforcement point rather than inventing it once.

3.7 The Trust Controller publishes trust state, it does not compute risk

The Trust Controller answers "is this agent approved, what is it permitted to do, and is it still permitted". It does not answer "does this particular request look wrong". Those are different questions with different latency, different data and different owners, and conflating them is how identity platforms end up owning fraud outcomes they cannot influence.

The connection between the two is available and is a strength rather than a gap: a risk platform that decides an agent should stop can suspend it in the Trust Controller, and scene 06 shows that suspension propagating along three paths with a stopwatch running. Risk decides. The Trust Controller enforces and distributes.

3.8 Ecosystem trust for unmanaged external agents is deferred

The demonstration models one external partner agent provider, trusted into CBA by federation alone, and ConnectID as a cross recognised peer. That proves the mechanism works across an organisational boundary. It does not prove CBA has an answer for an agent from a party it has never accredited, and no such claim is made.

3.9 Security event delivery into CBA's monitoring estate is integration work

content-observability.md covers what is emitted. The gap is only the last hop, and CBA's monitoring platform, its ingest format and its retention requirement are all things ID Partners must confirm for the CBA estate rather than things Raidiam should assume.

3.10 The Enhanced Vendor Demo integrates with nothing of CBA's

Stated so that nothing in the demonstration is mistaken for an integration result. Every non Raidiam runtime component in the demonstration is labelled as a reference implementation standing in for a CBA system, and the estate model is watermarked as illustrative. What the demonstration proves is that the mechanism works end to end against real services. What it does not prove is that it works against CBA's services, and the register should not be read as if it did.

4. Open verification items

These are a different class from section 3 and are separated deliberately. A gap is something known to be missing. An open verification item is something we believe works, that has not yet been proven on the deployment being used, and that would change the answer if it turned out not to. A bank is entitled to know which of a vendor's claims are load bearing and still untested.

4.1 Capability envelope projection into the published statement

The claimed mechanism: a capability envelope is expressed as metadata rows against a governed role, and those rows are applied as OpenID Federation metadata policy in the subordinate statement the authority issues about the subject. That is what makes the envelope governable independently of OAuth scopes and independently of runtime client configuration, which is precisely what TC-27's acceptance criteria demand.

What was actually observed on the CBA directory instance on 10 August 2026, by read only survey and then independently confirmed a second time: one role exists, it carries one metadata row, that row is Active on the organisation's authority claim, and it does not appear in the subordinate statement issued for the subject. The statement emits empty policy buckets for federation_entity, openid_provider and openid_relying_party, and no bucket at all for oauth_authorization_server, which is the entity type the row is written against.

Two explanations fit that observation and a read only survey cannot separate them. Either the statement builder does not emit policy for that entity type, or policy buckets are populated only once the subject publishes a retrievable entity configuration, and this subject's is unretrievable (see 4.2). The first would be a product limitation. The second would mean the mechanism is sound and the observed case was simply never a valid test of it.

The test that settles it, and it is a small one: create a role with a metadata row against EntityType: openid_relying_party, assign it to a subject that publishes a valid entity configuration, and fetch the subordinate statement. If the row appears in the policy, the mechanism works and this item closes. If it does not, the envelope needs a different delivery path, and that is a design change rather than a configuration change.

That test requires a write, and as at 10 August 2026 it has not been run. Until it has been run and the result seen, no claim is made anywhere in this response that a capability envelope expressed as directory role metadata reaches the wire. Everything written about metadata policy in content-target-state.md, content-federation-bridge.md and content-commercial.md states the mechanism as designed and should be read against this item.

4.2 The demonstration federation is being built from empty

As at 10 August 2026 the CBA directory instance holds two federations, one organisation, one role, one software statement, no authorisation servers, no certificates and no resolvable entity at all. The single existing leaf serves an HTML page at its federation well known location instead of a signed statement, so resolution fails for it, correctly and for the leaf's own reason.

Nothing in this response should be read as extending an already working CBA federation. What already runs in production, in Australia, is the same platform under ConnectID, and that remains the proof point that this is production technology rather than a prototype. The CBA federation itself is new, and the distinction matters enough to state rather than blur.

The practical consequence is that there is no working local reference to copy, so each mechanism is being proven for the first time rather than by imitation of a working sibling. This is being managed by automating the wiring from the first day rather than configuring by hand, so that a failure costs a re run rather than a morning.

4.3 Two of the fifteen evidence documents are frames, not answers

Both documents open by saying they are a frame. That is the correct and honest treatment, because both depend on facts about the CBA estate and the in region operating model that Raidiam does not hold and should not invent. It is recorded here so that the response is not read as though fifteen objectives were answered when thirteen were.

5. Things that look like gaps and are not

Each of these has been raised as a gap in a review at some point. Each has an answer that can be shown on screen, which is why they are recorded here rather than in section 3.

6. What the register means for the programme

Ordered by what would delay CBA rather than by severity.

1. The capability envelope projection test (4.1) is the most urgent single action, and it is the smallest. It is hours of work, it settles whether TC-27's delivery mechanism holds, and everything written about metadata policy across this response depends on the answer. It should be run before anything else is built on top of it.
2. The bridge to the existing authorization server estate (3.5) is the critical path. It is the only gap whose size is genuinely unknown, and it is unknown because nobody has surveyed the estate yet. content-overlay-compatibility.md is the survey instrument and it should be answered early.
3. The manifest schema (3.3) blocks the registration workflow. It is not difficult, but it needs a decision from CBA and ID Partners before the pipeline can be built against it in anger.
4. The approval system decision (3.1) is a CBA choice that nobody is currently making. The pipeline is built against whichever answer is given, and the answer is cheap to give.
5. Everything else is closable in parallel, and none of it blocks a proof of concept from starting.

7. What we need from ID Partners

1. Sizing of 3.2, 3.5 and 3.4 against the real CBA estate. Raidiam's effort indications for those rows are informed guesses about systems Raidiam has not seen, and should be replaced rather than adopted.
2. Confirmation or correction of the SPIFFE and SPIRE questions in 3.4.
3. Confirmation of CBA's monitoring platform and ingest requirement for 3.9.
4. Any gap ID Partners has found that is not in this register. A gap register that is only as honest as the vendor's own visibility is not honest enough, and Mina's own objective analysis is the natural place for the corrections to come from.

8. Status

Authored. This register is deliberately more complete than CBA asked for, and it should be presented early in the session rather than left to questions. Any gap discovered after publication is added here rather than defended.