TC-23 Commercial and procurement implications
| Objective | TC-23 |
| Evidence level | Evidence |
| Domain | Commercial and procurement fit |
| Owner | ID Partners, as reseller. Raidiam supplies the capability inventory only. |
| Phase | Enhanced Vendor Demo |
| Proven by | content-commercial |
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
Commercial and procurement implications of the solution and deployment model.
2. The position
Commercials route to ID Partners. ID Partners is the in region reseller and the contracting party. Licensing, pricing, contract structure and procurement route are theirs to state and CBA's to negotiate. Nothing in this document, in the demonstration, in the narration or in any diagram scopes or prices anything.
Raidiam's contribution to this objective is a single artefact: the capability inventory in section 4, which sets out what the platform can do and marks what is separately licensable, so that nothing priceable is given away by accident in a demonstration and so ID Partners knows exactly what surface they are pricing.
The line to use in the room, if asked what something costs: "Commercials route to ID Partners." Nothing further, including a range, an order of magnitude or a comparison.
3. Procurement implications worth flagging, none of which are prices
These are the structural facts that shape a procurement, and they are legitimate to state.
| Implication | Why it matters to procurement |
|---|---|
| The contracting party is ID Partners | The commercial relationship, the support agreement and the invoicing are with ID Partners as reseller, with Raidiam as the product vendor behind them. This affects who CBA's contract is with and how the vendor management model is set up. |
| The deployment option changes the contract shape | The managed service and bring your own Postgres options place the data store on different sides of the boundary, which changes the data processing terms, the responsibility split and the operational commitments (content-deployment-model.md). The technical choice should be made before the contract is drafted, not after. |
| Region selection is a contractual fact | Sydney and Melbourne for Australian customers. Which regions are used, and whether both are required, should be named in the agreement. |
| The Enhanced Vendor Demo carries no contract dependency | The 24 August 2026 demonstration is vendor hosted, synthetic and requires nothing to be signed. The Formal Proof of Concept does require an agreement, at minimum covering environment access, data handling and support. That is the first commercial gate on the timeline. |
| Environment count is a scoping dimension | Non production environments, and whether each requires its own trust anchor, is a scoping question that should be settled early because it is easier to answer at design time than to renegotiate. |
| Portability is a design property, not a concession | The declared state of the entire federation lives in a git repository CBA can own, and the platform API is documented. Exit produces a machine readable estate rather than a data extract request (content-recovery.md). This is a fact CBA's procurement team will want and it is genuinely true. |
| CBA is already a consumer of this stack | Through ConnectID membership. Existing familiarity with the technology and its operation is a real procurement input, and it reduces the novelty risk normally priced into a first deployment. |
4. Capability inventory
Every capability below is real, and several are visible in the demonstration. The licensing column records only whether a capability is separately licensable, so it is not conceded by implication. No capability is scoped, sized or priced here, and any question about any row routes to ID Partners.
4.1 Trust Controller core
| Capability | What it does | Where it appears | Licensing |
|---|---|---|---|
| Directory and organisation model | Federations, authorities, authorisation domains, organisations, authorisation servers, software statements | Scenes 01, 02 | Core |
| OpenID Federation publication | Entity configurations, subordinate statements, subordinate listing, resolve endpoint | Scenes 02, 04 | Core |
| Capability roles as metadata policy | Roles carrying metadata rows, applied as federation metadata policy, unioned across roles, forming the capability envelope. Projection into the published statement is open verification item 4.1 in content-gap-register.md. | Scenes 02, 10 | Core |
| Authority claims and trust marks | Certification and status assertion, with a live status endpoint | Scenes 02, 06 | Core |
| Lifecycle control | Approve, suspend, withdraw, with publication following the state | Scenes 02, 06 | Core |
| Change history and versioning | Every state change versioned with actor, time and before and after state, in the interface and the API | Scenes 02, 07, 10 | Core |
| Full API surface | Everything the interface does is available through the API, which is what allows approval workflow to be externalised | Scenes 01, 07 | Core |
| Arbitrary attribute recording | Manifest sourced attributes recorded against a software statement or authorisation server and retrieved | Scene 08 | Core |
| Single sign on into the platform | Administrators authenticate with their own organisation's identity provider | Described, TC-14 | Confirm with ID Partners |
4.2 Separately licensable capability
Each of these is a distinct capability with its own commercial treatment. They are shown in the demonstration because they are part of the architecture. They are not included by implication.
| Capability | What it does | Where it appears | Note |
|---|---|---|---|
| Federation hub | Partner organisations authenticate into the platform with their own identity provider, so CBA does not run an identity estate for its partners | Described, TC-14. CBA already consumes this through ConnectID. | Separately priceable |
| Public key infrastructure, standard profiles | RSA and elliptic curve certificate issuance backed by a managed key management service, including the bring your own public key path where the private half never leaves the customer hardware security module | Scene 09 | Separately priceable |
| Post quantum public key infrastructure | ML-DSA profile for post quantum signing | Scene 09 | Separately priceable |
| Credential issuance | OID4VCI credential issuance, used here for verifiable mandates carried by an agent | Woven through scenes 03, 05, 06 | Separately priceable |
| Credential verification and presentation | OID4VP presentation with selective disclosure, so a counterparty receives only the mandate claims it needs | Woven through scenes 03, 05, 06 | Separately priceable |
| Shared signals publication | Security event publication and delivery over HTTP (RFC 8935), so a withdrawal reaches subscribed consumers immediately | Scene 06 | Separately priceable |
| Token status lists | OAuth token status list publication, so a consumer that subscribes to nothing still fails on the next presentation of an already issued token | Scene 06 | Separately priceable |
| Bring your own Postgres deployment | Customer held data store over private connectivity, with the vendor running the processing layer | Described, TC-13 | Separately priceable |
| Additional trust anchors or authorities | More than one anchor, for example a separate anchor per environment or per jurisdiction | Modelled in the estate | Separately priceable |
| Cross recognition with an external scheme | Mutual recognition between the CBA federation and an external scheme, so an external party's identity is trusted into CBA by federation alone | Modelled: an external partner agent provider and ConnectID as a cross recognised peer | Separately priceable |
| Additional environments | Non production environments | Scoping dimension | Separately priceable |
4.3 Not Raidiam capability, and therefore not Raidiam commercials
Recorded here so the inventory is complete and so nothing in these rows is assumed to be included.
| Item | Owner |
|---|---|
| Agent marketplace or catalogue | CBA or ID Partners. See content-gap-register.md. |
| Agent Identity Manifest schema | ID Partners |
| Approval and rejection workflow | CBA's existing tooling. External by design. |
| Ping Federate and Entra bridge | ID Partners |
| SPIFFE and SPIRE integration | ID Partners |
| Implementation, integration and support services | ID Partners |
5. What we need from ID Partners
- Confirmation that the section 4 inventory matches how ID Partners intends to package and price, and a correction where it does not.
- The procurement route CBA prefers, and whether an existing vendor arrangement can be used.
- What agreement is needed to start the Formal Proof of Concept, and its lead time. This is the first commercial item on the critical path.
- The data processing position for each deployment option.
- Whether any capability in section 4.2 should be withheld from the demonstration entirely rather than shown and marked. Raidiam's recommendation is to show them, because they are the strongest part of the architecture, and to name none of their commercial treatment on screen.
6. Status
Framed, with the capability inventory supplied. All commercial content is owned by ID Partners and is deliberately absent from this document, from the demonstration and from every narration script.