Organisation workflows with shared approval and custody choices
Development status: Being explored — The intended pattern combines approval of sensitive actions by several authorised approvers, a choice of how the signing keys behind an organisation’s funds are held, and opinionated starting profiles. None of this is implemented in the experimental implementation, and nothing is publicly available for live use.
Before you read: What you could build: intended application patterns.
How might an organisation run sensitive workflows in which several people must approve actions and keys are held in a way it chooses? This page describes how multi-party approval, custody choices and starting profiles are intended to fit together for an organisation, distinguishes everyday signing from the approval of sensitive actions, and sets out the responsibilities that would remain with the organisation itself. None of it exists today.
The problem
Organisations that adopt shared infrastructure bring their internal governance with them. Three needs come up repeatedly:
- No single person acting alone. Sensitive actions — moving significant funds, or changing important settings — should not be something one person can carry out alone. Controls need to reflect the organisation’s own approval rules.
- Key holding that fits risk policy. The signing keys behind an organisation’s funds are a central risk. How they are held has to fit the organisation’s own risk policies, which differ from one organisation to the next.
- A sensible starting point. Teams new to confidential applications benefit from recommended starting configurations, rather than deciding every setting from scratch.
The pattern on this page brings these needs together. Each part rests on a capability that has its own primary page; this page describes how the parts are intended to fit an organisation’s workflows.
Multi-party approval
Status of this section: Being explored — not implemented.
- Several approvers for sensitive actions. The design is being explored so that approving a sensitive action could require several authorised approvers, separate from the key used for day-to-day signing. Routine actions would continue to be signed with everyday keys.
- The organisation’s policy. Which actions would need several approvers, and how many, is not yet specified publicly. No defaults are published.
- Authority, not identity or visibility. Approval concerns the authority to act. It is distinct from identity — who the organisation or person is — and from who may see data. See Approving actions: authority and multi-party approval and Participant identity.
- Narrow credentials for automated jobs. The design is being explored so that automated jobs could use short-lived, narrowly scoped credentials instead of a participant’s main key, limiting what an automated process could do if its credential were misused. The scope and duration of such credentials are not described.
- Recovery arranged in advance. The design is being explored so that an actor could keep its identity and obligations after losing a key, through a recovery path configured in advance. Where none is configured, recovery would not be possible.
Custody choices
Status of this section: Being explored — not implemented.
- A choice of how keys are held. The design is being explored to let an organisation choose how the signing keys behind its funds are held, for example by one party or by a group of parties.
- No service or provider. This documentation does not describe any custody service or custody provider, and it does not describe Cubane holding organisations’ keys.
- Holding is not approving. Holding keys would not by itself confer authority to approve actions; custody and approval are separate choices.
- Keys over time. Creating, rotating and revoking keys is described on Key lifecycle: creation, rotation and revocation. The general considerations of holding keys by one party or by a group are on Custody options for organisations.
Starting profiles
Status of this section: Being explored — no profile is defined.
- Recommended starting points. Opinionated starting profiles would help teams choose confidentiality and performance settings for common use cases.
- Nothing published yet. No profile names, settings or figures are published; see Use-case profiles.
- Documented when defined. Once defined, each profile would be documented with its intended use and its limitations.
A profile would be a starting point, not a decision made on the organisation’s behalf: the team would still check that the profile fits its own needs.
How the pieces would fit together
Status of this section: Being explored — a conditional description; none of it can be done today.
Once these capabilities are implemented, enabled and publicly released, an organisation adopting this pattern would be expected to work through a set of decisions:
- choose a starting profile for its confidentiality and performance settings;
- decide which sensitive actions need several approvers, and who those approvers are;
- choose how the signing keys behind its funds are held;
- configure a recovery path in advance;
- decide who may see which data — see Sharing selected results with auditors and partners.
Each of these would be the organisation’s own policy decision, made separately. The list is a set of decisions rather than a sequence of steps, and it does not describe how any decision would be recorded or applied. No interface for making these choices exists; the intended onboarding experience is previewed on Onboarding an organisation.
The organisation’s own responsibilities
Whatever the platform eventually provides, an organisation would remain responsible for:
- Its policies. Setting and regularly reviewing who approves which actions, how keys are held, its recovery path and the visibility it has granted.
- Keys, devices and people. Protecting the keys and devices it controls, and supporting the people who hold approval authority, including when they change roles or leave.
- Independence. Making sure that approvers are genuinely independent of each other where independence matters.
- Its obligations. Meeting its own legal, regulatory and contractual obligations. What is and is not claimed about compliance is set out on Compliance position and data-protection intent.
Assumptions, trust and limitations
- Independence is organisational. Several approvers add protection only if they are independent of each other — approvers who rely on the same device, the same system or the same person’s instructions may offer less protection than their number suggests. Independence is an organisational property that the platform could not provide on its own.
- Nothing is implemented. Nothing described on this page is implemented or enforced today.
- Enforcement is not described. How approval, custody and recovery would be enforced is not described.
- Recovery has limits. A recovery path would restore the ability to act for an identity; it would not recover encrypted data.
- Profiles are recommendations. Starting profiles would be recommendations, not assurances.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once the underlying capabilities are released, this page would link to versioned reference for approvals, custody and recovery, and to the organisation onboarding experience. Approved public references would be listed once approved; none are listed yet.
What this page does not claim
This page does not claim:
- any custody service or custody provider, or that Cubane holds keys;
- that any approval, custody choice or recovery path is implemented or enforced today;
- any recovery beyond a path configured in advance;
- any approval rules, approver counts, profile contents or defaults;
- any legal or regulatory assurance.
Anything not stated here as available should be treated as unavailable.
Related pages
- Approving actions: authority and multi-party approval — the primary page for multi-party approval.
- Custody options for organisations — the primary page for custody choices.
- Use-case profiles — intended starting configurations.
- Onboarding an organisation — the intended onboarding experience, previewed conditionally.
- Key lifecycle: creation, rotation and revocation — how keys would be managed over time.
- Participant identity — identity kept separate from keys, and pre-arranged recovery.
- Sharing selected results with auditors and partners — deciding who may see which data.
Glossary
- Multi-party approval
- Approval authority
- Signing key
- Custody
- Recovery path
- Scoped credential
- Use-case profile
References
No approved public references yet.
