Approving actions: authority and multi-party approval

Development status: Being explored — The design is being explored; its public interface and support are not settled. The intention is that approving a sensitive action could require several authorised approvers, separate from the key used for day-to-day signing; nothing in the experimental implementation enforces approval by several parties. Nothing is publicly available for live use.

Before you read: Identity, keys and access: concepts.

Could sensitive actions require approval from several authorised people, separate from everyday signing keys? That is the intention being explored. Nothing enforces it today: nothing in the experimental implementation enforces approval by several parties. This page distinguishes proving who is acting from being authorised to act, explains the intended separation between approval authority and everyday signing, and describes multi-party approval and related authority concepts at concept level.

Signing is not the same as approving

Two questions are easily run together:

• Authentication shows who is acting.
• Authorisation decides whether that actor may do what they are asking to do.

In everyday use, a key signs routine actions for an identity. For sensitive actions, the intended design separates the authority to approve from the key used for day-to-day signing. A valid signature would show which key signed; it would not, by itself, show that a sensitive action has been approved.

Approval authority is also separate from who may see data. Being allowed to see something does not mean being allowed to act on it; see Visibility controls and selective disclosure.

Multi-party approval

Status of this section: Being explored — nothing enforces it today.

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.

• The same action. Each approver would approve the same action. How approvals would be collected and checked is not described.
• The organisation’s policy. Which actions would count as sensitive, and how many approvers they would need, would be set by the organisation’s own policy. No defaults are published.
• Independence. Several approvers add protection only if they are genuinely independent of each other. Independence is an organisational property — a matter of who the approvers are and how they work — which the platform could not provide on its own. It is not a cryptographic assurance.

Related authority concepts

Status of this section: Being explored — not implemented.

• 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, and how they would be issued or withdrawn, are not described.
• Pre-arranged recovery. 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; see Participant identity.
• Custody does not confer authority. Holding the keys behind an organisation’s funds would not by itself confer approval authority; see Custody options for organisations.

Example situations

Once these capabilities are implemented, enabled and publicly released, they are intended to support situations such as the following. The examples illustrate the concepts; they are not configurations or recommendations.

• A large payment. A large payment from an organisation’s funds could require approval by several finance approvers, while routine payments are signed with an everyday key.
• A scheduled reporting job. A reporting job could run with a short-lived credential limited to that job, rather than with an approver’s main key.
• A reviewer. A reviewer could be allowed to see certain records without being able to approve anything, because seeing and approving are separate.
• A lost approver key. An approver who loses a key could continue through a recovery path arranged in advance.

How multi-party approval would fit into an organisation’s day-to-day work is described as an application pattern on Organisation workflows with shared approval and custody choices.

What exists today

• Nothing in the experimental implementation enforces approval by several parties.
• Approval authority, narrow credentials for automated jobs and pre-arranged recovery are not implemented.
• Key handling in the experimental implementation must not be relied on for security.

Assumptions, trust and limitations

• Multi-party approval protects only as well as the independence and diligence of the approvers.
• How approvals would be enforced, recorded or reviewed is not described.
• The terms used on this page are defined in the glossary, and several of those definitions are marked for review.

Not yet available, and how this page will grow

Further technical reference is not yet available. Once implemented and released, this page would describe how approvals are configured and checked, with versioned reference. Where approval decisions would fit when an organisation joins is previewed conditionally on Onboarding an organisation.

What this page does not claim

This page does not state any approval rules, approver counts or defaults, and it does not claim that any approval is enforced today. It claims no recovery beyond a path configured in advance and no compatibility with other platforms’ approval mechanisms. Anything not stated here as available should be treated as unavailable.

Related pages

• Participant identity — the identity on whose behalf approvals would be given, and pre-arranged recovery.
• Custody options for organisations — who holds keys, which is separate from who may approve.
• Visibility controls and selective disclosure — who may see data, which is separate from who may act.
• Organisation workflows with shared approval and custody choices — how multi-party approval fits into an organisation’s workflows.
• Onboarding an organisation — where approval decisions would appear in the intended onboarding experience.

Glossary

• Authentication
• Authorisation
• Approval authority
• Multi-party approval
• Signing key
• Scoped credential
• Recovery path

References

No approved public references yet.