Capability Leases

A destructive step is valid only inside every window above it

Each record carries issued_at and expires_at, and each authority that signs one has a window of its own. Issuance nests the windows; verification tests them against one clock.

The live interval is issued_at ≤ now < expires_at, so verification at the exact expiry value fails with LeaseExpiredOrUnknown. The pure verifiers take now_unix_ms from their caller and add no clock-skew allowance. Issuance compares the windows and authority status in the profile and request, without reading a wall clock, and refuses a receipt that would outlive its lease.

Buyer-core verifies at its configured verifier epoch. It checks each authority’s window at that epoch, each record’s issue time against its authority’s window, and each record’s own lifetime. For a destructive step it checks again that the receipt’s window sits inside the lease.

Two signed records and one preimage carry the authority

A lease authority signs the lease; a governance authority signs the receipt that authorizes a destructive step. The scope they cover is committed by digest.

• Capability lease, chio.capability-lease.v1. The lease authority signs the lease id, issuer, subject, scope digest, action class, and issue and expiry times.
• Governance receipt, chio.governance-receipt.v1. The governance authority signs the receipt id, authorizing kernel, case kind, authorized lease, workflow, step hash, and issue and expiry times.
• Lease scope binding. An unsigned preimage holding the workflow and tool scope. The signed lease commits to its digest.

pub struct GovernanceReceiptArtifact {
    pub schema: String,
    pub receipt_id: String,
    pub authorizing_kernel: String,
    pub case_kind: GovernanceReceiptCaseKind,
    pub authorized_lease_id: String,
    pub workflow_id: String,
    pub step_sha256: String,
    pub issued_at_unix_ms: u64,
    pub expires_at_unix_ms: u64,
}

Both signed records travel in SignedExportEnvelope<T>: the body, the signer key, and a signature over the canonical body JSON. The signature establishes integrity under the embedded key; authority pinning decides whether that key is trusted for its declared role.

Lease bodies use camelCase fields. Their action classes are scoped_observation, delegated_action, and narrow_destructive, compared against allowlists as named classes. The receipt’s case kind has one value, destructive_authorization. The Governance Ladder declares which action classes peers require, and listing charters and cases belong to Listing Disputes.

The scope digest binds the lease to the operation you mean

A digest means something only when the verifier rebuilds its preimage independently. The binding’s canonical preimage has thirteen fields, which answer four questions:

• Which workflow step? Lease id, workflow id, workflow grant id, and step index.
• Which execution target? Tool name, peer kernel id, action-class id, and tool-arguments hash.
• Whose authority? Subject, lease action class, and destructive flag.
• For how long? Issue and expiry timestamps in Unix milliseconds.

The schema field is validated and left out of the preimage. Buyer-core requires one binding per lease, resolves its workflow step, and compares its scope with the workflow receipt, the tool receipt, the class binding, and the lease body before it recomputes the digest. An edited binding therefore changes the digest and fails against the unchanged signed lease.

The pure lease helper sees only the digest string. Pass its optional expected digest from the scope you intend; with None, the helper skips that equality check and binds the lease to no particular operation.

One offline command issues a lease and its authorization together

The command reads an authority profile, an issuance request, and local signing seeds. One request selects a lease authority and a governance authority, and every step in it uses that pair.

chio federation authority issue \
  --profile ./authority-profile.json \
  --request ./issuance-request.json \
  --signing-keys ./authority-signing-keys.json \
  --out-dir ./issued-workflow

The output directory holds issuance-bundle.json, capability-leases.json, lease-scope-bindings.json, governance-receipts.json, and verification-context.json. Before signing, the command checks the inputs:

1. Profile. Explicit authority keys, matching key ids, positive validity spans, status, and nonempty class and case allowlists. Runtime policy issuer keys stay separate from lease, governance, and revocation authority keys.
2. Authorities. The selected authorities have Active status, and their configured seeds derive the profile’s public keys.
3. Steps. A destructive step uses narrow_destructive and supplies the governance receipt fields; a non-destructive step omits them. Duplicate lease ids and step indices fail. The governance authority’s destructive-authorization allowlist is checked even when the request has no destructive step.

The buyer verifier pins the authority before it reads a signature

The buyer verifier resolves the lease issuer and the receipt’s authorizing kernel from its trusted authority bundle. It checks key revocation, authority windows, issue times, signer-key equality, and the class or case allowlist, then calls the pure helpers. That order ties a valid signature to an expected authority.

For a destructive step, buyer-core recomputes the step hash from the canonical tool receipt body, resolves the authorized lease and its scope binding, and calls the strict verifier with the package’s workflow id. The strict verifier compares the lease id, workflow id, and step hash. A presence check confirms only that a live, signed receipt exists, so it never replaces the binding check; the wrong-workflow case shows the difference.

Revocation here works on pinned authority-key fingerprints. A matching receipt verifies every time inside its window, so a workflow that needs one-time use enforces it in the admission system that executes the step.

Lease verification reference

Next: follow the authority across operators