]>

hello@prova.red

Security AI agent authorization evidence delegation receipt transparency log post-quantum 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.

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; states how far that reaches. The records reuse JSON Web Signature (JWS) over JavaScript Object Notation (JSON) in one canonical form , the Merkle tree of , and time-stamps from a Time-Stamping Authority (TSA) . Agents sign with Ed25519 and the Module-Lattice-Based Digital Signature Algorithm ML-DSA-87 side by side; a signed tree head adds the Stateless Hash-Based Digital Signature Algorithm SLH-DSA . Other drafts () 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 ; 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 ; lists the parts specified only there.

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 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.

Principal:

The person who signs a permission with a passkey ("issuer").

Passkey:

A credential 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 ().

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 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 ().

Base64url is that of , 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 (). 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. lists the codes.

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 ; 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, and values abbreviated: ", ""], "name": "Agent"}, "id": "", "issuer": {"key": "", "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": ["", ""], "name": "Example Stationery"}]} ]]> The log then holds these entries ("receipt n" has "seq" n; "cs" is a countersignature): The content of the receipt at entry 5, shown across lines, is: ","previous":"", "seq":4,"slip":"", "type":"provared.stub.v0","when":"2026-10-05T09:40:00Z", "with":"supplier"} ]]> 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.

Common Rules

Envelope and Labels Every record is a JWS in the General JWS JSON Serialization (). 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 (), also "header", which holds exactly "authenticatorData" and "clientDataJSON" (bad-envelope). Each signature covers the JWS Signing Input () 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

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 (), used for explicit typing (); being signed, it stops a signature made for one kind of record passing as another. "Ed25519" is registered by and "ML-DSA-87" by . "SLH-DSA-SHA2-256s", named in , and "prova.red/webauthn/v0", a collision-resistant name (), are not registered.

Content The content of a record is the decoded "payload". It MUST be a JSON object in UTF-8, in the canonical form of : 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).

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 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 the unit is 1 to 16 ASCII letters, digits, ".", "-" or "_", beginning with a letter or digit.

Keys Keys are JSON Web Keys (JWK) of exactly these shapes, with no other member (bad-key): These follow , (the Algorithm Key Pair, "AKP", key type) and ; "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: with SHA-256, over the members required by , for "OKP" and for "AKP". It is told which recorders it trusts by key-set digests: the digest of the key set written in the canonical form.

Hybrid Signatures A receipt, a countersignature, a delegation and an acknowledgement carry two signatures over the same payload: Ed25519 (, as requires), then ML-DSA-87 (pure ML-DSA.Verify of with an empty context, as requires). A signed tree head adds a third, SLH-DSA-SHA2-256s (pure slh_verify of 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 (). An entry none of whose signatures was verified is not evidence: what it says MUST NOT be shown as fact.

Ed25519 Verification 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 ();
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.

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 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);
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 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) (), is stored as an ECDSA-Sig-Value in strict Distinguished Encoding Rules (DER) . 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 .

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.

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, ) 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.

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.

"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 ().

"requires":

0 to 64 conditions ().

"never":

0 to 16 names, none repeated ().

"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 ().

"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 () of its own origin (). 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 , and an action name that begins so MUST be on it (bad-field). Any other member, such as those by which covers fields, is a problem for a verifier of this document alone (bad-field).

Limits, Conditions and Prohibitions A limit names an "action" from "actions" (bad-field) and holds exactly one of "max", "each" and "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 ]]> "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 (); "approval" asks for the principal's approval. "never" names kinds of action and rules of conduct from . 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.

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 .

"when":

The time of the action, as the agent states it.

The permission and any delegation named are records relied on (). 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. 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.

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 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 (). 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 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.

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 (). Its entry may hold "stamps" over its digest (), 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. 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 (). 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 (). 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. sets out how a verifier uses it with the principal's own copy.

Logs, Signed Tree Heads and Time-Stamps

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 , 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 ("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). The leaves of the tree are the lines' bytes, without line feeds, in log order; the root is the Merkle Tree Hash of 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).

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.

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 ().

Time-Stamps "stamps" holds 1 to 4 time-stamps, none repeated. A string there is the base64url of an 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 . 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 . Time-stamps are read only if none of the record's own signatures failed. A verifier MUST confirm that:

1. the token is one element with nothing after it, laid out as and 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 (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 (, ) or ESSCertID (), 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 ; 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. 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.

Verification

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 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.

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 and 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.

Relationship to Other Work

Agent receipts:

has the user 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. and 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 registers Signed Statements and returns Receipts proving inclusion in its log; a SCITT Receipt proves registration, not an action. 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. 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. 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 ().

OAuth and GNAP:

Token Exchange expresses delegation through the "act" claim (); Rich Authorization Requests and the Grant Negotiation and Authorization Protocol (GNAP) grant detailed rights. All yield tokens issued by a server for access, not records signed by the principal. Transaction Tokens carry one call's context through a trust domain; a receipt can hold a token's digest in "details".

Attenuating tokens:

lets a holder derive offline tokens with equal or narrower capabilities, within depth and lifetime limits, checked before each call; macaroons , Biscuit and 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) gives workloads identities; 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 (, ) and a mandate of the Agent Payments Protocol , 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 and as its architecture and solution drafts, and a data model for records as new work. Permissions with limits could serve as input to it.

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; 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 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 that of , and the time-stamp that of the Time-Stamp Protocol.

Parts Specified Elsewhere 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 ; 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.

Open Issues

1. Labels: standards-tree media types , a registered passkey method; registers SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s, not SLH-DSA-SHA2-256s.
2. Canonical form: 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 ; public suffixes; extension bytes; backup flags.
4. requires SHA-512 with Ed25519 when signed attributes are present; also accepts SHA-256 and SHA-384.
5. Timing: whether to bring in the date rules of and , and whether 300 seconds is the right allowance.
6. A COSE form, with COSE_Sign (); SCITT registration; consistency proofs (); composite signatures; a registry for shared action names; whether to answer "within its permission" when not everything was verified.

Implementation Status 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 . 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 : 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 (: 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 were confirmed against it on Node.js 24.19.0 with OpenSSL 3.5.7. No independent implementation is known. 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.

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 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 do.

Stripping:

Signatures are fixed in number, order and label, and their keys are given elsewhere (), 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 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.

Privacy Considerations Following : 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 defines covered names and purpose. "origin" and "rpId" name the site where the principal signed. A verifier makes no network request.

IANA Considerations This document has no IANA actions. On adoption, a later version is expected to request standards-tree media types 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 ().

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK] This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology World Wide Web Consortium International Telecommunication Union Informative References In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. mesur.io Tradeverifyd University of the Bundeswehr Munich Digital signatures are used within JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) to protect the integrity and authenticity of messages, such as JSON Web Signatures and signed COSE structures. This document specifies JOSE and COSE serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. The conventions for the associated algorithm identifiers, signatures, public keys, and private keys are also specified. Huawei Huawei Entrust Limited Nokia This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. Authproof This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. kriya native This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. VERIDIC Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism. World Wide Web Consortium AP2 project Eclipse Biscuit project UCAN Working Group

Codes Any record (): 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); bad-key (key shape); signature-invalid (signature fails); check-failed (anything unexpected). Passkeys (): 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 (, , ): 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 (, , ): 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 (, ): 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 .

Shared List Names that begin "provared." are reserved for this list; 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.