Signed Permissions and Action Receipts for Automated Agents
draft-izmaylov-agent-permission-receipts-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Pavel Izmaylov | ||
| Last updated | 2026-10-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-izmaylov-agent-permission-receipts-00
Network Working Group P. Izmaylov
Internet-Draft 6 October 2026
Intended status: Standards Track
Expires: 9 April 2027
Signed Permissions and Action Receipts for Automated Agents
draft-izmaylov-agent-permission-receipts-00
Abstract
Automated agents, such as artificial intelligence (AI) agents, act
for people. This document specifies records that let anyone check,
later and offline, what an agent was allowed to do and what it
recorded doing: a permission a person signs with a passkey, with
limits a machine can check; a receipt the agent signs for each
action, with Ed25519 and the post-quantum Module-Lattice-Based
Digital Signature Algorithm (ML-DSA-87); and a log whose tree head is
signed and time-stamped. A verifier says whether each action stayed
within its permission, apart from whether the records are sound.
Note to Readers
Note to the RFC Editor: please remove this note before publication.
The contribution is the content model and the comparison rule: a
principal-signed permission with limits a machine can check,
acknowledged cancellation, and a verifier that says whether each
action, a helper agent's included, stayed within it. The JSON Web
Signature (JWS) encoding is not essential; a CBOR Object Signing and
Encryption (COSE) form and a Supply Chain Integrity, Transparency,
and Trust (SCITT) registration profile can be added if a working
group prefers them.
Comments are welcome, in writing: by email to the author, or as
issues at https://github.com/provared/provared/issues.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Izmaylov Expires 9 April 2027 [Page 1]
Internet-Draft Agent Permission Receipts October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Example . . . . . . . . . . . . . . . . . . . . 4
4. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The Permission . . . . . . . . . . . . . . . . . . . . . . . 10
6. Action Receipts . . . . . . . . . . . . . . . . . . . . . . . 12
7. Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Cancellation and Acknowledgement . . . . . . . . . . . . . . 14
9. Logs, Signed Tree Heads and Time-Stamps . . . . . . . . . . . 15
10. Verification . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Relationship to Other Work . . . . . . . . . . . . . . . . . 19
12. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 21
13. Parts Specified Elsewhere . . . . . . . . . . . . . . . . . . 21
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
16. Security Considerations . . . . . . . . . . . . . . . . . . . 23
17. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
19.1. Normative References . . . . . . . . . . . . . . . . . . 24
19.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Codes . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Shared List . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
Izmaylov Expires 9 April 2027 [Page 2]
Internet-Draft Agent Permission Receipts October 2026
1. Introduction
When an automated agent acts for a person, the questions asked
afterwards are the same: was the action authorized, by whom, within
what limits, did the other party agree, and when? Authorization
protocols answer at the moment of a request, with tokens that are not
kept. This document is about records that a third party can verify
later, with no network access. Each record is signed by the party
that made it. Whoever keeps the log can still leave out or delay
entries; Section 16 states how far that reaches.
The records reuse JSON Web Signature (JWS) [RFC7515] over JavaScript
Object Notation (JSON) in one canonical form [RFC8785], the Merkle
tree of [RFC9162], and time-stamps from a Time-Stamping Authority
(TSA) [RFC3161]. Agents sign with Ed25519 [RFC8032] and the Module-
Lattice-Based Digital Signature Algorithm ML-DSA-87 [FIPS204] side by
side; a signed tree head adds the Stateless Hash-Based Digital
Signature Algorithm SLH-DSA [FIPS205].
Other drafts (Section 11) already have principal-signed
authorizations and delegation that only narrows. This document adds
limits a machine can check (totals, single amounts, counts, and
totals or counts within a rolling period) and conditions (the other
party's countersignature, or the principal's approval of one action)
to a permission the principal signs with a passkey [WebAuthn];
acknowledged cancellation; and a verifier that says whether each
recorded action, a helper agent's included, stayed within them. The
JWS encoding is not essential; a CBOR Object Signing and Encryption
(COSE) form and a Supply Chain Integrity, Transparency, and Trust
(SCITT) registration profile can be added if a working group prefers
them.
The records are evidence, not a verdict: a sound record can show an
agent acting outside its permission. This document is the core of a
published format description [FORMAT]; Section 13 lists the parts
specified only there.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The format's own names, as used in its labels and members, are given
in parentheses.
Izmaylov Expires 9 April 2027 [Page 3]
Internet-Draft Agent Permission Receipts October 2026
Principal: The person who signs a permission with a passkey
("issuer").
Passkey: A credential [WebAuthn] in a device, unlocked by user
verification such as a biometric or a personal identification
number (PIN).
Agent: Software that acts for the principal and deals with services,
which may countersign. A helper agent acts under a delegation.
Permission: The principal's signed statement of which agent may do
what, within which limits, with whom and when ("slip").
Action receipt, or receipt: The agent's signed statement that it
took one action ("stub"). It is not a SCITT Receipt (Section 11).
Delegation: An agent's signed hand-over of part of its permission
("pass").
Log: A sequence of entries, one to a line, only ever added to
("book").
Recorder, signed tree head: Whoever keeps a log; its signed
statement of the log's size and root ("seal").
Verifier: Anyone, or any software, that verifies records
("checker").
Digest: The SHA-256 hash [FIPS180-4] of some bytes, in base64url.
Problem, sound: A reason why an entry, or the log, cannot be relied
on; an entry with none is sound.
Finding: A statement that a sound receipt or delegation lies outside
its permission. A finding is not a problem.
Intact: Of a log: no problem was found and everything was verified
(Section 10.1).
Base64url is that of Section 5 of [RFC4648], without padding. Where
a rule is followed by a code in parentheses, such as "(chain-
broken)", an entry that breaks the rule has a problem. A verifier
reports that code for it, unless it stopped at an earlier fault of
the same entry (Section 10.1). Every finding of a compared receipt
or delegation is reported: each code once, except over-period-limit,
which is reported once for each period limit exceeded. Appendix A
lists the codes.
3. Overview and Example
Once the principal has signed a permission, the agent signs a receipt
for each action, naming the permission and the receipt before it.
The recorder writes each receipt, with any countersignature and
approval, as one log line, and now and then appends a time-stamped
signed tree head. This example follows the demonstration published
with [FORMAT]; the parties and orders are invented. An office agent
may order supplies up to 200 GBP in total and 100 GBP for one order,
and send two messages in any hour. Every order needs the supplier's
countersignature, and an order above 60 GBP the principal's approval.
The permission's content is shown with spaces and line breaks added,
Izmaylov Expires 9 April 2027 [Page 4]
Internet-Draft Agent Permission Receipts October 2026
and values abbreviated:
{"actions": ["supplies.order", "message.send"],
"agent": {"keys": ["<Ed25519>", "<ML-DSA-87>"], "name": "Agent"},
"id": "<base64url>",
"issuer": {"key": "<ES256>", "name": "A. Person",
"origin": "https://sign.example.org", "rpId": "example.org"},
"limits": [
{"action": "supplies.order", "max": 200, "unit": "GBP"},
{"action": "supplies.order", "each": 100, "unit": "GBP"},
{"action": "message.send", "count": 2, "per": 3600}],
"never": ["destroys", "impersonate"],
"purpose": "Keep the office stocked with paper and toner.",
"requires": [
{"action": "supplies.order", "need": "countersignature"},
{"above": 60, "action": "supplies.order", "need": "approval",
"unit": "GBP"}],
"type": "provared.slip.v0",
"validFrom": "2026-10-05T09:00:00Z",
"validUntil": "2026-10-12T09:00:00Z",
"with": [{"id": "supplier", "keys": ["<Ed25519>", "<ML-DSA-87>"],
"name": "Example Stationery"}]}
The log then holds these entries ("receipt n" has "seq" n; "cs" is a
countersignature):
Entry Record Action, amount With it Total Findings
0 permission
1 receipt 0 order, 45 GBP cs 45
2 receipt 1 message
3 receipt 2 order, 80 GBP approval, cs 125
4 receipt 3 order, 25 GBP 150 countersignature-
missing
5 receipt 4 order, 80 GBP cs 230 over-limit,
approval-missing
6 signed tree head time-stamp
The content of the receipt at entry 5, shown across lines, is:
{"action":"supplies.order","amount":{"unit":"GBP","value":80},
"id":"<base64url>","previous":"<digest of the receipt at 4>",
"seq":4,"slip":"<digest of the permission>",
"type":"provared.stub.v0","when":"2026-10-05T09:40:00Z",
"with":"supplier"}
Izmaylov Expires 9 April 2027 [Page 5]
Internet-Draft Agent Permission Receipts October 2026
Given the principal's key thumbprint, the recorder's key-set digest
and the TSA's certificate digest, a verifier finds no problem and
verifies every signature: the log is intact. It reports that the
agent did not stay within its permission, at entries 4 and 5.
4. Common Rules
4.1. Envelope and Labels
Every record is a JWS in the General JWS JSON Serialization
(Section 7.2.1 of [RFC7515]). It MUST hold exactly the members
"payload" and "signatures". Each element of "signatures" MUST hold
exactly "protected" and "signature" and, for a record signed with a
passkey (Section 4.7), also "header", which holds exactly
"authenticatorData" and "clientDataJSON" (bad-envelope). Each
signature covers the JWS Signing Input (Section 5.1 of [RFC7515])
formed from "protected" and "payload" as carried.
The protected header of each signature, once decoded, MUST be exactly
the UTF-8 bytes of {"typ":"T","alg":"A"}, with no white space and the
two members in that order. A verifier compares bytes and interprets
nothing else. A header that is not a known text is a problem
(unknown-type). One that belongs to another kind of record than the
one expected is a problem too (payload-type-mismatch). The number
and order of the signatures are fixed (bad-signatures-layout).
For each kind of record, with X as below, T is
"vnd.provared.X.v0+json" and the content's "type" is "provared.X.v0".
A takes these values in signature order, W being "prova.red/webauthn/
v0":
slip: Permission: W
stub: Action receipt: Ed25519, ML-DSA-87
countersignature: Countersignature: Ed25519, ML-DSA-87
approval: Approval: W
pass: Delegation: Ed25519, ML-DSA-87
cancellation: Cancellation: W
acknowledgement: Acknowledgement: Ed25519, ML-DSA-87
seal: Signed tree head: these two, then SLH-DSA-
SHA2-256s
Izmaylov Expires 9 April 2027 [Page 6]
Internet-Draft Agent Permission Receipts October 2026
Each label ends in "v0", so that a record of a later, frozen version
cannot be taken for a draft one. "typ" is the media type of the
record (Section 4.1.9 of [RFC7515]), used for explicit typing
(Section 3.11 of [RFC8725]); being signed, it stops a signature made
for one kind of record passing as another. "Ed25519" is registered
by [RFC9864] and "ML-DSA-87" by [RFC9964]. "SLH-DSA-SHA2-256s",
named in [FIPS205], and "prova.red/webauthn/v0", a collision-
resistant name (Section 4.1.1 of [RFC7515]), are not registered.
4.2. Content
The content of a record is the decoded "payload". It MUST be a JSON
object in UTF-8, in the canonical form of [RFC8785]: a verifier
serializes it again and refuses it if a single byte differs (payload-
not-canonical). This refuses repeated member names, white space and
members out of order. The content MUST hold only objects, arrays,
strings and integers from 0 to 2^53 - 1. It holds no "true",
"false", "null", fractions, exponents or negative numbers, and no
unpaired surrogate, even escaped. Objects and arrays MUST NOT nest
more than 8 levels deep, the content itself being the first (payload-
not-canonical). The signed bytes are verified as signed; the
canonical form is a test, never a rewrite.
"type" MUST match the labels (payload-type-mismatch). An object MUST
hold exactly the members listed for it, each in its stated form (bad-
field). Lengths of text are counted in Unicode code points.
A record MUST NOT exceed 65,536 characters, counted as the length of
"payload" plus the lengths of every string in its signature entries,
"header" included (too-large).
4.3. Values
Base64url: A verifier MUST refuse padding, a character outside the
alphabet, a length that leaves 1 when divided by 4, and unused
bits that are not zero (bad-base64url).
Identifier: An "id" is 16 random bytes in base64url. No two records
in a log hold the same "id" (duplicate-id).
Time: "YYYY-MM-DDTHH:MM:SSZ", an [RFC3339] date-time in Coordinated
Universal Time (UTC), to the second, with no fraction or offset.
It MUST exist: "2026-02-29", hour 24 and second 60 are refused
(bad-field).
Digests: A record's digest is that of its content bytes as signed,
covering no signature; records name one another by it. A "sha256"
member holds a document's digest: records never hold documents.
Name: Text of 1 to 200 code points, chosen by the writer and never
checked against anything.
Amount: Exactly {"unit", "value"}, where "value" is an integer and
Izmaylov Expires 9 April 2027 [Page 7]
Internet-Draft Agent Permission Receipts October 2026
the unit is 1 to 16 ASCII letters, digits, ".", "-" or "_",
beginning with a letter or digit.
4.4. Keys
Keys are JSON Web Keys (JWK) [RFC7517] of exactly these shapes, with
no other member (bad-key):
{"alg":"Ed25519","crv":"Ed25519","kty":"OKP","x":X} X: 32 bytes
{"alg":"ML-DSA-87","kty":"AKP","pub":P} P: 2592 bytes
{"alg":"SLH-DSA-SHA2-256s","kty":"AKP","pub":P} P: 64 bytes
{"alg":"ES256","crv":"P-256","kty":"EC","x":X,"y":Y} X, Y: 32 bytes
{"alg":"RS256","e":"AQAB","kty":"RSA","n":N} N: 2048-8192 bits
These follow [RFC8037], Section 3 of [RFC9964] (the Algorithm Key
Pair, "AKP", key type) and Section 6 of [RFC7518]; "n" has no leading
zero byte. The key set of an agent or a service is exactly Ed25519
then ML-DSA-87; a recorder's adds SLH-DSA-SHA2-256s; a principal's
passkey is one ES256, RS256 or Ed25519 key.
A verifier is told which principals it trusts by key thumbprints:
[RFC7638] with SHA-256, over the members required by Section 3.2 of
[RFC7638], Section 2 of [RFC8037] for "OKP" and Section 6 of
[RFC9964] for "AKP". It is told which recorders it trusts by key-set
digests: the digest of the key set written in the canonical form.
4.5. Hybrid Signatures
A receipt, a countersignature, a delegation and an acknowledgement
carry two signatures over the same payload: Ed25519 (Section 5.1 of
[RFC8032], as Section 4.6 requires), then ML-DSA-87 (pure ML-
DSA.Verify of [FIPS204] with an empty context, as Section 5 of
[RFC9964] requires). A signed tree head adds a third, SLH-DSA-
SHA2-256s (pure slh_verify of [FIPS205] with an empty context). Each
is verified with the key in the same place of the key set that
applies: the agent's or a service's keys in the permission, a
helper's keys in its delegation, or the recorder's keys in the head.
Every signature MUST verify; one that fails is a problem (signature-
invalid).
A signature whose algorithm the verifier lacks is not verified
(Section 10.1). An entry none of whose signatures was verified is
not evidence: what it says MUST NOT be shown as fact.
Izmaylov Expires 9 April 2027 [Page 8]
Internet-Draft Agent Permission Receipts October 2026
4.6. Ed25519 Verification
[RFC8032] leaves verifiers choices, and verifiers that choose
differently disagree. With public key A, signature halves R and S,
message M, base point B, group order L, and n*P for the point P
multiplied by the integer n, a verifier MUST:
1. refuse S unless, read as a little-endian integer, it is less than
L;
2. refuse A or R unless it decodes to a point on the curve, which
includes refusing an encoded y of p or more (Section 5.1.3 of
[RFC8032]);
3. refuse A or R of small order, that is, one of the eight points
whose order divides 8, the identity among them; and
4. accept only if S*B = R + k*A, with k the SHA-512 hash of R, A and
M reduced modulo L. A signature that satisfies only the equation
multiplied by the cofactor, 8*S*B = 8*R + 8*k*A, is refused.
These rules apply to every Ed25519 signature, a passkey's included; a
key of large order plus small order is not refused by them.
4.7. Passkey Signatures
A permission, an approval and a cancellation carry one signature by
the principal's passkey. The signer asks the passkey for an
assertion whose challenge is the SHA-256 hash of the JWS Signing
Input, with user verification "required". It stores, in base64url
and exactly as returned, "authenticatorData" and "clientDataJSON" in
"header", and the signature in "signature".
A verifier checks the signature against the "key", "rpId" and
"origin" of the "issuer" of the permission concerned. It follows
Section 7.2 of [WebAuthn] as far as it applies to a later check with
no state, and MUST confirm that:
1. the client data is UTF-8 with no byte order mark and is a JSON
object, read by a JSON parser: white space and member order are
free, and a repeated member is read as its last occurrence
(passkey-bad-data);
2. its "type" is "webauthn.get" (passkey-wrong-type);
3. its "challenge" is the base64url of the SHA-256 hash of the JWS
Signing Input (passkey-challenge-mismatch);
4. its "origin" is the same string as the issuer's, and
"crossOrigin" is not the JSON value true (passkey-origin-
mismatch); other members are not used;
5. the authenticator data is at least 37 bytes (passkey-bad-data)
and begins with the SHA-256 hash of "rpId" (passkey-rpid-
mismatch);
Izmaylov Expires 9 April 2027 [Page 9]
Internet-Draft Agent Permission Receipts October 2026
6. its flags have "user present" (bit 0) and "user verified" (bit 2)
set (passkey-user-not-present, passkey-user-not-verified), and
"attested credential data" (bit 6) clear; without "extension
data" (bit 7) it is exactly 37 bytes (passkey-bad-data). Further
bytes and other flags are not examined. So the [WebAuthn] rule
that "backup state" (bit 4) is clear when "backup eligible" (bit
3) is clear is not checked; and
7. the signature verifies over the authenticator data followed by
the SHA-256 hash of the client data (signature-invalid). An
ES256 signature, made with the Elliptic Curve Digital Signature
Algorithm (ECDSA) (Section 3.4 of [RFC7518]), is stored as an
ECDSA-Sig-Value in strict Distinguished Encoding Rules (DER)
[X690]. It is one SEQUENCE with a one-byte length, two positive
INTEGERs of 1 to 33 bytes in their shortest form, nothing after
(passkey-bad-data). Either value of s that verifies is accepted.
RS256 is Section 3.3 of [RFC7518].
The signature counter, the credential identifier and the user handle
are not used. For an approval or a cancellation, a failure is
reported as approval-invalid or cancellation-invalid. If the
verifier was given thumbprints of trusted passkeys, the issuer's key
MUST be one (issuer-not-expected); if it was given none, it MUST say
that the key was not compared with a trusted key.
4.8. Records Relied On
An entry that relies on another record names it by its digest. That
record MUST be earlier in the log and sound. Otherwise the entry has
a problem: slip-missing or slip-unusable for a permission; pass-
missing for a delegation, or pass-mismatch if it is under another
permission; and cancellation-not-found for a cancellation. A
permission or a delegation is judged as it stood when it was itself
read. A problem that a later entry adds to it (dated-after-stamp,
Section 9.3) changes nothing for the entries that rely on it, though
it remains a problem of the log. A cancellation named by an
acknowledgement is judged again once the whole log has been read; if
it has a problem then, the acknowledgement is reported cancellation-
not-found.
5. The Permission
A permission's content holds exactly these members, all required but
"passes":
"type": "provared.slip.v0"
"id": An identifier.
"issuer": The principal: exactly "key", "name", "origin" and "rpId",
below.
Izmaylov Expires 9 April 2027 [Page 10]
Internet-Draft Agent Permission Receipts October 2026
"agent": Exactly "keys" (a key set) and "name", and optionally
"software": 1 to 16 objects {"name", "sha256"}, digests of the
program and settings the principal approved. It is a statement,
not proof of what ran.
"actions": 1 to 64 action names, none repeated.
"limits": 0 to 64 limits (Section 5.1).
"requires": 0 to 64 conditions (Section 5.1).
"never": 0 to 16 names, none repeated (Section 5.1).
"with": 0 to 64 services, {"id", "name"} or {"id", "keys", "name"};
"id" has the form of an action name, may begin "provared.", and is
unique. A service with no "keys" cannot countersign.
"passes": An integer from 1 to 10 (Section 7).
"validFrom", "validUntil": Times, the second later than the first.
The permission covers "validFrom" up to, but not including,
"validUntil".
"purpose": Text of 1 to 1,000 code points.
"rpId" is the WebAuthn Relying Party ID: 1 to 253 lower-case ASCII
letters, digits, "." and "-", beginning and ending with a letter or a
digit. "origin" is at most 300 characters. It MUST be equal to the
ASCII serialization (Section 6.2 of [RFC6454]) of its own origin
(Section 4 of [RFC6454]). So it has no path, no "/", no user
information, no default port, and no leading zero in a port. Its
scheme MUST be "https", or "http" with the host "localhost". Its
host MUST be "rpId" or end with "." and "rpId".
An action name is 1 to 64 lower-case ASCII letters, digits, ".", "-"
and "_", beginning with a letter or a digit. Names are compared
exactly. Names beginning "provared." are reserved for the shared
list of Appendix B, and an action name that begins so MUST be on it
(bad-field). Any other member, such as those by which [FORMAT]
covers fields, is a problem for a verifier of this document alone
(bad-field).
5.1. Limits, Conditions and Prohibitions
A limit names an "action" from "actions" (bad-field) and holds
exactly one of "max", "each" and "count":
{"action","max","unit"} the amounts added up: at most max
{"action","each","unit"} no single amount above each
{"action","count"} at most count receipts (count >= 1)
{"action","max","per","unit"} as max, in any period of per seconds
{"action","count","per"} as count, in any period of per seconds
Izmaylov Expires 9 April 2027 [Page 11]
Internet-Draft Agent Permission Receipts October 2026
"per" is from 1 to 31,622,400 seconds (366 days). No two limits have
the same "action", the same choice of "max", "each" or "count", and
the same "per" or none. Every "unit" named for one action, in limits
and conditions, MUST be the same: a receipt gives one amount.
A condition is {"need": "countersignature"} or {"need": "approval"}.
It may hold "action", which MUST be one of "actions" (bad-field);
without it, the condition applies to every action. It may hold
"above" and "unit", which come together, need "action", and limit the
condition to amounts above "above". No two conditions have the same
"need" and the same "action" or none. "countersignature" asks for the
service's countersignature (Section 6); "approval" asks for the
principal's approval.
"never" names kinds of action and rules of conduct from Appendix B.
A permission MUST NOT allow, in "actions", a shared action of a kind
that its "never" names (bad-field). A rule of conduct is the
principal's signed instruction; no check of a record shows that it
was kept.
6. Action Receipts
A receipt's content holds exactly:
"type": "provared.stub.v0"
"id": An identifier.
"slip": The digest of the permission.
"seq": Its place in its chain, from 0.
"previous": The digest of the receipt before it; present if and only
if "seq" is not 0.
"action": An action name.
"amount", "with": Optional: an amount; the "id" of a service.
"details": Optional: 1 to 32 objects {"name", "sha256"}, the
documents involved.
"approval", "pass": Optional: the digest of an approval; of the
delegation a helper acts under.
"terms": Optional, with "with": the digest of a service's terms
[FORMAT].
"when": The time of the action, as the agent states it.
The permission and any delegation named are records relied on
(Section 4.8). Both signatures MUST verify with the agent's keys or,
for a helper, with the "to" keys of its delegation (signature-
invalid). A verifier of this document alone accepts no terms entry,
so it reports a receipt that holds "terms" as terms-not-found.
Izmaylov Expires 9 April 2027 [Page 12]
Internet-Draft Agent Permission Receipts October 2026
The receipts of the permission's own agent form one chain, and those
under each delegation another. In each chain, in log order, the
first has "seq" 0. Each later one has the next "seq" and names the
one before in "previous" (chain-broken), and is not dated before it
(time-went-backwards). A receipt with a problem keeps its place in
its chain, provided its content could be read and the records it
relies on were found: the next receipt is checked against it. So one
break is reported once.
A countersignature has exactly the content {"stub": the receipt's
digest, "type": "provared.countersignature.v0", "when": a time}, and
means "this action happened with me". It is carried on the receipt's
log line and signed with the key set the permission gives for the
service the receipt names in "with". A verifier MUST confirm "stub"
(countersignature-wrong-stub), that such keys exist
(countersignature-not-possible), and both signatures
(countersignature-invalid). A receipt without one is one-sided: a
named state, not a problem, showing what the agent said.
An approval is the principal's approval of exactly one action. Its
content holds exactly "type" ("provared.approval.v0"), "id", "slip",
"action" and "when", and optionally "amount", "with" and "details".
It is signed with the permission's passkey and carried on the
receipt's line, and the receipt names it by its digest. The receipt
MUST name the approval on its line (approval-mismatch), and an
approval it names MUST be there (approval-not-found). The approval's
"slip", "action", "amount", "with" and "details" MUST match the
receipt's, each present in both or neither (approval-mismatch). Its
"id" MUST NOT be that of an approval on an earlier line (approval-
reused) or of another record (duplicate-id). Its passkey signature
MUST verify against the permission's "issuer" (approval-invalid). It
MUST NOT be dated more than 300 seconds after the receipt, which was
signed after it (approval-dated-after-stub). An approval shows that
the passkey approved the action, not that the principal read it.
7. Delegation
"passes" says how many times in a row a permission may be delegated:
1 lets its agent delegate to a helper, 2 lets that helper delegate
once more, up to 10. Without it, a permission may not be delegated.
A delegation's content holds exactly:
"type", "id", "slip": "provared.pass.v0"; an identifier; the
permission's digest.
"from": The digest of the delegation its writer acts under; absent
when the writer is the permission's own agent.
"to": The helper: exactly {"keys": key set, "name": name}.
"actions", "limits": As in a permission, the limits naming only
Izmaylov Expires 9 April 2027 [Page 13]
Internet-Draft Agent Permission Receipts October 2026
these actions.
"validFrom", "validUntil", "when": Its validity, as in a permission;
when it was written.
It is signed by its writer: with the agent's keys or, with "from",
the "to" keys of that delegation (signature-invalid). The permission
and the delegation in "from" are records relied on (Section 4.8).
Its depth is 1 without "from", otherwise one more than that of
"from"; a depth above 10 is a problem (pass-too-deep).
A verifier reports these findings for a delegation. It reports pass-
not-allowed if the depth exceeds "passes" (0 if absent), and pass-
wider if an action is not among its writer's, or its validity starts
earlier or ends later than the writer's. It reports outside-valid-
time if "when" is outside the writer's validity, and after-
cancellation as Section 8 sets out.
A receipt under a delegation is compared with the permission as the
agent's own receipts are, sharing their totals, conditions and
"never". It is also compared with its delegation, whose "actions",
"limits" and validity count as a permission's, and with every
delegation above it; each delegation's totals include everything
delegated from it. A finding code already given for the receipt is
not repeated. Receipts under or below a delegation reported pass-
not-allowed are reported pass-not-allowed. Since the limits of the
permission and of every delegation above always apply, a delegation
cannot widen a permission.
8. Cancellation and Acknowledgement
A cancellation has exactly the content {"id", "slip", "type":
"provared.cancellation.v0", "when"}. It is signed with the
permission's passkey and verified against its "issuer" (cancellation-
invalid); the permission is a record relied on (Section 4.8). Its
entry may hold "stamps" over its digest (Section 9.3), which the
principal can obtain at once.
Take the first cancellation of a permission in the log that is sound
when it is read, and whose passkey signature, and its permission's,
were verified. Every receipt and delegation under the permission
after it in the log is reported after-cancellation.
Izmaylov Expires 9 April 2027 [Page 14]
Internet-Draft Agent Permission Receipts October 2026
Section 22 of [FORMAT] adds a stricter rule for a time-stamped
cancellation. A receipt before it in the log is also reported,
unless a time-stamp on an earlier head shows that the receipt existed
by the cancellation's time, within 300 seconds. This document does
not specify that rule (Section 14). Without that rule, a verifier
applying only this document can miss receipts made after a
cancellation.
A cancellation does not show that the agent was told; an
acknowledgement is the agent's signed statement that it was. Its
content holds exactly "cancellation" (a digest), "id", "slip", "type"
("provared.acknowledgement.v0") and "when", and optionally "pass".
It is signed with the agent's keys or a helper's (signature-invalid).
The permission, any delegation named and the cancellation, which MUST
cancel the same permission (cancellation-not-found), are records
relied on (Section 4.8). An acknowledgement changes no finding, and
its "when" is not compared with the cancellation's; its signer SHOULD
NOT date it before the last receipt or delegation its agent wrote.
Section 26 of [FORMAT] sets out how a verifier uses it with the
principal's own copy.
9. Logs, Signed Tree Heads and Time-Stamps
9.1. The Log
A log is UTF-8 text, one entry to a line, each line ended by a line
feed except perhaps the last. A log with no entry, an empty line or
a byte order mark is a problem (not-json); so is a line ending in a
carriage return (line-not-canonical). Each line is a JSON object in
the canonical form of Section 4.2, with records as values (line-not-
canonical). It holds exactly the members of one kind of entry
(unknown-entry):
"slip" (a permission); "stub", optionally with "countersignature" and
"approval" (an action receipt); "pass" (a delegation);
"cancellation", optionally with "stamps"; "acknowledgement"; or
"seal" (a signed tree head), optionally with "stamps". A verifier of
this document alone reports the four further kinds of [FORMAT]
("refusal", "terms", "vouching", "withdrawal") as unknown-entry, and
so never calls such a log intact. Entries are numbered from 0. The
same permission MUST NOT appear twice (duplicate-slip), nor the same
delegation (duplicate-id). A line MUST NOT exceed 131,072 bytes, nor
a log 100,000 entries (too-large).
Izmaylov Expires 9 April 2027 [Page 15]
Internet-Draft Agent Permission Receipts October 2026
The leaves of the tree are the lines' bytes, without line feeds, in
log order; the root is the Merkle Tree Hash of Section 2.1.1 of
[RFC9162] with SHA-256. Inclusion and consistency proofs are checked
against a size as well as a root, so the two are kept together. A
verifier given a root or a size to expect MUST compare it (root-
mismatch).
9.2. Signed Tree Heads
A signed tree head's content holds exactly "type"
("provared.seal.v0"), "id", "by" (exactly {"keys": the recorder's key
set, "name"}), "size" (at least 1), "root", "previous" (the previous
head's digest, absent for the first) and "when". A head is signed
with the three keys in "by" and appended as the next entry, so each
head covers those before it. A verifier holding the whole log MUST
confirm that:
1. the three signatures verify (signature-invalid);
2. "size" is its own place in the log, and "root" the root of the
entries before it (seal-mismatch);
3. "previous" names the nearest earlier head, or is absent if there
is none (seal-chain-broken);
4. "when" is not before that head's (time-went-backwards); and
5. if given digests of trusted recorders' key sets, that of
"by.keys" is one (sealer-not-expected); if given none, it MUST
say that the keys were not compared with trusted keys.
Section 21 of [FORMAT] adds rules that compare a head's "when" with
the times its entries state and with earlier heads' time-stamps
(time-went-backwards). This document does not specify them
(Section 14).
9.3. Time-Stamps
"stamps" holds 1 to 4 time-stamps, none repeated. A string there is
the base64url of an [RFC3161] TimeStampToken of at most 12,288 bytes,
whose "messageImprint" has the hashAlgorithm SHA-256 and a
hashedMessage equal to the 32 bytes of the record's digest, not
hashed again. An object there is a block time-stamp of [FORMAT]. It
MUST hold exactly "block" and "proof", each text (bad-field) in
base64url (bad-base64url); a verifier of this document alone does not
count it, and answers no to the second question of Section 10.1.
Time-stamps are read only if none of the record's own signatures
failed. A verifier MUST confirm that:
Izmaylov Expires 9 April 2027 [Page 16]
Internet-Draft Agent Permission Receipts October 2026
1. the token is one element with nothing after it, laid out as
[RFC3161] and [RFC5652] require: signed data of version 3 with
exactly one signer, of version 1 or 3, enclosing a TSTInfo of
version 1 (stamp-bad-data);
2. it meets these rules of DER [X690] (stamp-bad-data): definite
lengths in their shortest form; single-byte tags; every
constructed element exactly filled by its parts; every INTEGER
and OBJECT IDENTIFIER in its shortest form; every BOOLEAN 0x00 or
0xFF; every NULL empty; every BIT STRING with at most 7 unused
bits; and genTime and each certificate's validity times in the
one form DER gives them, naming a moment that exists. The order
of SET OF elements and the omission of DEFAULT values are not
checked;
3. the "messageImprint" is as above (stamp-wrong-data);
4. the signed attributes hold a content type of id-ct-TSTInfo, and
the TSTInfo's message digest made with the signer's digest
algorithm (SHA-256, SHA-384 or SHA-512). They also hold
ESSCertIDv2 ([RFC5035], [RFC5816]) or ESSCertID ([RFC2634]),
ESSCertIDv2 being used if both are present; the token carries the
certificate that its first identifier names (stamp-invalid);
5. the signature over the signed attributes verifies with that
certificate's key (stamp-invalid). The methods are RSASSA-
PKCS1-v1_5 (modulus of 2048 to 8192 bits, exponent of at most 32
bits) and ECDSA on P-256 or P-384, the signature algorithm naming
the signer's digest algorithm (for RSA, also rsaEncryption); and
Ed25519 [RFC8419]; and
6. "genTime" lies within the certificate's validity, the seconds
field of any "accuracy" is at most 300, and no extension is
critical (stamp-invalid).
A verifier is told which TSAs it trusts by the digest of each TSA's
certificate in DER; it builds no chain, checks no revocation and asks
no outside party. A time-stamp counts only if its TSA is trusted and
every signature of its record was verified (for a cancellation, also
its permission's). A sound time-stamp from a TSA not trusted MUST be
shown as such, with its certificate's digest; no time-stamp that does
not count may be used as a time. Times are taken to the second,
rounded down.
Izmaylov Expires 9 April 2027 [Page 17]
Internet-Draft Agent Permission Receipts October 2026
A counted time-stamp at time T shows that the record existed by T.
On a signed tree head that is itself sound, it also shows that every
entry before the head existed by T. An entry existed by the earliest
such time of any later sound head. A verifier MUST say "existed by",
never "existed at", and MUST say which entries the last counted time-
stamp reaches. It MUST report as dated-after-stamp a head or a
cancellation dated more than 300 seconds after the earliest time its
counted time-stamps state. It MUST report so too an entry whose
"when", or that of a countersignature or approval on its line, is
more than 300 seconds after the time by which it existed.
10. Verification
10.1. The Three Answers
A verifier is given the log and, optionally, the size and root it
expects, the thumbprints of the passkeys it trusts, and the digests
of the key sets of the recorders and of the certificates of the TSAs
it trusts. It makes no network request. It gives three answers,
kept apart:
1. Was a problem found? Yes if any entry, or the log, has one. A
signature that fails is a problem.
2. Was everything verified? Yes only if every entry was read as far
as its signatures, and no signature or time-stamp in the log was
left unverified because the verifier does not implement its
method.
3. Did each action stay within its permission? Yes only if no
problem was found, every receipt and delegation was compared, and
none gave a finding.
A verifier MUST call a log intact only if no problem was found and
everything was verified. A receipt or delegation is compared only if
it is sound, at least one of its signatures was verified and none
failed, and its permission's passkey signature was verified. So the
third answer can be yes while the second is no: for example, a
verifier without ML-DSA-87 compares receipts on their Ed25519
signatures alone. When the second answer is no, a verifier MUST say
that the third rests only on the signatures it verified, and MUST
name the signing methods it lacked.
A verifier checks each record's envelope, labels, content and
members, and finds the records it relies on, in that order. At the
first fault there, it reports that fault's code and checks nothing
further in that entry. An entry's "id" is compared with earlier
ones, and noted, once its members are read, before the records it
relies on are found (an approval's, once it matches its receipt).
Other faults of an entry (a signature, its place in a chain, a
Izmaylov Expires 9 April 2027 [Page 18]
Internet-Draft Agent Permission Receipts October 2026
countersignature, an approval, a repeated "id") are each reported.
Anything the verifier did not expect is a problem (check-failed),
never a pass. Each problem and finding is reported with its entry's
number. Two verifiers agree if they give the same three answers,
find problems at the same entries, and report the same findings for
each entry.
10.2. Findings
A verifier reports these findings at the receipt concerned:
action-not-allowed: "action" is not in "actions".
prohibited: "action" is a shared action of a kind that
"never" names.
party-not-allowed: "with" names no service of the permission.
outside-valid-time: "when" is outside the permission's validity.
amount-missing: A limit with a "unit", or a condition with
"above", applies to the action, and the receipt
has no amount in that unit (once a receipt).
over-limit, over-each-limit, over-count-limit: The running total
exceeds "max"; the amount exceeds "each"; with
this receipt, the number exceeds "count".
over-period-limit: Within the period ending at this receipt, the
total exceeds "max" or the number "count".
countersignature-missing, approval-missing: A condition applies, and
the line holds no countersignature, or no
approval.
after-cancellation, pass-not-allowed: As Section 8 and Section 7 set
out.
A condition with "above" applies only if the amount is in its unit
and greater than "above"; an amount missing or in another unit is
amount-missing. Only compared receipts count towards totals.
Totals and counts without "per" are kept in log order over every
compared receipt for the action under the permission, in every chain,
the current one included. Once a total is exceeded, each later
receipt is reported too. A period is counted back from each receipt
X stating time t. With "per" P, it holds every receipt for the
action, in any chain and anywhere in the log, dated later than t
minus P and earlier than t; those dated t that come earlier in the
log; and X. A later line may state an earlier time, so these limits
are settled once every receipt has been read. There are no calendar
days or time zones.
11. Relationship to Other Work
Agent receipts: [I-D.nelson-agent-delegation-receipts] has the user
Izmaylov Expires 9 April 2027 [Page 19]
Internet-Draft Agent Permission Receipts October 2026
sign an authorization (WebAuthn being one way) with allowed and
denied actions, prohibitions and a time window, logged before the
agent acts; its delegations may only narrow, within a depth limit,
and can be revoked. [I-D.sahu-agent-action-receipts] and
[I-D.dembowski-agentledger-proof-of-behavior] specify signed,
hash-chained action receipts, with a recorded policy decision or a
gate run before execution. Here the permission carries limits on
amounts, counts and periods, and anyone can compare each recorded
action with it afterwards.
SCITT profiles: A SCITT Transparency Service [RFC9943] registers
Signed Statements and returns Receipts [RFC9942] proving inclusion
in its log; a SCITT Receipt proves registration, not an action.
[I-D.noa-scitt-ai-agent-receipt] records a principal class and an
ALLOW or DENY verdict, keeps pre-execution authorization apart,
and does not claim that a named approver authorized the action.
[I-D.emirdag-scitt-ai-agent-execution] has the operator sign each
record, with an independent custodian as Transparency Service; a
principal's constraints appear only as an optional text field and
references to credentials. [I-D.mih-scitt-agent-action-capsule]
records one action per capsule, with its disposition and the
constraints evaluated, and leaves permission to authorization
records it references by digest. None defines a permission signed
by the principal, with limits that a verifier compares receipts
against. That content model could be carried by a SCITT profile,
with heads or receipts registered as Signed Statements, also
guarding against truncation and split views (Section 16).
OAuth and GNAP: Token Exchange expresses delegation through the
"act" claim (Section 4.1 of [RFC8693]); Rich Authorization
Requests [RFC9396] and the Grant Negotiation and Authorization
Protocol (GNAP) [RFC9635] grant detailed rights. All yield tokens
issued by a server for access, not records signed by the
principal. Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
carry one call's context through a trust domain; a receipt can
hold a token's digest in "details".
Attenuating tokens: [I-D.niyikiza-oauth-attenuating-agent-tokens]
lets a holder derive offline tokens with equal or narrower
capabilities, within depth and lifetime limits, checked before
each call; macaroons [MACAROONS], Biscuit [BISCUIT] and UCAN
[UCAN] narrow capabilities likewise. Delegation here also only
narrows, but is checked over recorded actions, with totals and
periods across many of them.
WIMSE: Workload Identity in a Multi System Environment (WIMSE)
[I-D.ietf-wimse-arch] gives workloads identities;
[I-D.ietf-wimse-aims] applies WIMSE and OAuth to AI agents. A
WIMSE credential for an agent's keys would say which workload held
them.
Credentials and mandates: A permission resembles a credential
Izmaylov Expires 9 April 2027 [Page 20]
Internet-Draft Agent Permission Receipts October 2026
([VC-DATA-MODEL], [I-D.ietf-oauth-sd-jwt-vc]) and a mandate of the
Agent Payments Protocol [AP2], by which a user authorizes
purchases within limits; but it is checked against receipts, and
handles no payment.
Agent auditing: A request for a working-group-forming session on
Agent Use of Delegation and Interaction Traceability (AUDIT) names
[I-D.kuehlewind-audit-architecture] and
[I-D.birkholz-verifiable-agent-conversations] as its architecture
and solution drafts, and a data model for records as new work.
Permissions with limits could serve as input to it.
12. Design Rationale
Passkeys are on the devices people use, resist phishing and record
user verification; no device offers a post-quantum passkey. JWS JSON
carries several signatures, and JSON text suits a log of one entry to
a line. The content model does not depend on JWS; Section 11
describes how a SCITT profile could carry it. Two signatures side by
side can each be verified by any library, and a verifier lacking one
says so. Composite signatures [I-D.ietf-jose-pq-composite-sigs]
would make one of the two, but that draft pairs ML-DSA-87 only with
ES384 or Ed448, never with Ed25519. Verification needs no network,
because a record may be checked years later, when its writers have
gone. Post-quantum signatures are used from the start: if Ed25519 is
forged in future, a record carrying only Ed25519 could be made
afterwards and not told apart from a genuine one; SLH-DSA rests on
hash functions alone. The tree is that of Certificate Transparency,
the covering of fields in [FORMAT] that of [RFC9901], and the time-
stamp that of the Time-Stamp Protocol.
13. Parts Specified Elsewhere
[FORMAT] specifies these parts, out of scope here: one-page proofs of
single entries, with a permission's names and purpose covered by the
disclosures of [RFC9901]; vouching records, by which an organization
states that a key belongs to a name, and their withdrawal; a
service's signed refusals and terms; time-stamps from a public block
chain; further date rules; and the principal's own copy of a
cancellation, handed to a verifier. How records are carried, how
keys are distributed, and what to do about a finding are out of scope
too.
14. Open Issues
This section is to be removed before publishing as an RFC.
Izmaylov Expires 9 April 2027 [Page 21]
Internet-Draft Agent Permission Receipts October 2026
1. Labels: standards-tree media types [RFC6838], a registered
passkey method; [I-D.ietf-cose-sphincs-plus] registers SLH-DSA-
SHA2-128s and SLH-DSA-SHAKE-128s, not SLH-DSA-SHA2-256s.
2. Canonical form: [RFC8785] is Informational (Independent stream),
not in the downref registry; this document could define the
narrowed form, which is short.
3. Client data: refusing repeated members, or the limited
verification algorithm of [WebAuthn]; public suffixes; extension
bytes; backup flags.
4. [RFC8419] requires SHA-512 with Ed25519 when signed attributes
are present; Section 9.3 also accepts SHA-256 and SHA-384.
5. Timing: whether to bring in the date rules of Section 21 of
[FORMAT] and Section 22 of [FORMAT], and whether 300 seconds is
the right allowance.
6. A COSE form, with COSE_Sign (Section 4.1 of [RFC9052]); SCITT
registration; consistency proofs (Section 2.1.4 of [RFC9162]);
composite signatures; a registry for shared action names; whether
to answer "within its permission" when not everything was
verified.
15. Implementation Status
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
Provared 0.1.0, by the author, covers this document and [FORMAT]: a
library, a command-line verifier, a verification page that runs from
one file, samples with expected answers, and tests. Maturity: a
first version, marked as a draft. Licence: Apache License 2.0
([FORMAT]: Creative Commons Attribution 4.0); JavaScript for Node.js
24.7 or later, with no dependencies. Location:
https://github.com/provared/provared (tag v0.1.0) and the npm package
"provared". Contact: the author. Date: published 5 October 2026;
updated 6 October 2026. The rules of Section 4.6 were confirmed
against it on Node.js 24.19.0 with OpenSSL 3.5.7. No independent
implementation is known.
Izmaylov Expires 9 April 2027 [Page 22]
Internet-Draft Agent Permission Receipts October 2026
Provared is used by the author as a trade mark; it is not registered.
Anyone may use the identifiers in this document to implement this
document.
16. Security Considerations
A permission cannot be made or widened without the principal's
passkey, nor any other record made or changed without its signer's
keys; each signature covers a label naming the kind of record. A
receipt cannot be removed from the middle of its chain, moved within
its chain or changed unnoticed; its last receipts can be, unless a
head held by someone else covers them. Nothing before a signed tree
head can be changed, added or removed unnoticed by a verifier that
holds a copy of that head, or of its size and root, obtained other
than from the recorder. Trusting the recorder's keys protects
against everyone except the recorder, who can sign a shortened or
reordered history. A counted time-stamp shows that the entries
before a sound head existed by its time. Against anyone but the
recorder, a permission gains post-quantum protection once under a
head whose keys the verifier trusts: two of the head's three
signatures are post-quantum and cover its line.
What the format does not protect against:
No trusted keys: With no trusted keys named, "intact" means only
that the log is consistent with itself. Anyone can make such a
log.
Omission, one side's word: An agent that writes no receipt leaves no
trace in its own log. A one-sided receipt, an acknowledgement,
and the times in records, which periods rest on, are the signer's
word.
Truncation and split views: The last head, with everything after it,
can be removed unnoticed unless someone else holds that head. A
recorder can keep two logs that differ after some entry, with
heads for each; no consistency proof is defined. Handing heads to
others lets them be compared.
One log only: approval-reused and duplicate-id hold within one log;
the same approval or "id" in two logs is not detected.
Agent keys held by the recorder: Such a recorder can write and sign
another history. A time-stamp then shows only when;
countersignatures still stand against it.
Passkeys: A passkey shows that a device signed after verifying a
user, not who held it, nor that the principal read what was
signed; a compromised device or page can show one thing and have
another signed. The counter is not used, so a cloned passkey goes
unseen. An "http://localhost" origin is for tests only.
Time-stamp keys: A TSA is trusted by certificate digest, without
Izmaylov Expires 9 April 2027 [Page 23]
Internet-Draft Agent Permission Receipts October 2026
revocation, and its time is checked against the certificate's
validity, not the verifier's clock. A compromised TSA key can
stamp any time; a verifier that learns of it MUST stop trusting
it. Up to four TSAs lessen the dependence on one.
Renewal: TSA signatures are classical, and certificates age. A
later head covers earlier heads' lines, time-stamps included, so
stamping it by a newer TSA extends the evidence, as evidence
records [RFC4998] do.
Stripping: Signatures are fixed in number, order and label, and
their keys are given elsewhere (Section 4.5), so removing or
replacing one is caught.
Ed25519 alone: Without ML-DSA-87, what is compared rests on Ed25519
alone. A verifier whose library applies other rules than
Section 4.6 MUST add the missing checks.
Malleable signatures: An ECDSA signature can be altered into another
valid one. A record digest covers only content, so no digest
changes; the line does, and a later head shows it.
A verifier MUST treat every byte of a record as untrusted, and answer
a failed check with a code, not a crash. It SHOULD replace control,
invisible and direction-changing characters before showing text from
a record. Member names are plain strings: "__proto__" is like any
other.
17. Privacy Considerations
Following [RFC6973]: keys repeat in every record a party signs, so
records in different logs can be linked. Document digests are not
salted, so whoever can guess a document can confirm that a receipt
names it; a writer can add a random value to a document first. A TSA
learns the digests it stamps, when, and who asked. An entry cannot
be erased without breaking later heads, so records should hold no
more personal data than needed; names may be pseudonyms, and [FORMAT]
defines covered names and purpose. "origin" and "rpId" name the site
where the principal signed. A verifier makes no network request.
18. IANA Considerations
This document has no IANA actions. On adoption, a later version is
expected to request standards-tree media types [RFC6838] for each
kind of record. It would also request a JWS algorithm name for the
passkey signature, and one for the third signature of a signed tree
head (Section 14).
19. References
19.1. Normative References
Izmaylov Expires 9 April 2027 [Page 24]
Internet-Draft Agent Permission Receipts October 2026
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS 204,
DOI 10.6028/NIST.FIPS.204, August 2024,
<https://doi.org/10.6028/NIST.FIPS.204>.
[FIPS205] National Institute of Standards and Technology, "Stateless
Hash-Based Digital Signature Standard", FIPS 205,
DOI 10.6028/NIST.FIPS.205, August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/rfc/rfc2634>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/rfc/rfc3161>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007,
<https://www.rfc-editor.org/rfc/rfc5035>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
Izmaylov Expires 9 April 2027 [Page 25]
Internet-Draft Agent Permission Receipts October 2026
[RFC5816] Santesson, S. and N. Pope, "ESSCertIDv2 Update for RFC
3161", RFC 5816, DOI 10.17487/RFC5816, April 2010,
<https://www.rfc-editor.org/rfc/rfc5816>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/rfc/rfc6454>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature
Algorithm (EdDSA) Signatures in the Cryptographic Message
Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
2018, <https://www.rfc-editor.org/rfc/rfc8419>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
Izmaylov Expires 9 April 2027 [Page 26]
Internet-Draft Agent Permission Receipts October 2026
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object
Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/rfc/rfc9864>.
[RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing
and Encryption (JOSE) and CBOR Object Signing and
Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May
2026, <https://www.rfc-editor.org/rfc/rfc9964>.
[WebAuthn] World Wide Web Consortium, "Web Authentication: An API for
accessing Public Key Credentials - Level 3", W3C REC-
webauthn-3-20260825, 25 August 2026,
<https://www.w3.org/TR/2026/REC-webauthn-3-20260825/>.
[X690] International Telecommunication Union, "Information
technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, February 2021.
19.2. Informative References
[AP2] AP2 project, "Agent Payments Protocol (AP2)", 2026,
<https://github.com/google-agentic-commerce/AP2>.
[BISCUIT] Eclipse Biscuit project, "Biscuit specification", 2026,
<https://doc.biscuitsec.org/reference/specifications>.
[FORMAT] Izmaylov, P., "The Provared format - draft version 0", 5
October 2026,
<https://github.com/provared/provared/blob/v0.1.0/spec/
provared-format.md>.
[I-D.birkholz-verifiable-agent-conversations]
Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent
Conversation Records", Work in Progress, Internet-Draft,
draft-birkholz-verifiable-agent-conversations-01, 31
August 2026, <https://datatracker.ietf.org/doc/html/draft-
birkholz-verifiable-agent-conversations-01>.
Izmaylov Expires 9 April 2027 [Page 27]
Internet-Draft Agent Permission Receipts October 2026
[I-D.dembowski-agentledger-proof-of-behavior]
Dembowski, J., "Proof-of-Behavior Protocol for Autonomous
AI Agents", Work in Progress, Internet-Draft, draft-
dembowski-agentledger-proof-of-behavior-00, 20 April 2026,
<https://datatracker.ietf.org/doc/html/draft-dembowski-
agentledger-proof-of-behavior-00>.
[I-D.emirdag-scitt-ai-agent-execution]
Emirdag, P., "AI Agent Execution Profile of SCITT", Work
in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-
execution-00, 11 April 2026,
<https://datatracker.ietf.org/doc/html/draft-emirdag-
scitt-ai-agent-execution-00>.
[I-D.ietf-cose-sphincs-plus]
Prorock, M., Steele, O., and H. Tschofenig, "SLH-DSA for
JOSE and COSE", Work in Progress, Internet-Draft, draft-
ietf-cose-sphincs-plus-10, 28 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
sphincs-plus-10>.
[I-D.ietf-jose-pq-composite-sigs]
Prabel, L., Shuzhou, S., Gray, J., and T. Reddy.K, "PQ/T
Hybrid Composite Signatures for JOSE and COSE", Work in
Progress, Internet-Draft, draft-ietf-jose-pq-composite-
sigs-04, 11 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-pq-
composite-sigs-04>.
[I-D.ietf-oauth-sd-jwt-vc]
Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
Verifiable Digital Credentials (SD-JWT VC)", Work in
Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-19,
31 August 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-oauth-sd-jwt-vc-19>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-11, 30 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-11>.
Izmaylov Expires 9 April 2027 [Page 28]
Internet-Draft Agent Permission Receipts October 2026
[I-D.ietf-wimse-aims]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Identity Management
System", Work in Progress, Internet-Draft, draft-ietf-
wimse-aims-00, 15 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[I-D.kuehlewind-audit-architecture]
Kuehlewind, M. and H. Birkholz, "An Architecture for
Auditing Agent Delegation and Interactions", Work in
Progress, Internet-Draft, draft-kuehlewind-audit-
architecture-01, 7 September 2026,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
audit-architecture-01>.
[I-D.mih-scitt-agent-action-capsule]
Mih, S., "An Agent Action Capsule Profile for SCITT", Work
in Progress, Internet-Draft, draft-mih-scitt-agent-action-
capsule-05, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-mih-scitt-
agent-action-capsule-05>.
[I-D.nelson-agent-delegation-receipts]
Nelson, R., "Delegation Receipt Protocol for AI Agent
Authorization", Work in Progress, Internet-Draft, draft-
nelson-agent-delegation-receipts-10, 13 June 2026,
<https://datatracker.ietf.org/doc/html/draft-nelson-agent-
delegation-receipts-10>.
[I-D.niyikiza-oauth-attenuating-agent-tokens]
Aimable, N., "Attenuating Authorization Tokens for Agentic
Delegation Chains", Work in Progress, Internet-Draft,
draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June
2026, <https://datatracker.ietf.org/doc/html/draft-
niyikiza-oauth-attenuating-agent-tokens-01>.
[I-D.noa-scitt-ai-agent-receipt]
Toraman, T., "A SCITT Profile for AI-Agent Action
Receipts", Work in Progress, Internet-Draft, draft-noa-
Izmaylov Expires 9 April 2027 [Page 29]
Internet-Draft Agent Permission Receipts October 2026
scitt-ai-agent-receipt-01, 14 August 2026,
<https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
agent-receipt-01>.
[I-D.sahu-agent-action-receipts]
sahu, N., "Signed, Hash-Chained Action Receipts for AI
Agents", Work in Progress, Internet-Draft, draft-sahu-
agent-action-receipts-00, 16 August 2026,
<https://datatracker.ietf.org/doc/html/draft-sahu-agent-
action-receipts-00>.
[MACAROONS]
Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A.,
Vrable, M., and M. Lentczner, "Macaroons: Cookies with
Contextual Caveats for Decentralized Authorization in the
Cloud", Network and Distributed System Security Symposium
(NDSS) 2014, DOI 10.14722/ndss.2014.23212, February 2014,
<https://doi.org/10.14722/ndss.2014.23212>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
August 2007, <https://www.rfc-editor.org/rfc/rfc4998>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/rfc/rfc8725>.
Izmaylov Expires 9 April 2027 [Page 30]
Internet-Draft Agent Permission Receipts October 2026
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
[RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/rfc/rfc9635>.
[RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/rfc/rfc9901>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/rfc/rfc9942>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[UCAN] UCAN Working Group, "User Controlled Authorization Network
(UCAN) Specification, Version 1.0.0", 2026,
<https://github.com/ucan-wg/spec>.
[VC-DATA-MODEL]
World Wide Web Consortium, "Verifiable Credentials Data
Model v2.0", 15 May 2025,
<https://www.w3.org/TR/vc-data-model-2.0/>.
Appendix A. Codes
Any record (Section 4): not-json (not JSON; empty; byte order mark);
bad-envelope (envelope members); bad-base64url (not strict
base64url); too-large (over a size limit); unknown-type (unknown
label); payload-type-mismatch (other kind of record); bad-signatures-
layout (signatures in wrong number or order); payload-not-canonical
(not canonical); bad-field (member missing, unknown or malformed);
Izmaylov Expires 9 April 2027 [Page 31]
Internet-Draft Agent Permission Receipts October 2026
bad-key (key shape); signature-invalid (signature fails); check-
failed (anything unexpected).
Passkeys (Section 4.7): passkey-bad-data (malformed values); passkey-
wrong-type (wrong "type"); passkey-challenge-mismatch (wrong
challenge); passkey-origin-mismatch (other origin); passkey-rpid-
mismatch (other "rpId"); passkey-user-not-present (flag clear);
passkey-user-not-verified (flag clear); issuer-not-expected (key not
trusted).
Logs and receipts (Section 4.8, Section 9.1, Section 6): line-not-
canonical (line not canonical); unknown-entry (unknown kind of
entry); duplicate-id ("id" or delegation twice); duplicate-slip
(permission twice); slip-missing (permission not earlier); slip-
unusable (permission not sound); root-mismatch (unexpected root or
size); chain-broken (receipt missing, moved or changed); time-went-
backwards (dated before its predecessor); terms-not-found (terms not
in the log); countersignature-wrong-stub (for another receipt);
countersignature-not-possible (service has no keys);
countersignature-invalid (fails); approval-mismatch (for something
else); approval-not-found (not on the line); approval-reused (used
twice); approval-invalid (fails); approval-dated-after-stub (dated
after its receipt).
Delegations, cancellations and heads (Section 7, Section 8,
Section 9): pass-missing (delegation not earlier or not sound); pass-
mismatch (other permission); pass-too-deep (deeper than 10);
cancellation-invalid (fails); cancellation-not-found (unusable);
seal-mismatch (size or root wrong); seal-chain-broken (wrong
"previous"); sealer-not-expected (recorder not trusted); dated-after-
stamp (dated after a time-stamp); stamp-bad-data (malformed); stamp-
wrong-data (for something else); stamp-invalid (signature or field
fails).
Findings (Section 10.2, Section 7): action-not-allowed, prohibited,
party-not-allowed, outside-valid-time, amount-missing, over-limit,
over-each-limit, over-count-limit, over-period-limit,
countersignature-missing, approval-missing, after-cancellation, pass-
not-allowed and pass-wider. The codes terms-unusable, terms-
mismatch, outside-terms, cover-invalid, vouching-missing,
acknowledgement-mismatch, proof-invalid, headers-invalid and record-
not-sound belong only to parts specified in [FORMAT].
Izmaylov Expires 9 April 2027 [Page 32]
Internet-Draft Agent Permission Receipts October 2026
Appendix B. Shared List
Names that begin "provared." are reserved for this list; [FORMAT]
also gives each action's meaning. Shared action names are written
below without their "provared." prefix: "data.read" stands for
"provared.data.read". Kinds and rules of conduct are written as
shown, with no prefix; a "never" list may name any of them.
"reads": Looks at data without changing it. Actions: "data.read",
"data.search", "message.read", "calendar.read", "code.read",
"web.read".
"changes": Creates or changes data in a way that can be put back.
Actions: "data.create", "data.change", "message.draft",
"calendar.change", "access.remove", "code.change",
"system.configure".
"destroys": Removes data or a resource in a way that may not be put
back. Actions: "data.delete".
"sends": Sends a message or data to a person, to the public or to
another system. Actions: "data.export", "message.send",
"post.publish", "agent.instruct".
"commits": Binds the principal to something: an order, a booking, an
agreement, an account. Actions: "booking.make", "booking.cancel",
"order.place", "order.cancel", "terms.accept", "form.submit",
"account.create".
"grants": Gives someone or something access or permission. Actions:
"access.grant", "key.create".
"runs": Runs a program or a command. Actions: "code.run",
"code.release".
"enters": Signs in to a system or an account. Actions:
"account.sign-in".
"impersonate": Never claim to be a human being, or to be anyone
other than the agent of the principal who signed the permission.
"bypass": Never go around an access control, a block or a refusal.
"escalate": Never obtain or use access that it was not given.
"conceal": Never hide, alter or leave out its own records.
"deceive": Never state what it has reason to believe is false, and
never make up a record or a result.
"harass": Never threaten, pressure or attack a person.
"disclose": Never pass information that is not public to anyone the
permission does not name.
"continue-after-stop": Never carry on after being told to stop.
Author's Address
Pavel Izmaylov
Email: hello@prova.red
Izmaylov Expires 9 April 2027 [Page 33]