TC-13 Deployment model options and CBA boundary implications

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

Deployment model options and CBA boundary implications.

2. The answer in short

Raidiam Connect is delivered as software as a service on Amazon Web Services. For Australian customers it runs in the Sydney and Melbourne regions. It is a single cloud product today: AWS only, with no multi cloud or on premises deployment option. Where data sovereignty or data residency requires the customer to hold the data store, there is a bring your own Postgres option in which CBA operates the database inside its own AWS account and Raidiam operates the processing layer against it over private connectivity.

3. The deployment options

The AWS region identifiers for the chosen deployment are fixed in the deployment design rather than assumed here. Both options are the same product and the same code path. Option B changes where the data sits and who holds it, not how the platform behaves.

Anything beyond these two shapes, including dedicated tenancy, additional regions or a non AWS target, is a commercial and roadmap question and routes to ID Partners.

4. The shared responsibility boundary

                      OPTION A                              OPTION B
                   managed service                  bring your own Postgres

   ┌───────────────────────────────────┐   ┌───────────────────────────────────┐
   │  CBA                              │   │  CBA                              │
   │   federation content and estate   │   │   federation content and estate   │
   │   model, roles, approvals         │   │   model, roles, approvals         │
   │   who may administer, via SSO     │   │   who may administer, via SSO     │
   │   signing key custody (KMS)       │   │   signing key custody (KMS)       │
   │   consuming systems and their     │   │   consuming systems and their     │
   │   client representations          │   │   client representations          │
   │                                   │   │   ── the database ──              │
   │                                   │   │   host, encrypt, back up, restore │
   │                                   │   │   network path to the processing  │
   │                                   │   │   layer                           │
   ├───────────────────────────────────┤   ├───────────────────────────────────┤
   │  RAIDIAM                          │   │  RAIDIAM                          │
   │   application and its operation   │   │   application and its operation   │
   │   platform patching and upgrade   │   │   platform patching and upgrade   │
   │   availability and monitoring     │   │   availability and monitoring     │
   │   infrastructure security         │   │   infrastructure security         │
   │   the database and its backups    │   │   schema, migrations, and the     │
   │                                   │   │   restore requirements CBA meets  │
   └───────────────────────────────────┘   └───────────────────────────────────┘

The row that matters most in a boundary review is the third from last. CBA decides what is published and what is withdrawn. The platform enforces those decisions and records them; it does not make them.

5. Boundary implications for CBA

What crosses the boundary outbound, deliberately. Entity configurations, subordinate statements, trust marks and their status are served publicly and without authentication, because a federation whose statements cannot be fetched by a consumer is not a federation. Publication is the product. This is a deliberate design position and the reasoning is set out in content-data-protection.md and content-network-architecture.md: those documents are signed, read only and carry public trust metadata, so the control is the signature, not the transport or the network.

What does not cross. The administrative plane. Who proposed a change, who approved it, who administers, and the change history are behind authenticated access, and the identities are CBA's own through single sign on.

What CBA must provide. For option A: identity provider integration for administrator single sign on, and a key management service key for the bring your own key signing path if that path is used. For option B: an AWS account and VPC for the database, the peering or VPN, and the database operational service.

What CBA does not have to provide. No inbound path into the CBA network. The Trust Controller does not call into CBA. Consuming authorization servers call out to fetch federation statements, which is an outbound HTTPS pattern, and shared signal delivery can be pushed to a CBA endpoint or polled by CBA, whichever CBA's network standards prefer.

6. The Enhanced Vendor Demo is not the deployment model

Stated plainly so it is not mistaken for one. The demonstration on 24 August 2026 is vendor hosted, uses synthetic data only, integrates with no CBA system, touches no CBA network and carries no contract dependency. The reference authorization servers and resource servers built for it are deployed on demonstration hosting behind *.cba.raidiam.io, which is convenient for a demonstration and is not the product deployment model described above. Every non Raidiam runtime component in the demonstration is labelled as a reference implementation standing in for the CBA estate.

The deployment boundary question therefore does not bind until the Formal Proof of Concept, at which point the option A or option B decision is made and the network and account work follows it.

7. What we need from ID Partners and CBA

1. Which option CBA requires: managed service, or bring your own Postgres. The answer is usually driven by a data residency or custody control rather than by a technical preference, so the control should be named.
2. If option B, which AWS account and VPC, and whether CBA's standard is peering, site to site VPN or something else.
3. The region pair, and whether both are required or one is sufficient.
4. Whether CBA requires the administrative interface to be reachable only from the CBA network, which is a constraint to design for rather than retrofit.
5. Which CBA identity provider fronts administrator single sign on.
6. Environment count for the Formal Proof of Concept: how many non production environments, and whether each needs its own trust anchor.

Commercials for any of the above route to ID Partners.