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 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.2) | |
|---|---|---|
| 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 | seven years, retrievable by hash |
| 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. 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