Security architecture
Security model
Decentralization Manager combines host controls, operator authentication, Canton authorization, encrypted peer communication, protected local state, supply-chain controls, and on-ledger governance. No single layer secures the whole deployment.
Each organization operates its own instance and controls its accounts, identity provider, Canton credentials, local storage, network exposure, peer records, and upgrades. On-ledger governance limits application actions; it does not protect a compromised host or incorrect off-ledger input.
Trust boundaries
Treat every arrow as a separate boundary requiring the appropriate authentication, authorization, encryption, validation, logging, and failure handling.
Control ownership
Operator access
OIDC, PKCE, role enforcement, session and account controls
Canton connections
Separate Admin and Ledger credentials, least privilege, restricted network paths, TLS or mTLS
Peer communication
Persistent Noise identity, encrypted transport, allowlisted keys, out-of-band verification
Persistent data
Restricted storage, database encryption, protected backups, consistent recovery
DAR supply chain
Approved source, version pinning, hashes, review, and package comparison
Governance
On-ledger proposals, confirmations, active rules, execution, expiry, and result verification
Release compatibility
Approved versions, peer protocol, migrations, known issues, and support status
Threat model and residual risks
Compromised operator account: can invoke the routes and Canton rights available to that identity.
Compromised host: can expose local credentials, falsify the UI, interrupt workflows, or misuse assigned Canton rights.
Wrong peer record: creates encrypted trust with the wrong endpoint; encryption cannot replace identity verification.
Lost or replaced Noise identity: changes how peers recognize the instance and requires coordinated replacement.
Malicious or incompatible DAR: can affect application behavior despite successful distribution.
Mixed peer versions: can interrupt coordination when protocol compatibility changes.
Coordinator failure: can stop workflow progress without invalidating the existing Decentralized Party.
Inconsistent restore: can preserve only part of the identity, credential, package, or workflow state.
Sensitive logs or support exports: can leak credentials or confidential identifiers if not sanitized.
Governance limits
Governance authorizes application actions on Canton; it does not prove that every input, package, host, or external system is safe. Members must review the proposal, referenced contracts, package versions, and expected effects before confirming.
Do not use a fixed approval count as a universal product property. Production rules and any intentional design constraints must be documented for the supported release.
Audit and disclosure
Audit pages identify the reviewed commit, components, dates, exclusions, design acknowledgements, and remediation status. An audit is point-in-time evidence, not a guarantee for every deployment or future release.
Use one approved private vulnerability-reporting route. Do not report unpatched vulnerabilities through public issues or discussions.
Technical sources
Next step
👉 Apply the controls: Decentralization Manager production deployment.
Last updated