TC-20 Data protection controls
| Objective | TC-20 |
| Evidence level | Evidence, Integrate |
| Domain | Security and risk fit |
| Owner | Raidiam, with CBA controlling key custody and, under one deployment option, the data store itself |
| Phase | Formal Proof of Concept |
| Proven by | content-data-protection, with content-recovery.md covering the recovery half |
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
Data protection and recovery controls for PoC data and trust artefacts.
Recovery is answered in content-recovery.md. This document answers protection.
2. The fact that changes this conversation
The overwhelming majority of the data in a trust directory is public trust metadata, published deliberately. Entity configurations, subordinate statements, metadata policy, trust marks, trust mark status, organisation names and public key sets are all served to anyone who asks, without authentication, because a federation whose statements cannot be fetched is not a federation.
That single fact reshapes the assessment. For most of this data:
- Confidentiality is not the control. There is no confidentiality requirement on a document whose purpose is to be fetched by parties CBA has not met.
- Integrity and authenticity are the controls. Every statement is signed, and its chain terminates at a trust anchor CBA controls. The risk that matters is not disclosure. It is an attacker causing a false statement to be believed, which is a key custody and signature verification problem.
- Availability matters more than it usually does. If a consumer cannot fetch a statement, it fails closed and refuses the agent. Publication availability is a service availability control, not just a data one.
A data protection review that starts from encryption at rest will spend its time on the smallest part of the estate. The part that deserves the attention is section 5, key custody.
3. What is actually not public
The genuinely protected data is a short list, and it is worth being precise about it.
| Data | What it is | Sensitivity | Control |
|---|---|---|---|
| Administrator accounts | Name, work email, organisation, role. A small volume of ordinary business contact data. | The real personal data footprint, and it is small | Authentication is federated to CBA's identity provider, so credentials do not live in the platform (TC-14) |
| Access and change history | Who did what, when, from where | Business sensitive. It is the audit record. | Authenticated access, role scoped, retained |
| Records not yet published | An Agent Identity created but not activated does not resolve and is not visible externally | Business sensitive | Access control, and the fact of non publication |
| Customer supplied attributes | Whatever CBA chooses to record against a record: repository links, image digests, bill of materials references, owning team (TC-25) | CBA controls this entirely | See the warning below |
| Private key material | The signing keys behind every statement | The highest value asset in the system | Section 5 |
The warning on customer supplied attributes. Arbitrary attributes can be recorded against a software statement or an authorisation server, and retrieved. That is a demonstrated capability (scene 08) and it is how manifest sourced evidence pointers are carried. It also means CBA decides what goes in. No secret, credential, token or personal data should be recorded as an agent attribute, because some of those attributes are carried into published metadata by design. Attributes are evidence pointers, not a data store. This should be a rule in the manifest schema that ID Partners owns, and it is better stated now than discovered later.
4. Standard controls
| Control | Position |
|---|---|
| Encryption in transit | TLS on every endpoint, administrative and public |
| Encryption at rest | Managed encryption on the data store, with keys held in the cloud key management service |
| Access control | Federated authentication, no anonymous access, no shared accounts, role scoped authorisation (TC-14) |
| Attribution | Every state change versioned with actor, time and before and after state |
| Segregation by organisation | Permissions scoped to the organisations a principal administers, so administration of one part of the estate does not confer administration of another |
| Data residency | Sydney and Melbourne for Australian customers, with a bring your own Postgres option where the record must sit inside the CBA estate (content-deployment-model.md) |
| Personal data footprint | Minimal by design. Agent identities are software, not people. There is no customer personal data in the trust layer. |
5. Key custody, which is where the real risk sits
If an attacker can sign a statement that chains to CBA's trust anchor, every control above is irrelevant. Key custody is therefore the control that carries this objective.
Private keys can stay in CBA's key management service and never reach the platform. The demonstrable artefact is the bring your own public key path: CBA generates a key pair in its own key management service, uploads only the public half as a PEM, and the platform derives the key identifier deterministically from the public key. The entity stamps the same identifier on the header of the statements it signs, and both sides agree on the identifier without either having been told the other's value. The private half never leaves the hardware security module. Scene 09 demonstrates it end to end.
The platform's own key material, including its public key infrastructure, is backed by a managed key management service rather than held as files. Available profiles include RSA, elliptic curve, and ML-DSA for post quantum signing. Which profiles are in scope commercially routes to ID Partners.
Two operational consequences to design for, and they belong in the Formal Proof of Concept design:
- Key rotation. Whoever holds the private key controls the rotation schedule. Consumers pick up a new key by re resolving, which is the same mechanism as everything else, provided the client representation references a key set rather than embedding key values. That is a compatibility question for each consuming authorization server (
content-overlay-compatibility.md). - Key loss. Losing the trust anchor's private key is the one unrecoverable event in this architecture. It cannot be restored from a database backup or a git repository. It is recovered through the key management service's own controls, which is precisely why the bring your own key path matters: CBA holds the key and CBA's existing key custody, backup and recovery controls apply to it.
6. Retention and deletion
- Published trust metadata is not deleted when an agent is withdrawn. It stops being published, which is a different action, and the change history retains the fact that it existed and was withdrawn. That is a deliberate audit property.
- Change history and access logs are retained. Retention periods for the Formal Proof of Concept are agreed with CBA and are a contractual matter routed through ID Partners.
- On exit, the declared state of the entire federation is in CBA's own git repository and the platform API is documented, so CBA leaves with a machine readable copy of its estate rather than a data extract request. This is a portability property worth noting in the procurement conversation (
content-commercial.md).
7. What applies to the Enhanced Vendor Demo
Nothing in the demonstration environment is CBA data. It is synthetic throughout, vendor hosted, with no CBA integration and no CBA network connectivity, and it is destroyed after use. The controls above describe the product and the Formal Proof of Concept, not the demonstration, and the demonstration should not be assessed as though it held anything.
8. What we need from CBA and ID Partners
- Which deployment option, since option B places the data store inside CBA's own control (
content-deployment-model.md). - Whether CBA requires the bring your own key path for federation signing from day one, and which key management service instance holds the keys.
- Retention requirements for change history and access logs.
- Whether CBA classifies the change history as containing personal data, given it names administrators, and any handling that follows from that classification.
- A rule in the Agent Identity Manifest schema prohibiting secrets and personal data in agent attributes. ID Partners owns the schema.