# CBA Agentic IDAM Trust Controller — objective coverage # # SINGLE SOURCE OF TRUTH for what is built against TC-01..TC-28. # Source: "Agentic IDAM - Trust Controller PoC Objectives - FINAL (2).pdf", 10 July 2026, §7. # # Generates three outputs (tools/objectives/): # 1. the live coverage page in the microsite (render-coverage.ts) # 2. a CI gate that fails on unevidenced claims (check-objectives.ts) # 3. the vendor-demo / PoC split export for ID Partners (export-split.ts) # # status: todo | building | built | recorded | evidenced | na # built = it runs, verified against the live stack # recorded = a clip exists AND someone has watched it end to end # evidenced = an authored artefact exists (Evidence-level objectives) # owner: raidiam | idpartners | shared # phase: vendor-demo | poc | both (CBA's own phasing) # evidence: demonstrate | integrate | evidence (CBA's own evidence levels) # # CI rule: status in [built, recorded, evidenced] REQUIRES a non-empty artefacts list. # CI rule: owner idpartners MUST carry a handoff note. meta: source_document: Agentic IDAM - Trust Controller PoC Objectives - FINAL (2).pdf source_date: 2026-07-10 source_author: Robert Harkin, Technical Delivery Manager, CBA vendor: Raidiam delivery_partner: ID Partners demo_date: 2026-08-24 # CONFIRMED 2026-08-10. Ten working days from kickoff. build_freeze: 2026-08-20 # everything demonstrable must be built by end of day production_window: 2026-08-20 .. 2026-08-21 dry_run: 2026-08-21 last_reviewed: 2026-08-10 objectives: - id: TC-01 objective: > Registering an Agent in a marketplace or catalogue triggers the appropriate Agent Identity workflow based on an Agent Identity Manifest. domain: governance-control-strength phase: both evidence: [demonstrate, integrate] owner: shared status: built proven_by: scene-01-manifest-to-identity artefacts: - kind: doc path: docs/tracker-reconciliation.md handoff: > ID Partners builds and shows the mock marketplace/catalogue and owns the Agent Identity Manifest schema. Raidiam shows the receiving half: a manifest committed to git drives the Connect API to create the software statement, assign roles and activate authority claims, with a rejected manifest producing a rejected outcome. notes: > Acceptance requires that agent registration remains OWNED by the marketplace and that identity creation is triggered only by an explicit manifest or lifecycle event. The GitOps pipeline makes that boundary visible: the manifest is the contract, Connect is the fulfilment. verification: > Verified live 2026-08-10. All three paths driven: catalogue refuses with reasons and nothing crosses; catalogue registers and the Trust Controller refuses the identity, which is two control decisions by two owners; catalogue registers and the Trust Controller accepts, and the handoff emits a payload addressed to tools/connect carrying the software statement, its organisation and its federation roles. - id: TC-02 objective: > The Trust Controller is the control-plane governance layer for Agent Identity approval, suspension and withdrawal decisions. domain: strategic-architecture-fit phase: both evidence: [demonstrate] owner: raidiam status: built proven_by: scene-02-control-plane artefacts: - kind: doc path: docs/capability-envelope-spike.md notes: > Raidiam Connect IS the Trust Controller. Approve = software statement live with Active authority claims. Suspend = claims set Inactive, marks stop issuing. Withdraw = entity no longer resolves. Decision history is the Connect change log, which is versioned already. verification: > Verified live 2026-08-10. The CBA estate is applied to the directory and nine entities resolve under the authority. Publication and withdrawal are the same mechanism: attaching an Active claim publishes the capability into the subordinate statement, setting it Inactive withdraws it. Both observed on the wire. - id: TC-03 objective: > Token flow with an Agent Identity trust check before access is granted to a protected service or resource. domain: integration-fit phase: both evidence: [demonstrate, integrate] owner: raidiam status: building proven_by: scene-03-token-trust-check artefacts: [] notes: > Payments/Accounts/Supplier resource servers publish protected-resource metadata declaring the RAR detail types, claims and DPoP binding they require. The agent resolves the requirement, obtains a token, and the RS re-derives trust from the federation before honouring it. Denials are observable and explainable, which the acceptance criteria demand explicitly. verification: > The resource server verifies token signature, issuer, audience and expiry, and resolves the authorization server through the federation to the trust anchor. It does NOT independently resolve the agent entity statement: the agent identity arrives as the RFC 8693 act chain in a token the authorization server signed, recorded as agent_identity_source act_chain_asserted_by_authorization_server. That is CBA's own architecture, since TC-10 places metadata consumption at the identity provider. Optional independent resolution on rs-payments only is scoped but not started. - id: TC-04 objective: > An Agent lifecycle event such as suspension or retirement triggers revocation or disablement of associated Agent Identities. domain: governance-control-strength phase: both evidence: [demonstrate, integrate] owner: raidiam status: todo proven_by: scene-06-revoke-and-propagate artefacts: [] notes: > Three propagation paths shown side by side with a stopwatch on screen, because the acceptance criteria call for timing and stale-metadata tolerance: (1) Connect authority claim set Inactive, trust mark withdrawn, next resolve fails closed; (2) SSF security event pushed to subscribed resource servers (RFC 8935); (3) OAuth token status list flipped, so a non-subscribing RS still fails on next presentation. - id: TC-05 objective: > Agent Identity metadata service lifecycle control for publishing, updating and withdrawing OpenID Federation entity configuration or equivalent trust metadata, as the authoritative source for Agent Identity. domain: integration-fit phase: both evidence: [demonstrate, integrate] owner: raidiam status: built proven_by: scene-02-control-plane artefacts: - kind: doc path: docs/capability-envelope-spike.md notes: > Live subordinate statements and entity configurations fetched on screen before and after a change. Versioning and traceability come from Connect's existing change history. verification: > Verified live 2026-08-10. Subordinate statements are published, updated and withdrawn through claim state, and the published authorization_details_types were read back off the authority and match the runtime vocabulary the resource servers enforce. - id: TC-06 objective: > Clarify the marketplace or catalogue role as the authoritative Agent registration and discovery channel, separate from Agent Identity and trust authority. domain: strategic-architecture-fit phase: vendor-demo evidence: [evidence, demonstrate] owner: shared status: evidenced proven_by: content-domain-boundary artefacts: - kind: doc path: docs/evidence/content-domain-boundary.md handoff: > ID Partners owns the marketplace side of the responsibility model. notes: > A single diagram carrying the four-layer domain model from §5 of the objectives paper: Agent, Agent Identity, Identity-layer Client Representation, Workload-layer Representation, with the accountable team named against each. This is the diagram the whole demo hangs off. verification: > Verified live 2026-08-10 by driving apps/marketplace. A registration request produces an Agent Identity Manifest, which is the live artefact the objective asks for rather than a diagram. The boundary is stated in the interface: the catalogue decides whether the agent should exist, and only then does the Trust Controller decide whether it gets an identity. A refused registration never reaches the Trust Controller at all. - id: TC-07 objective: > Orchestration across Agent workflow events and Agent Identity workflows for registration, approval, publication, suspension and withdrawal. domain: delivery-fit phase: both evidence: [demonstrate, integrate] owner: shared status: todo proven_by: scene-01-manifest-to-identity artefacts: [] handoff: > Marketplace-side workflow steps and RACI are ID Partners'. notes: > The GitOps pipeline demonstrates retry and remediation without corrupting either system of record, which the acceptance criteria call out. Show a failed apply, then a re-run. - id: TC-08 objective: > Policy enforcement for Agent Identity trust decisions using roles, scopes, claims, attributes, environment context or risk signals. domain: governance-control-strength phase: both evidence: [demonstrate, integrate] owner: raidiam status: todo proven_by: scene-05-guardrails artefacts: [] notes: > The five guardrail denials, each a different policy surface: eligibility denied (no role), widen denied (RAR envelope exceeded), read-only agent denied write, budget denied (cumulative), constraint denied (wrong counterparty). Every denial renders its reason. - id: TC-09 objective: > Federation bridge capability for existing authorization servers, including trust-chain resolution, client metadata resolution and dynamic client onboarding for Agent Identities. domain: compatibility-fit phase: poc evidence: [evidence, integrate] owner: idpartners status: evidenced proven_by: content-federation-bridge artefacts: - kind: doc path: docs/evidence/content-federation-bridge.md handoff: > ID Partners owns the Ping Federate bridge. Mina confirmed on 6 August that ID Partners has a module that walks the trust chain. Raidiam supplies the federation surface and the written integration design; ID Partners confirms it against the CBA estate. notes: > Raidiam's contribution is showing automatic client registration working against a conformant AS, with the client metadata assembled from directory roles as federation metadata policy. - id: TC-10 objective: > The Trust Controller is the authoritative source of Agent Identity trust metadata, with downstream Identity Providers consuming it to establish local client representations and perform runtime token issuance. domain: integration-fit phase: both evidence: [demonstrate, integrate] owner: raidiam status: building proven_by: scene-04-dynamic-onboarding artefacts: - kind: doc path: docs/deployment-hostnames.md notes: > An agent presents at an OP it has never met. The OP resolves it through the federation, builds a local client representation from the resolved metadata, and issues a token. No pre-shared client record anywhere. This is the single most persuasive scene in the demo. verification: > Verified live 2026-08-10. All seven reference authorization servers resolve through the federation to the trust anchor: /resolve returns 200 with a signed resolve response, a three entry trust chain and resolved metadata carrying federation_entity and openid_provider. The platforms sign their entity configuration under a directory issued organisation signing certificate, so the superior vouches the exact key that signed the leaf. - id: TC-11 objective: > Validate the strategic OpenID Federation target state by operating as the authoritative Trust Controller for Agent Identity trust publication, while demonstrating a credible transition from the near-term overlay deployment model to native federation. domain: strategic-architecture-fit phase: both evidence: [evidence, demonstrate] owner: raidiam status: evidenced proven_by: content-target-state artefacts: - kind: doc path: docs/evidence/content-target-state.md notes: > Raidiam is already native. The transition story is about CBA's authorization servers, not about Raidiam's roadmap. Frame it as overlay first (Connect publishes, Ping consumes through the bridge), native second (Ping resolves directly). Deviations from the standards must be explicit. - id: TC-12 objective: Overlay compatibility with the current enterprise authorization server landscape. domain: compatibility-fit phase: both evidence: [evidence, integrate] owner: idpartners status: evidenced proven_by: content-overlay-compatibility artefacts: - kind: doc path: docs/evidence/content-overlay-compatibility.md handoff: > ID Partners owns the Ping and Entra compatibility matrix and the required enterprise changes. David was explicit on 6 August that this belongs in the second presentation, not the vendor demo. - id: TC-13 objective: Deployment model options and CBA boundary implications. domain: deployment-model-fit phase: both evidence: [evidence] owner: raidiam status: evidenced proven_by: content-deployment-model artefacts: - kind: doc path: docs/evidence/content-deployment-model.md notes: > SaaS on AWS, Sydney and Melbourne for Australian customers, single cloud today. Bring your own Postgres over VPC peering or VPN where data sovereignty is required, with Raidiam running the processing layer. Shared responsibility diagram. One slide, no more. - id: TC-14 objective: > Identity and authentication controls for PoC users, services, marketplace integrations, Trust Controller integrations and vendor access. domain: security-risk-fit phase: both evidence: [evidence, demonstrate, integrate] owner: raidiam status: evidenced proven_by: content-access-controls artefacts: - kind: doc path: docs/evidence/content-access-controls.md notes: > No anonymous or shared access anywhere. Connect supports SSO into the platform and can act as a federation hub so partners authenticate with their own identity provider. CBA already consumes this through ConnectID. - id: TC-15 objective: Secure configuration and hardening of PoC components. domain: security-risk-fit phase: poc evidence: [evidence, integrate] owner: raidiam status: evidenced proven_by: content-hardening artefacts: - kind: doc path: docs/evidence/content-hardening.md - id: TC-16 objective: Vulnerability identification and remediation approach for PoC components. domain: security-risk-fit phase: poc evidence: [evidence, integrate] owner: raidiam status: evidenced proven_by: content-vulnerability-management artefacts: - kind: doc path: docs/evidence/content-vulnerability-management.md - id: TC-17 objective: Network protection, segmentation and isolation for the PoC deployment pattern. domain: security-risk-fit phase: poc evidence: [evidence, integrate] owner: raidiam status: evidenced proven_by: content-network-architecture artefacts: - kind: doc path: docs/evidence/content-network-architecture.md - id: TC-18 objective: > Security logging for authentication, access, Agent workflow triggers, Agent Identity trust decisions, policy changes, errors and administrative actions. domain: security-risk-fit phase: both evidence: [demonstrate, integrate] owner: raidiam status: building proven_by: scene-07-audit-trail artefacts: [] notes: > Acceptance requires correlation identifiers spanning the marketplace and the Trust Controller. Carry one correlation id from the committed manifest, through the Connect change record, into the token issuance log and the resource server decision log, and show it filtered end to end. Delivery is by webhook and log stream, which is the existing product capability. verification: > Resource half done and verified live across two servers: the caller's correlation id is taken from header, traceparent, argument, token claim or generated, echoed on every allowed call, every refusal including the 401 before a token exists, and every decision log entry, queryable at /decisions?correlation_id=. The manifest to Trust Controller half is still to come. - id: TC-19 objective: Observability and monitoring sufficient to operate and investigate the Trust Controller. domain: delivery-fit phase: both evidence: [evidence, demonstrate] owner: raidiam status: evidenced proven_by: content-observability artefacts: - kind: doc path: docs/evidence/content-observability.md - id: TC-20 objective: Data protection and recovery controls for PoC data and trust artefacts. domain: security-risk-fit phase: poc evidence: [evidence, integrate] owner: raidiam status: evidenced proven_by: content-data-protection artefacts: - kind: doc path: docs/evidence/content-data-protection.md notes: > Worth stating plainly that almost all data in the platform is public trust metadata by design, which materially changes the data protection conversation. - id: TC-21 objective: Recoverability and rebuild approach for the PoC environment. domain: delivery-fit phase: poc evidence: [evidence, integrate] owner: raidiam status: evidenced proven_by: content-recovery artefacts: - kind: doc path: docs/evidence/content-recovery.md notes: > The GitOps pipeline is itself the answer: the entire federation is declared in git and applied by pipeline, so rebuild is a re-apply. Demonstrate a teardown and rebuild if time allows. - id: TC-22 objective: Support, operating model and vendor enablement for implementation and BAU transition. domain: delivery-fit phase: both evidence: [evidence] owner: idpartners status: evidenced proven_by: content-support-model artefacts: - kind: doc path: docs/evidence/content-support-model.md handoff: ID Partners owns the in region support and enablement model as reseller. - id: TC-23 objective: Commercial and procurement implications of the solution and deployment model. domain: commercial-procurement-fit phase: vendor-demo evidence: [evidence] owner: idpartners status: evidenced proven_by: content-commercial artefacts: - kind: doc path: docs/evidence/content-commercial.md handoff: > ID Partners owns commercials as reseller. Raidiam supplies a capability inventory so nothing priceable is given away by accident: post quantum PKI, credential issuance, SSF publication, token status lists, federation hub. - id: TC-24 objective: > Implementation gap severity and internal build effort for capability not available out of the box. domain: delivery-fit phase: both evidence: [evidence] owner: shared status: evidenced proven_by: content-gap-register artefacts: - kind: doc path: docs/evidence/content-gap-register.md notes: > Answer this honestly and first, before they find the gaps themselves. Known gaps: approval workflow is external by design; marketplace and manifest are CBA or partner built; SPIFFE binding is an integration, not a product feature. - id: TC-25 objective: > Agent Identity metadata and external evidence handling, including manifest-sourced ownership, environment, version, grant types, endpoints, keys, hashes, repository links, SBOM references and other evidence pointers. domain: governance-control-strength phase: both evidence: [demonstrate, integrate] owner: shared status: todo proven_by: scene-08-metadata-and-evidence artefacts: [] handoff: ID Partners owns the manifest schema; Raidiam shows what Connect can record and return. notes: > The specific ask Ralph made: show how arbitrary attributes are recorded against a software statement or authorisation server and retrieved. Includes a metadata classification matrix distinguishing mandatory from optional, standards-based from CBA-specific, and authoritative from derived, with a named owner and validation rule per item. - id: TC-26 objective: > Cryptographic assurance for Agent Identity trust metadata using enterprise-managed key material, without the Trust Controller storing private keys. domain: security-risk-fit phase: both evidence: [demonstrate, evidence] owner: raidiam status: todo proven_by: scene-09-kms-held-keys artefacts: [] notes: > Connect is KMS backed throughout, including the PKIs. The demonstrable artefact is the BYO public key path: upload a PEM public key whose private half is in AWS KMS, Connect derives the kid as hex(sha256(DER SPKI)), the entity stamps the same kid on its entity configuration JWS header, and both sides agree without either being told the other's value. Also show the PKI profiles: RSA, EC (ISO 18013-5 capable) and ML-DSA for post quantum. - id: TC-27 objective: > Govern, version and expose an approved capability envelope for an Agent Identity, and make that capability metadata available to downstream identity, policy, entitlement and enforcement platforms. domain: integration-fit phase: both evidence: [demonstrate, integrate] owner: raidiam status: built proven_by: scene-10-capability-envelope artefacts: - kind: doc path: docs/capability-envelope-spike.md - kind: doc path: docs/artefacts/tc27-subordinate-statement.jwt notes: > The acceptance criteria insist the envelope is governed INDEPENDENTLY of OAuth scopes and runtime client configuration. Directory roles carrying metadata rows are exactly that: they are applied as federation metadata policy, they union across roles, and they are versioned by Connect. Show a capability change propagating to a consumer without touching the agent identity. - id: TC-28 objective: > Automated Workload Identity registration through APIs and integration with CBA's existing SPIFFE/SPIRE-based workload attestation capability. domain: integration-fit phase: both evidence: [demonstrate, evidence, integrate] owner: idpartners status: todo proven_by: scene-11-instance-attestation artefacts: [] handoff: > SPIFFE and SPIRE integration deferred to ID Partners. notes: > Raidiam's half is the automated registration API and the analogous runtime binding: the agent provider attests an instance, the instance authenticates with a client attestation grant, and the instance identity is bound to the approved Agent Identity. Frame SPIFFE as another attestation source feeding the same binding, which is architecturally true and honest.