Identity and delegation

Audience: developers · Read route: rebuild · Reflects specification v0.1

Authority binds through a verifiable chain, and every link in it is checkable without a network call at the moment an action is recorded. A real legal entity records actions; a natural person or a service actually signs them; the runtime needs to know that the signer had scoped authority that had not expired and had not been revoked. Four links do this.

The four links

• Directory attestation. A directory holds an attestation binding a legal entity to an account public key. The directory is itself a runtime instance built on the same primitives as everything below it, and multiple instances can cross-verify by signature.
• Account identity. Each runtime has an account: an opaque, random identifier with a public key on the dual-curve tree. The account identifier is not derivable from anything personal, so correlating an account across deployments requires an explicit attestation rather than a lookup.
• Mandated actor. A delegation grants a natural person or a service scoped, time-bounded authority to sign actions on the account's behalf. The actor's public key is pinned at the moment the mandate is granted.
• Action signature. Every action carries the mandated actor's signature, which verifies against the key pinned at grant time.

Mandates are auditable, scoped, and revocable

A mandate is scoped to specific methods, is time-bounded, and can be revoked. Both the delegation and its revocation are themselves recorded actions on the public audit layer, so the full history of who was authorised to do what, and until when, is auditable like any other event. An action from an actor without an active, in-scope mandate for the method it invokes is rejected. These are auditable, revocable mandates, and their alignment with eIDAS mandate semantics is what makes them portable into a regulatory setting.

Local verification, no network on the hot path

Verification happens against the pinned key, locally, with no lookup on the critical path. Without pinning, verification needs a network round-trip; with pinning it does not:

Resolving an identifier on every action would put a network round-trip, and a fresh trust assumption, on the hot path. Pinning fixes the action's meaning at the moment it was signed.

Compromise does not cascade

Every key in the chain is a distinct per-context derivation, as described on Keys and derivation. A leaked action-signing key reveals nothing about the mandate above it; a compromised mandate can be revoked in its own scope without touching the account. There is no single key whose loss unravels the chain.

Open identity standards, credential optional

Accounts and mandates bind to the open W3C DID and Verifiable Credentials standards. For citizen-facing flows, a mandate may be issued as a portable, selectively disclosable credential using SD-JWT and presented over OpenID4VP and OpenID4VCI, with binding aligned to eIDAS. A party can present such a credential to a runtime it has never met, which verifies the issuer, the scope, the expiry, and the revocation status locally, and accepts or rejects the action. The credential is optional; organisational flows work without it.

Provisional item PROV-4 (data-protection erasable-mandate pattern), pending technical review. An append-only record cannot delete a past entry, which appears to conflict with a data-subject erasure request. The pattern that resolves this: the runtime operates on a pseudonymous actor identifier, and the mapping from that pseudonym to a natural person is held as a separate, erasable link. Erasing the link renders the person no longer identifiable from the append-only record, honouring an erasure request without rewriting history. The pattern is normative; the concrete operator-owned identity-link mechanism that stores and erases the link is proprietary operator configuration and is out of scope for this reference. The split is subject to technical review; see the specification, Section 9, PROV-4.

The rules behind this page

The MUST rules for local signature verification against a pinned key, scoped and time-bounded and revocable mandates, recorded delegation and revocation, rejection of an unmandated action, and binding to the open identity standards are in the specification, Section 3.6. This page explains the mechanism behind them.