TC-06 Domain boundary: the marketplace, the Agent Identity, and the layers between

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

Clarify the marketplace or catalogue role as the authoritative Agent registration and discovery channel, separate from Agent Identity and trust authority.

This is the first architectural question in the paper and it is the one every other objective inherits. If the boundary is drawn in the wrong place, TC-01 (registration triggers identity), TC-04 (lifecycle triggers revocation), TC-07 (orchestration across the two workflows) and TC-27 (capability envelope) all inherit the error.

2. The answer in one sentence

The marketplace is authoritative for the existence of an Agent. The Trust Controller is authoritative for the identity, the capability envelope and the lifecycle state of an Agent Identity. Neither is authoritative for the other's records, and the contract between them is the Agent Identity Manifest.

3. The four layer model

Taken from section 5 of the objectives paper and adopted without amendment. Every component in the demonstration is placed against exactly one of these layers.

  MARKETPLACE / CATALOGUE               TRUST CONTROLLER                 CONSUMING PLATFORMS
  authoritative for the Agent           authoritative for the            authoritative for their own
                                        Agent Identity                   runtime records

  ┌────────────────────────┐            ┌────────────────────────┐        ┌────────────────────────┐
  │  1  AGENT              │  manifest  │  2  AGENT IDENTITY     │ publish│  3  IDENTITY LAYER     │
  │                        │  ────────▶ │                        │ ──────▶│     CLIENT             │
  │  the product           │  lifecycle │  the governed identity │ resolve│     REPRESENTATION     │
  │  name, owner, purpose  │  events    │  capability envelope   │ withdraw                        │
  │  version, deployment   │            │  keys, lifecycle state │        │  the client record at  │
  │  discovery, catalogue  │            │  certification status  │        │  an authorization      │
  │  entry                 │            │                        │        │  server                │
  └────────────────────────┘            └───────────┬────────────┘        └────────────────────────┘
                                                    │                                  │
                                                    │ authorises                       │ binds
                                                    ▼                                  ▼
                                        ┌────────────────────────────────────────────────┐
                                        │  4  WORKLOAD LAYER REPRESENTATION              │
                                        │     the running instance, attested at runtime, │
                                        │     bound to the approved Agent Identity       │
                                        └────────────────────────────────────────────────┘

The Agent Identity Manifest is not a fifth layer. It is the contract between layer 1 and layer 2: a declarative document, emitted by the marketplace, that says an agent exists, who owns it, and what it claims to need. ID Partners owns the schema. In this demonstration it is a YAML file in git that drives the Connect API.

4. Why the layers are separate, and not one record

Three properties make collapsing them unsafe.

Cardinality is not one to one. One Agent has several Agent Identities, because development, test and production are different trust subjects and must fail independently. One Agent Identity has as many identity layer client representations as there are authorization servers it presents at, which in the CBA estate is several, because the estate is heterogeneous by acquisition and by division. One Agent Identity has as many workload representations as there are running instances, which at scale is thousands and changes by the minute. A catalogue record cannot carry a field for something that has a different cardinality, a different lifetime and a different owner.

Change velocity is not the same. A product description changes when marketing changes it. A capability envelope changes when a risk owner approves it. A client record changes when an authorization server is upgraded. An instance changes on every deployment. Putting them in one place forces the slowest approval onto the fastest change.

Accountability is not the same. The team that decides an agent should exist is not the team that is accountable for what it is permitted to do, and neither is the team that runs the authorization server. Section 5 of the paper names the identity platform team against layers 2, 3 and 4 and the agent platform team against layer 1, and that split is the reason the boundary exists at all.

5. Why the marketplace must not become the identity control plane

A catalogue would become a runtime dependency on the token path. If trust decisions read catalogue state, then every authorization server and every resource server needs a live path to the catalogue at the moment a token is issued. A product catalogue is not built to that availability profile, and the blast radius of an outage moves from "nobody can browse the agent list" to "nobody can transact".

There will be more than one catalogue. Internal build catalogues, vendor catalogues, cloud provider agent registries and customer built agents all arrive over the next two years. If identity is a property of the catalogue, CBA acquires one identity authority per catalogue and no single answer to "is this agent permitted, and who says so". The whole point of a Trust Controller is that the answer is singular and resolvable.

Catalogues are optimised for publication, control planes for withdrawal. A marketplace is designed to make it easy to add things. An identity control plane is designed to make it accountable to grant and immediate to withdraw. Those are different default postures and they should not share a permission model.

Marketplace records are assertions, not credentials. Nothing in a catalogue entry is signed in a way a third party can verify. An Agent Identity is published as a signed entity statement whose chain terminates at a trust anchor CBA controls. A consumer can verify it without trusting the transport, without an API key, and without asking CBA anything at runtime.

6. Why the Trust Controller must not become the marketplace

The mirror error is just as expensive, and vendors make it more often.

If the Trust Controller holds product descriptions, deployment targets, ratings, documentation links and discovery, then the identity platform team becomes the change bottleneck for every product edit, and CBA loses the ability to add or replace a catalogue without migrating its identity estate. Raidiam Connect deliberately does not do this. It records what is needed to make a trust decision, plus whatever additional attributes CBA chooses to attach for evidence purposes (TC-25), and it holds no opinion about how agents are discovered or marketed.

7. The test that decides which layer a field belongs to

One question resolves almost every boundary argument in a design review:

If the marketplace is offline, can a token still be issued, and can an agent still be revoked?

Both answers must be yes. Any data whose absence makes either answer no belongs in layer 2, published by the Trust Controller. Any data whose absence does not belongs in layer 1.

A second question resolves the layer 2 versus layer 3 boundary:

If this authorization server is decommissioned tomorrow, does this fact survive?

If it must survive, it is Agent Identity. If it dies with the server, it is a client representation.

8. How information flows, and in which direction

Nothing flows from a consumer back into layer 2. A consuming authorization server never becomes a source of truth about the agent, which is what makes withdrawal a single action rather than a distribution problem.

9. What this means for accountability, stated plainly

That last row is the commercial argument for the whole programme. Deleting a marketplace entry stops discovery. It does not stop a token being issued.

10. Evidence and artefacts

11. What we need from ID Partners

The marketplace half of this model is ID Partners' to confirm against the CBA estate. Specifically:

1. Which catalogue is in scope. Is CBA standing up a new agent marketplace, extending an existing service catalogue, or consuming a vendor or cloud provider registry? The answer changes who emits the manifest and how many emitters there will be.
2. The Agent Identity Manifest schema. ID Partners owns it. Raidiam's requirement is only that it carries a stable agent identifier, an owning organisation, an environment, a requested capability set and a change reason. Everything else is ID Partners' choice.
3. Where approval lives. Approval and rejection are external to the Trust Controller by design (see content-gap-register.md). ID Partners should confirm whether that is Jira, GitHub, Jenkins or a CBA specific workflow, because the manifest pipeline is built against it.
4. Whether a catalogue entry can exist without an Agent Identity, and the reverse. Both are legitimate states and the model above allows them. CBA should decide whether either is permitted as a steady state or whether both are exceptions to be reported.
5. The RACI for layer 1. Section 5 names the agent platform team. ID Partners should confirm the real team names inside CBA so the diagram carries their language, not ours.