TC-14 Identity and authentication controls

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

Identity and authentication controls for PoC users, services, marketplace integrations, Trust Controller integrations and vendor access.

Five categories of principal are named. Each is answered separately in section 3, because they have genuinely different controls and answering them as one is how gaps hide.

2. The two rules that govern everything below

No anonymous access, and no shared access. Every action that changes state is attributable to a single named principal, human or machine. There are no shared logins, no team accounts and no credential that two people hold. This is not a configuration option to be enabled: it is the condition under which the change history in section 5 is worth anything at all.

Authentication is federated, not duplicated. CBA staff authenticate with CBA credentials through single sign on. Partner organisations authenticate with their own identity provider. The platform does not become a second password estate, a second joiner mover leaver process, or a second place a compromised credential can be found.

3. The five categories

3.1 PoC users, meaning CBA staff administering the Trust Controller

Single sign on into the platform from CBA's identity provider. CBA's authentication policy applies, including multi factor authentication and any conditional access rules, because the authentication event happens at CBA and the platform consumes the assertion. Joiner, mover and leaver is CBA's existing process: a person who leaves CBA loses platform access at the same moment they lose everything else, without a separate deprovisioning step that can be forgotten.

Authorisation inside the platform is by role, held against an organisation. A person's permissions are scoped to the organisations they administer, which in the CBA estate means a Bankwest administrator does not administer CommSec.

3.2 Services, meaning the automated integrations that drive the platform

The governance as code pipeline that applies manifests (scenes 01 and 07) authenticates with its own credential, holds its own role, and is a distinct principal in the change history. It is not a human's session and it is not a shared administrator account. Every record it creates or changes carries it as the actor, alongside the correlation identifier carried from the originating manifest.

This matters more than it sounds. If the pipeline runs as a person, the audit trail says a person made three hundred changes at 02:00 and the control is worthless.

3.3 Marketplace integrations

The marketplace is ID Partners' to build, so the credential it uses to call the platform is theirs to hold and CBA's to authorise. The requirement Raidiam places on it is the same as for any service: its own credential, its own role, its own attribution, scoped to the organisations it is entitled to act for, and revocable independently of everything else.

The boundary in content-domain-boundary.md limits the blast radius here: the marketplace credential can propose identity changes, and it cannot approve them, because approval is external to both systems by design.

3.4 Trust Controller integrations, meaning consumers of the published trust metadata

These are the authorization servers, resource servers and bridges that read the federation. They authenticate to nothing, and that is correct. Federation statements are signed and are fetched without credentials. A consumer verifies the signature and the chain rather than presenting a secret. Removing shared secrets from the read path removes an entire class of credential management problem, and it is the reason the trust surface scales to consumers CBA has not met yet.

Where a consumer receives pushed security events rather than polling, that channel is authenticated and the events are signed, so the receiver can verify origin independently of the transport.

3.5 Vendor access, meaning Raidiam and ID Partners staff

Named individuals only, with the same no shared access rule, and with access logged the same way any other administrative access is logged. For the Enhanced Vendor Demo the environment is vendor hosted and contains synthetic data only, so vendor access to the demonstration environment carries no CBA data risk. For the Formal Proof of Concept, the named list, the duration and the approval route are agreed with CBA before access is granted, and ID Partners is the party CBA holds that agreement with.

4. The platform as a federation hub

CBA's agent estate will include agents built by third parties, which means third party administrators will need scoped access to records they own. The platform can act as a federation hub, so a partner organisation authenticates with its own identity provider rather than being issued a credential by CBA.

Two consequences worth stating:

• CBA does not run an identity estate for its partners, and does not inherit the deprovisioning risk when a person leaves a partner organisation.
• The partner's own authentication controls apply, and CBA can require a level of assurance rather than a specific mechanism.

CBA already consumes this stack in production through ConnectID. This is not a described capability awaiting a build. It is running, in Australia, with CBA as a member.

5. What the controls produce: attribution

Access control is only credible if it produces evidence. Every state changing action in the platform is versioned with the actor, the time and the before and after state, and that history is available in the interface and through the API. Scene 02 walks it for an Agent Identity. Scene 07 follows a single correlation identifier from a committed manifest, through the platform change record, into token issuance and the resource server decision, which is the end to end attribution TC-18 asks for.

6. Privileged access and separation of duties

Multi party approval is enforced outside the platform, deliberately. The platform enforces who is permitted to make a change. Whether a change has been approved by two people, by a risk owner, or by a change advisory board is enforced by the workflow that drives the platform, which is CBA's existing tooling. This is a design position, not an omission, and it is recorded as gap 1 in content-gap-register.md with the reasoning. The practical shape in this demonstration: the pipeline credential is the only principal that changes production records, and the only way to make the pipeline run is to get a change merged, which is where CBA's approval controls already live.

7. What we need from CBA and ID Partners

1. Which CBA identity provider fronts administrator single sign on, and which groups map to which platform roles.
2. Whether CBA requires a specific assurance level or authentication method for partner organisations using the federation hub.
3. The approval control that gates the pipeline: which system, which approvers, and how many.
4. The vendor access list, duration and approval route for the Formal Proof of Concept environment.
5. Whether CBA requires administrative access to be network restricted in addition to being authenticated.
6. Which CBA SIEM receives the security event stream, and in which format (TC-18).