Profile delegus-base-v3

Release candidate. This describes v0.3-rc1, the current release candidate. New and existing relying parties are on it (profile delegus-base-v3). It is not frozen: the commitment construction is awaiting an external cryptography review, and the v0.2 specification stays the normative text until v0.3 is frozen. Details can still change.

Published at /profiles/delegus-base-v3. Until v0.3 is frozen, the document changes with each release-candidate edit and its hash moves with it; every receipt pins the exact bytes it was decided under, and the hash is fixed at the freeze.

What v3 adds#

New relying parties start on v3. A relying party registered earlier stays on delegus-base-v1, unchanged, until it moves.

• Budgets. A Grant can cap total spend, spend per period, or the number of uses. Check P21 asks whether the action fits; the spend itself is the last step, trust check T7, so a refusal never spends. See Budgets.
• Dependencies. An action can declare which earlier decisions it rests on, in relies_on, and the relying party can state which ones it requires, in requires. Checks D1–D7 test them. Each entry has a mode: PRIOR_DECISION (the earlier decision was genuine and an ALLOW) or CURRENT_AUTHORITY (and the Grant behind it is still in force now).
• Seller-side actions. Three new action types: commerce:quote, commerce:accept and commerce:fulfil.
• Receipt v2 (delegus-receipt-v2). The receipt pins the matched authority by a commitment instead of carrying it in plain text; the plain text comes back beside the receipt, to the relying party only. On an ALLOW it also carries a transaction handle that lets the relying party link its own receipts in one transaction.
• Standing. Under delegus-trust-v3, T1 also asks whether the company is in good standing (see below).

Words used on this page:

• Grant: the signed grant of authority a company (the Principal) gives its agent. Each entry in it is a Capability: an action type with its limits.
• Proof (in plain words, the proof of grant): the agent's short-lived signature over one request, showing it holds the Grant for this exact action.
• Action: what the relying party says the agent is trying to do.
• Relying party: the business that receives the request and asks Delegus Check to verify it.

Protocol checks#

Each check is true, false or "skipped". Protocol checks are designed to be reproducible by anyone given the Grant, Proof, Action, relying-party DID, a clock, the issuer's DID document snapshot, the status-list credential snapshot and, for budgeted Capabilities, the consumption snapshot. D2–D7 are reproducible by a party entitled to the dependency disclosure package; D5 is Delegus's attestation.

P1–P20 are the v1 checks, with P15 applying the v0.3 Action rules and P16–P20 the v0.3 action types. In plain words, the new ones:

• P21, budget headroom. If the matching Capability has a budget, does this action fit in what is left? When several Capabilities match, the first in Grant order with headroom, or with no budget, is the one used. If Delegus cannot read the counts for a budgeted Capability, P21 fails with SERVICE_UNAVAILABLE.
• D1, required dependencies declared. Everything the relying party requires, the agent's action declares, with the same mode. Only the agent declares; the relying party can require but cannot add to the agent's signed action.
• D2, the earlier decision exists. The fingerprint the action names opens to a receipt Delegus Check issued. A fingerprint names a receipt without revealing which one.
• D3, it is genuine. That receipt's Delegus Check signature is valid.
• D4, it was an ALLOW.
• D5, same transaction. All the declared earlier decisions belong to one transaction.
• D6 and D7, still in force (CURRENT_AUTHORITY only). The Grant behind the earlier decision has not expired (D6) or been revoked (D7) since. For PRIOR_DECISION, D6 and D7 are "skipped".

D1 runs once; D2–D7 run for each declared entry, in the order the action lists them. Each Dn is false if any entry fails it. An action with no relies_on, for a relying party that sends no requires, has D1–D7 true.

Trust checks: delegus-trust-v3#

Trust checks are Delegus's own attestation about the service state (who is registered, key status, replay, budgets). They are not reproducible offline by design.

delegus-trust-v3 is T2, T3, T5, T1 strengthened with standing, and T7 (trust configuration trust_0003). delegus-trust-v2, the policy of a retired intermediate profile, was T1 as in v1, T2, T3, T5 and T7. T4 and T6 do not exist; identifiers are never reused.

Good standing. Delegus staff can suspend a company, or mark it disputed, on a misuse report, and lift that later, with a recorded reason. While a company is not in good standing, every request under its Grants gets a signed DENY with ISSUER_NOT_TRUSTED at T1. A company that is not registered at all still gets ISSUER_UNKNOWN. Receipts already signed never change. Standing is checked only for relying parties on delegus-base-v3; under delegus-base-v1, T1 is unchanged and ISSUER_NOT_TRUSTED stays reserved.

Spec §5.3 defines T1 this way: issuer is a registered Principal in good standing. Standing is Delegus trust data: staff mark a Principal suspended or disputed on a misuse report, with a reason, audited, and lift it the same way. Receipts already issued are never altered.

Evaluation order#

P1 → T1 → T2 → T3 → P2 → P3 → P4 → P5
   → [resolve declared dependencies; read revocation state, including each CURRENT_AUTHORITY dependency's]
   → P6 → P7 → P8 → … → P14
   → [atomic replay write]
   → T5 → P15 → … → P20
   → P21
   → D1 → (per relies_on entry) D2 → D3 → D4 → D5 → D6 → D7
   → [spend: atomic budget decrement, only if every check above is true]
   → T7

The bracketed steps are internal operations, not checks. The decision is DENY if any check is false, and reason is the first false check in this order. Dependency checks run after P21 so the agent's own reasons are reported first. The spend is last, so no request spends budget and is then refused.

What each check needs#

A check whose prerequisite did not pass is reported "skipped". P1–P20 and T1–T5 keep their v1 prerequisites (see DENY reason codes). v3 adds:

So a replayed, revoked, expired or wrongly addressed request never reads or spends budget, and never has its dependencies evaluated.

protocol.result differs from v1 when a trust check fails. Because P21 and D1–D7 wait on T1–T3 and T5, a v3 receipt refused by a trust check (for example PROOF_REPLAYED) shows those checks "skipped" and protocol.result: "FAIL", although no P-check is false. Under v1 the same replay shows protocol.result: "PASS". The decision and reason are the same. Read the reason from reason, never from protocol.result.

A dependency or budget refusal uses up the Proof. Both come after T5, so the agent needs a fresh Proof to try again.

Earlier version: delegus-base-v1 (v0.2)#

delegus-base-v1, with trust policy delegus-trust-v1 and receipt format delegus-receipt-v1, is the v0.2 profile. It stays published and frozen; delegus-base-v3 is the default. It is kept here for history and for every relying party that has not chosen v3; its receipts keep verifying under v0.2 rules.

The full v1 table is at /profiles/delegus-base-v1.

The receipt names the matched authority by authority_commitment (spec §5.6, §6.2, §6.3, §R.6).

History#

The profile document is pinned by hash in every receipt, so its bytes never change; a change is a new profile with a new name. The published delegus-base-v3, served at /profiles/delegus-base-v3, has this hash:

sha256:dffe1a6e71459fc55fb2469689a7c2da6bb2b5abbdcc0091906d8ac06cd374cd

On 25 Sep 2026 an interim build published one revision with a reworded sentence by mistake (the first hash below). It was reverted the same day. No production receipt pins it. It stays retrievable by hash at GET /evidence/{sha256}. Receipts from the development environment may pin it, or an earlier draft (the second):

sha256:c3fb3b6fb525aeca4988da10c1bdd045aaa9ae1c4eaa9f3076a0f309d4efa4be
sha256:fcd03a43febc57e3420c31856b8ef3ca3b4082e3eb0dda5253e2a28c3c613550