The IETF draft: a receipt signed before the agent acts#
draft- (revision -10, June 2026) is an individual Internet-Draft with Informational intended status, not adopted by a working group. It defines a "Delegation Receipt Protocol" whose receipt is, in the draft's own terms, "a signed Authorization Object produced by the User prior to any agent action." The user's own key signs it — "the User's private key is the sole signing authority" — and the receipt is "published to an append-only log before the agent runtime receives control." The verifier is the agent itself: "before executing any action, the Agent MUST perform all of the following checks." Revocation is defined through a revocation log indexed by receipt id; no retention period is stated; no third-party verifier role exists, and audit relies on the public log being "provable … without additional trust assumptions." The draft scopes itself to "user-to-operator trust" and positions itself as complementary to OAuth token exchange and WIMSE. The implementations it lists are the author's SDK and hosted service.
The Delegus Decision Receipt: a record signed after verification#
A Delegus Decision Receipt (specification v0.2, §6) is produced by a third party — neither the buyer nor the seller — after it has verified a specific action. The relying party that received the agent's action makes one /verify call; Delegus Check checks signatures, validity, revocation, audience, freshness, replay and scope in a fixed published order, and signs a record of the decision. That record pins hashes of the grant presented, the exact request, the company's key document and revocation list as they stood, the rules applied and the evaluation time; it is issued for DENY as well as ALLOW, with the first failing check as the reason; and anyone holding it and the evidence it names can re-run the open protocol and reproduce the decision without calling Delegus, using the receipt's own signed clock. The evidence is retained, retrievable by hash, for seven years as v0.2 specifies.
Side by side#
| Delegation receipt (draft-nelson) | Decision Receipt (Delegus v0.3 rc1; v0.2 frozen) | |
|---|---|---|
| Signed by | the human user | Delegus, a third party |
| Produced | before the agent acts | after verifying a specific action |
| Verified by | the agent, before acting | the relying party, via /verify; anyone, offline, afterwards |
| Answers | "did the user authorize this agent?" | "was this action, by this agent, for this company, authorized — and who checked?" |
| Recipient's role | none defined | the caller and the keeper of the record |
| DENY | denied calls logged | a signed receipt with a reason code |
| Revocation | revocation log by receipt id | read-after-write: a successful revoke is seen by every later verify |
| Retention | append-only log; no period stated | receipt and evidence: seven years, write-once (no one, including Delegus, can change them) |
| Format | canonical JSON, Ed25519 / P-256, optional WebAuthn | compact JWS (EdDSA) over JCS; grants as VCs; proofs bound per request |
| Status | individual Informational I-D, rev -10 | v0.2 frozen; reference engine and vectors public |
Neither replaces the other. One is an input-side artifact (what the user permitted); the other is an output-side artifact (what a neutral verifier decided about a concrete action, and on what evidence).
How they could relate#
Delegus is designed to compile more than one upstream form of authority into one internal representation before evaluation. Today /verify accepts only Delegus Grants. A delegation receipt in the draft's sense is a plausible input to a Grant: a company's Principal could cite a user-signed Authorization Object, out of band, as the basis on which it issued a Grant to the agent, and the Grant — not the delegation receipt — is what the relying party's /verify call evaluates. The Decision Receipt would then pin the Grant (its hash over the exact bytes presented). A v0.2 Grant carries exactly the fields the specification defines and a verifier rejects any other at the first check, so there is no field today in which a Grant could reference a delegation receipt by hash; a future Grant version could add one. Nothing in v0.2 requires or defines any of this; it is an adapter question, and no interoperability has been attempted or claimed.
What Delegus is not designed to do is act as a verifier for the draft's protocol, because that protocol places verification inside the agent and defines no external verifier role.
Why the distinction matters to an integrator#
If you build the receiving side — an API, a marketplace, a service that takes actions from agents — a user-signed permission slip carried by the agent tells you what the user intended, in a form you would have to verify yourself and keep yourself. A Decision Receipt tells you that a neutral party checked this action against this company's signed authority, and hands you the signed answer to keep. The two can work together; they answer different questions.
Related: Specification v0.2 §6 and §8 · Receipts and offline re-verification · draft-nelson-agent-delegation-receipts
Under v0.3#
Under the v0.3 release candidate, the Decision Receipt changes form (
delegus-) but not role. It pins the matched authority by a commitment instead of carrying it in plaintext, and receipts become private by default: anyone holding one checks it is authentic, while checking what it pins (the matched authority, the earlier decisions it relied on) takes material only its relying party and principal can obtain. A later action can also declare that it depends on an earlier Decision Receipt; see Relying on earlier decisions.receipt- v2
Under v0.3 (the current release candidate), three Delegus cells change: Verified by becomes "anyone checks authenticity offline; checking what it pins needs its parties' material"; Retention becomes "receipt and evidence: seven years, write-once; receipts retrievable only by their parties"; and a Decision Receipt can be declared as a dependency of a later one. Nothing on the draft-nelson side is affected.