]> b7n0de

Germany kontakt@b7n0de.com

Security evaluation receipt Ed25519 canonical JSON This document defines a Signed Evaluation Receipt: one JSON object that records one evaluation result, whether a stated threshold held for a stated metric of a stated test suite, and signs it with Ed25519 over a domain-separated encoding of its canonical bytes. A receipt shows who signed the recorded bytes. It does not show that the recorded result is true. A receipt does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document.

Introduction Evaluation results for software and models are often reported as numbers in documents, dashboards or logs. A reader who receives such a number later has no means to tell whether the bytes they see are the bytes the reporting party produced. This document defines a small, fixed format that gives that means and nothing more. A Signed Evaluation Receipt (receipt) holds exactly one assertion: for a named test suite and metric, whether the score met a threshold under a stated comparator. The model and the dataset are named only through salted commitments. The assertion is serialized with the JSON Canonicalization Scheme , and the resulting bytes are signed with Ed25519 over a pre-authentication encoding that binds a fixed type. Two parties that share no infrastructure can use this format: an Issuer that ran an evaluation, such as the provider of a model or a test laboratory, and a Receiver that decides on the result, such as an operator that admits a model into service or an auditor. The Issuer hands over one receipt; the Receiver checks it under a key it fixed beforehand, without access to the Issuer's systems, and learns which result the Issuer reports for which committed model and dataset, under which threshold and comparator. The receipt object exists next to the DSSE-compatible signature because it carries, together with B, the fixed type and the payload schema identifier and is verified by one procedure (), so that every Receiver reaches the same verdict on the same receipt bytes and verification key, provided verification completes. A DSSE signature check alone is not that verdict. A receipt establishes integrity and origin: the holder of the signing key signed exactly these bytes. It does not establish truth. lists what a receipt does not prove, and that list is part of the definition. A receipt carries no inclusion proof and names no log. A receipt does not prove registration with a Transparency Service. In SCITT , transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document. This document defines an application payload and a receipt that carries it with a signature. Its interoperability target is that independent Receivers reach the same format, consistency and signature verdict on the same receipt bytes and verification key, provided verification completes. It does not define an evaluation method or decide whether a reported result is sufficient for an application. A separate profile can specify how this format is carried or cited in SCITT. This document defines no envelope mapping and no transport.

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.

Issuer:

The party that creates and signs a receipt.

Receiver:

The party that verifies a receipt. The Receiver fixes the verification key before verification, by means outside this document.

Payload:

The JSON object that holds the assertion ().

B:

The RFC 8785 byte string of the Payload. B is what is signed (through PAE).

PAE:

The pre-authentication encoding of .

Commitment:

A string that binds an identifier without revealing it ().

Receipt Format

The Receipt Object A receipt is one JSON text that is an I-JSON message : UTF-8 without a byte order mark, no string (member names included) that contains a surrogate or noncharacter code point ( Section 2.1), no duplicate member names at any level, and nothing before or after the JSON text other than insignificant whitespace ( Section 2). Member names are compared after unescaping ( Section 8.3), and so are string values: the receipt object is not canonicalized, so \/ and / are the same character. Its top-level value is an object with exactly these members:

schema:

The type of , as a string.

payload_b64:

The base64 encoding of B ( Section 4, with padding). It MUST be the canonical encoding: re-encoding the decoded bytes yields the same string ( Section 3.5).

signature:

An object with exactly the members alg and sig, or exactly alg, sig and key. alg is the string ed25519; sig is the canonical base64 encoding, as for payload_b64, of the 64-byte Ed25519 signature; key, when present, is the canonical base64 encoding, as for payload_b64, of a 32-byte Ed25519 public key and is only a hint ().

The receipt object has no number member. The number rules of I-JSON are not checked when the receipt is parsed: a number where a string belongs fails the step that checks that member. The receipt names no trust instance: it carries no certificate, no address from which a key could be fetched, and no list of trusted parties.

The Payload The Payload is a JSON object with exactly the members of Table 1. criteria_digest is the only optional member: a Payload either has it or not, and has no member that Table 1 does not list. The Type column states every constraint a member has except two: the pattern sha256: followed by 64 lowercase hexadecimal digits that the commitments of and criteria_digest () share, and the agreement of passed with the comparison. A member that violates its row fails step 6 of , a commitment or a criteria_digest without that pattern fails step 7, and a passed that disagrees fails step 8.

Member	Type	Meaning
schema	string, exactly the payload schema identifier below	version of the payload format
suite	non-empty string	name of the test suite
suite_version	non-empty string	version of the test suite
metric	non-empty string	name of the metric
comparator	string, one of >=, >, <=, <	how the score is compared with the threshold
threshold	decimal string	the threshold the score is compared with
score	decimal string	the score the Issuer reports
passed	true or false	whether score comparator threshold holds
n	integer from 1 to 2^53 - 1	number of samples the Issuer reports; not checked against anything
model_id_commit	string	commitment () to the model identifier
dataset_id_commit	string	commitment () to the dataset identifier
commit_alg	string, exactly sha256-salted-v1	the commitment construction
timestamp	string, a timestamp as defined below	when the Issuer states the evaluation ran
criteria_digest	string; OPTIONAL	digest () of the criteria set the Issuer states this result belongs to

The payload schema identifier is In this document a digit is one of the ASCII digits 0 to 9 (0x30 to 0x39); no other Unicode digit counts. A lowercase hexadecimal digit is a digit or one of the ASCII letters a to f (0x61 to 0x66). A non-empty string has at least one character. A decimal string is an optional minus sign, then either the digit 0 or a digit from 1 to 9 followed by any digits, then optionally a full stop followed by one or more digits; it has no exponent and no plus sign. A timestamp is a UTC date-time of in exactly this form, with an uppercase T and Z: The date exists in the proleptic Gregorian calendar: the day of the month is at most the maximum that Section 5.7 gives for its month and year, under the leap-year rule of Appendix C, so the year 0000 exists and is a leap year; the hour is 00 to 23, the minute 00 to 59 and the second 00 to 59. A timestamp has no fractional seconds and no offset other than Z, and this format does not represent a leap second. passed MUST equal the result of comparing score with threshold under comparator as exact decimal numbers. The Payload thus carries one assertion, and a Receiver can check that its parts agree with each other; it cannot check that they agree with any evaluation. The version of the format lives in the schema identifier. The test vectors of this version are the vector set of : this document gives ten of them in full and fixes the file that holds all of them by its URL, size and SHA-256. A later version uses a different identifier under and comes with its own test vectors. The identifier above keeps naming the format of this document.

Salted Commitments sha256-salted-v1 is defined as follows. The Issuer takes a salt of exactly 16 bytes from a cryptographically secure random source and keeps it. The commitment is the string sha256: followed by the 64 lowercase hexadecimal digits of SHA-256 over the salt bytes immediately followed by the UTF-8 bytes of the identifier. There is no separator and no length prefix. SHA-256 is the hash function specified in . A Receiver checks only the pattern sha256: followed by 64 lowercase hexadecimal digits; it can check the binding only when the Issuer discloses salt and identifier. Reusing the same salt and identifier produces the same commitment across receipts. Fresh salts avoid this equality link but do not make receipts unlinkable, because verification keys and other shared values may still link them ().

The Bytes B B is the serialization of the Payload under . For a valid Payload that means: members sorted by name, no insignificant whitespace, the integer n as its decimal digits, and strings with the escaping of Section 3.2.2.2. A Receiver MUST reject payload bytes that are not their own RFC 8785 serialization, so that exactly one B exists for each Payload. The check (step 5 of ) runs before the member checks of step 6, so it applies RFC 8785 in full, including the number serialization of its Section 3.2.2.3: a B that carries 1.0, 1e0 or 9007199254740993 is not its own serialization.

The Criteria Digest criteria_digest is OPTIONAL. When present, it is the string sha256: followed by the 64 lowercase hexadecimal digits of SHA-256 over the bytes of a criteria set, exactly as the publisher of that criteria set fixed them. A criteria set is any document that states how an evaluation is to be judged, for example its metric, comparator and threshold; this document defines no format and no canonical form for it. A Receiver checks only the pattern (step 7 of ). It can check the binding only when it holds the bytes of the criteria set, by computing SHA-256 over them. What the member does not show is part of . As an informative example, the profile of carries in its hash-only mode the 32 octets of SHA-256 over the canonical bytes of a criteria set written in as the payload of a Signed Statement. When the bytes of the criteria set are those canonical bytes, the 64 hexadecimal digits of criteria_digest are those 32 octets written in lowercase hexadecimal.

Signature

Pre-Authentication Encoding SP is the byte 0x20. LEN(x) is the number of bytes of x as ASCII decimal digits without leading zeros. type is the UTF-8 string of , body is B. "DSSEv1" is the six ASCII bytes of that literal. This is the pre-authentication encoding of DSSE ; it is defined here so that this document can be implemented without it.

The Type The type is the fixed string It enters every signature. It MUST NOT change for this format, because a change would invalidate every signature made under it; a new format uses a new type. The string is a media type name in the vendor tree ( Section 3.2) with the +json structured syntax suffix ( Section 3.1). It is the same string that a DSSE envelope would carry as payloadType.

Signing The signature is Ed25519 as defined in Section 5.1, in its pure form, without context and without prehashing (not Ed25519ctx, not Ed25519ph):

Verification Profile Ed25519 implementations differ on inputs that RFC 8032 leaves to choice . A Receiver MUST use this profile. In it, x*P is the scalar multiplication of the point P by the integer x, B' is the base point, and L is the order of B' ( Section 5.1).

1. The public key A and the signature's first half R MUST be canonical encodings: decoding as in Section 5.1.3 succeeds. That decoding rejects a y-coordinate that is not below p and the encoding of x = 0 with the sign bit set.
2. A and R MUST have order L: L*A and L*R are the neutral element, and A and R are not the neutral element.
3. The scalar S, the second half of the signature read as a little-endian integer, MUST be below L ( Section 5.1.7).
4. With k = SHA-512(R || A || PAE(type, B)) read as a little-endian integer reduced modulo L, the equation S*B' = R + k*A MUST hold (the cofactorless equation). In the hash input, R and A are the 32-byte encodings exactly as received: the first 32 bytes of the 64-byte signature and the verification key.

A signature that fails any rule is invalid. The rules are checked in the order given, and within rules 1 and 2 the key before R. Because A and R have order L, the cofactorless equation of rule 4 and the cofactored equation 8*S*B' = 8*R + 8*k*A of Section 5.1.7 accept exactly the same signatures. This specification defines individual verification only. A randomized batch result MUST NOT substitute for checking all four rules for each signature. A Receiver MUST NOT leave out any of the four rules.

Verification Procedure Input: the receipt bytes and the verification key that the Receiver fixed. The verification-key input is exactly 32 octets containing the compressed Edwards-point encoding of A defined by Section 5.1.2. A verification-key input that is not exactly 32 octets is an input error: the steps below are not run, and the result is neither PASS nor the FAIL of one of them. Any textual or file representation used to supply those octets is outside this specification. The steps are evaluated in order; the result is PASS only when every step succeeds, and the first step that fails gives FAIL. String values are compared after unescaping. A Receiver that stops because it reached a resource limit () reports a resource-limit error; that is neither PASS nor the FAIL of one of the steps below.

1. Parse the receipt as one I-JSON text (). A byte order mark, bytes that are not UTF-8, a surrogate or noncharacter code point, duplicate member names at any level, anything before or after the JSON text other than insignificant whitespace ( Section 2), a top-level value that is not an object with exactly the members schema, payload_b64 and signature, or a signature that is not an object with exactly alg and sig or exactly alg, sig and key: FAIL.
2. schema is not the type of : FAIL.
3. payload_b64 is not a string of the base64 alphabet with padding, or not the canonical encoding of the bytes it decodes to: FAIL. Otherwise those bytes are B.
4. B is not one I-JSON text whose value is an object, under the rules of step 1 (byte order mark, UTF-8, surrogates and noncharacters, duplicate names as in Section 2.3, which Section 3.1 requires of its input, trailing data): FAIL. Numbers are not judged here: each is read as an IEEE 754 double, rounded to nearest with ties to even and overflowing to infinity, and a number that so has no finite double, such as 1e400, fails step 5.
5. B is not the RFC 8785 serialization of the value parsed in step 4 (): FAIL. This step alone would also reject every B that step 4 rejects for a byte order mark, duplicate names or trailing data; step 4 is kept so that every Receiver reports the same failing step.
6. The Payload's member set differs from (every member of Table 1, with criteria_digest optional), or a member violates its row of Table 1 (its type, the schema and commit_alg values, a non-empty string, the comparator set, the decimal grammar, the range of n, the timestamp form): FAIL.
7. A commitment, or criteria_digest when present, is not sha256: followed by 64 lowercase hexadecimal digits: FAIL.
8. passed differs from the comparison of score with threshold: FAIL.
9. signature.alg is not the string ed25519, or signature.sig is not a string that is the canonical base64 encoding of exactly 64 bytes: FAIL.
10. signature.key is present and is not a string that is the canonical base64 encoding of the verification key: FAIL. A key in the receipt is only a hint.
11. The signature is invalid under the profile of for the verification key and PAE(type, B) with the fixed type: FAIL. A signature made over PAE with another type fails here.

Table 2 lists every vector of the vector set () with the step at which it fails first; each of the eleven steps is the first failing step of at least one vector. A vector shows the first failing step under in-order evaluation; it does not show that a later step would also reject it. Of the profile, the vectors cover rule 1 for the key (N18) and for R (N17), rule 2 for the key (N12, and N61 for a key of mixed order) and for R (N16, and N59 for an R of mixed order), rule 3 (N6) and rule 4 (N7). No vector isolates rule 1 from rule 2. Rule 1 rejects 40 encodings that a decoder reducing y modulo p would try (y from p to p + 18 with either sign bit, and x = 0 with the sign bit set); read by such a decoder, 14 of them give no point, 6 give points of small order and 20 give points of mixed order. None of these 26 points has order L, so a Receiver without rule 1 would still reject each of them under rule 2; N17 and N18 use y = p + 1, which such a decoder reads as the neutral element. P6 has no key hint, so step 10 has nothing to compare. N61 uses the mixed-order test key, the issuer's public point plus a point of order 8, with a signature that satisfies the cofactorless equation; only rule 2 rejects it. Its expected result is FAIL at step 11, rule 2 for the verification key. N59 uses the issuer test key and an R of mixed order, the point r*B' plus the same point of order 8, with S = r + k*a mod L; the cofactored equation holds and the cofactorless one does not, and rule 2 rejects R before rule 4 is reached. P9 and N51 to N55 pin rules that no other vector reaches: the year 0000 (P9), ASCII digits (N51), a number without a finite double (N52), the key before R in rules 1 and 2 (N53, N54), and no number rule at step 1 (N55). N56 writes n as 1800.0, which a Receiver that skipped the number serialization of RFC 8785 would accept. P10 carries the optional criteria_digest; N57 gives it uppercase hexadecimal digits and N58 the value null. The receipts without the member are the other positive vectors. P12 is the receipt of P1 followed by a line feed, insignificant whitespace that step 1 admits. N60 is B of P1 followed by a line feed, signed anew: step 4 admits the line feed under the rules of step 1, and step 5 rejects B, because its RFC 8785 serialization has no insignificant whitespace. P13 is a line feed followed by the receipt of P1, insignificant whitespace before the JSON text that step 1 admits.

ID	Step	Expected	What it shows
P1	all	PASS	pass
P2	all	PASS	recorded-failure
P4	all	PASS	escaped-receipt-string
P6	all	PASS	no-key-hint
P7	all	PASS	comparator-le
P8	all	PASS	exact-decimal
P9	all	PASS	year-0000
P10	all	PASS	criteria-digest
P12	all	PASS	receipt-trailing-whitespace
P13	all	PASS	receipt-leading-whitespace
N1	4	FAIL	no-duplicate-names
N2	2	FAIL	receipt-schema
N3	4	FAIL	no-trailing-data
N4	7	FAIL	commitment-pattern
N5	5	FAIL	jcs-form
N6	11 (profile 3)	FAIL	s-less-than-L
N7	11 (profile 4)	FAIL	pae-type
N9	10	FAIL	key-hint
N10	6	FAIL	payload-schema
N11	8	FAIL	result-consistency
N12	11 (profile 2, key)	FAIL	small-order-key
N13	3	FAIL	canonical-base64
N14	1	FAIL	receipt-duplicate-names
N15	9	FAIL	signature-alg
N16	11 (profile 2, R)	FAIL	small-order-R
N17	11 (profile 1, R)	FAIL	noncanonical-R
N18	11 (profile 1, key)	FAIL	noncanonical-key
N19	1	FAIL	receipt-trailing-data
N20	1	FAIL	receipt-member-set
N21	1	FAIL	signature-member-set
N22	1	FAIL	receipt-duplicate-after-unescaping
N23	1	FAIL	receipt-bom
N24	3	FAIL	payload-not-base64
N25	9	FAIL	signature-length
N26	9	FAIL	signature-canonical-base64
N30	6	FAIL	commit-alg
N31	6	FAIL	payload-member-missing
N32	6	FAIL	payload-member-extra
N33	6	FAIL	payload-member-type
N34	6	FAIL	decimal-grammar
N35	6	FAIL	n-at-least-1
N36	6	FAIL	timestamp-calendar
N37	6	FAIL	timestamp-leap-second
N38	6	FAIL	comparator-set
N39	6	FAIL	non-empty-string
N40	4	FAIL	payload-utf8
N41	4	FAIL	payload-lone-surrogate
N42	4	FAIL	payload-noncharacter
N43	4	FAIL	payload-bom
N44	1	FAIL	receipt-utf8
N45	1	FAIL	receipt-lone-surrogate
N46	1	FAIL	receipt-noncharacter
N48	8	FAIL	comparator-gt
N49	8	FAIL	comparator-lt
N50	6	FAIL	n-below-2-53
N51	6	FAIL	ascii-digits
N52	5	FAIL	number-without-double
N53	11 (profile 1, key)	FAIL	key-before-R-rule-1
N54	11 (profile 2, key)	FAIL	key-before-R-rule-2
N55	2	FAIL	receipt-number-at-step-2
N56	5	FAIL	number-serialization
N57	7	FAIL	criteria-digest-pattern
N58	6	FAIL	criteria-digest-type
N59	11 (profile 2, R)	FAIL	mixed-order-R
N60	5	FAIL	payload-trailing-whitespace
N61	11 (profile 2, key)	FAIL	mixed-order-key

What a Receipt Does Not Prove Verification establishes that the receipt passes the format, consistency and signature checks in under the Receiver's selected key. PASS does not mean that passed is true or that the result meets the Receiver's requirements for its intended use. Establishing who controls that key and whether that party is authorized to make the claim is outside this procedure. Verification does not establish that the Issuer's claims are true. In particular:

• The score can be false. The evaluation can be wrong, badly designed or not run at all; the receipt records what the Issuer states.
• The run need not have been the only run. An Issuer can evaluate many times and record only the run it prefers.
• The Issuer can lie. A valid signature binds the statement to the key, not to the truth.
• A receipt does not show that it was published, logged or shown to anyone else. A receipt does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document.
• The receipt bytes are not a stable name for the receipt. Only B is signed; the receipt object around it is not canonicalized, and its key hint can be present or absent. A party that cites a receipt cites SHA-256 over B.
• A commitment is computationally binding under the collision resistance of SHA-256. A Receiver can check a claimed opening only after receiving the salt and identifier. Hiding depends on keeping an unpredictable salt secret.
• The timestamp is the Issuer's statement, not a time attested by another party.
• The receipt says nothing about individual samples: n is the Issuer's statement, and no sample result is committed or can be disclosed against the receipt. A sample-level audit is outside this document and is left to a separate document.
• A receipt does not show that the threshold was fixed before the run.
• criteria_digest binds only the Issuer's statement that this result belongs to the criteria set with that digest. It shows neither that the criteria set existed before the run nor that the metric, comparator and threshold in it equal those in the receipt.
• Even with salt and identifier disclosed, the receipt does not show that the named model or dataset was the one actually evaluated.
• A receipt does not show where B came from. B carries no reference to another receipt or record that it was made from, for example when an Issuer translates the result of another format into a receipt; this format has no member for it.

Related Work The following individual drafts also define signed receipts; each sentence states a difference in construction as read on 2026-10-25.

• records access control decisions, serializes them with RFC 8785, makes Ed25519 mandatory to implement, permits ES256 and recommends ML-DSA-65, and offers an optional commitment mode that places salted field values in a Merkle tree hashed as in Certificate Transparency ( Section 2.1.1).
• defines two records signed with Ed25519: an attestation receipt for an AI inference decision, with twelve required members, the signature among them, three optional members and no other member; and an action record for the decision an enforcement point takes before a proposed agent action runs, with thirteen required members and no other member, all strings or arrays of strings. Both use a canonicalization that, by its own statement, differs from RFC 8785 only in forbidding numbers that RFC 8785 writes in exponential notation.
• profiles action receipts with RFC 8785, requires ML-DSA-65 for new issuance, accepts Ed25519 only under a separately selected historical format, and requires a hash chain between receipts.

None of the three, as read on that date, has a member for an evaluation threshold. Two further individual drafts concern evaluation evidence without defining a signed result:

• states format-neutral requirements for converting and consuming evaluation evidence so that claim-relevant loss stays visible; it defines no wire format, while this document defines one signed format for one result.
• carries pre-run evaluation criteria in the format of as a SCITT Signed Statement, in full or as the 32-octet SHA-256 of their canonical bytes; it records criteria before a run, while a receipt records one result after it and names such criteria at most by criteria_digest ().

The following individual drafts were read on 2026-10-19. The summaries describe their scope and construction in the cited revisions and identify differences from this document. The first three concern receipts for decisions or actions:

• records decisions about autonomous actions as allow, block or escalate, optionally with decimal-string scores and thresholds. It authenticates an RFC 8785 encoding of a fixed set of members with ES256 or RS256 signatures or an HS256 MAC. Its required backLink follows the applicable profile; the initial receipt in the engine decision profile uses the SHA-256 digest of the empty string.
• records agent actions with a boolean success member. A detached Ed25519 signature covers compact UTF-8 JSON with signed top-level members in a fixed, non-lexicographic order; objects within params are recursively sorted. In its receipt log, the first entry omits prev_hash. Each later entry carries the SHA-256 digest of the preceding serialized line, including its public key and signature but excluding its terminating newline.
• binds a JSON behavior record to an event of the Judgment Event Protocol through a critical extension. The record identifies an agent and an action and contains zero or more evidence descriptors, each carrying a digest. It is addressed by SHA-256 over its RFC 8785 serialization. The profile defines no independent signature format and leaves signature processing to that protocol.

Among these three revisions, Vaara explicitly defines optional thresholdAllow and thresholdBlock members for decision scores. This document requires score, comparator, threshold and passed for an evaluation result and checks their consistency using exact decimal comparison. That check does not establish that the reported score is correct. Three further individual drafts concern evaluation or measurement records:

• defines an Evidence Qualification Receipt that binds an exact proposition digest to a versioned evidence-requirements profile, evidence digests and one of three evaluation results, PASS, FAIL or INDETERMINATE, as one input to an authorization system; it defines no signature format and requires a receipt exchanged between domains to be integrity protected by a mechanism acceptable to the verifier, while this document defines the signature of a receipt.
• describes a JSON evidence record whose members include a preregistered decision procedure and an admissibility evaluation of binding gate results, serializes the core of each event with RFC 8785 before hashing when an event digest is used, and requires every event but the first to reference the digest of the preceding one; it names SHA-256 and Ed25519 only for profiles that use them, while this document fixes both for every receipt.
• defines capsules that compare declarations with observations, carry no decision and distinguish UNCHECKABLE from pass or failure. Self-measurement is permitted. A capsule's identifier is SHA-256 over its RFC 8785 serialization with capsule_id omitted; batches use an RFC 9162 Merkle Tree Hash over those identifiers. The profile describes COSE_Sign1 registration of a capsule, batch record or index. The draft reports comparisons with evaluation reruns but states that its implementation does not yet encode COSE and has made no SCITT registration. This document instead fixes a signed format for one Issuer-reported evaluation result and defines no SCITT registration profile.

Security Considerations This section follows the guidance of . The attacker considered can read, create, modify, replay and reorder receipts, and controls every input except the Receiver's choice of verification key. Forgery. Without the secret key an attacker cannot produce a receipt that verifies under the Receiver's key, given the security of Ed25519. The Receiver fixes the key out of band; a key carried in the receipt is only compared with it and never used on its own. A Receiver that took the key from the receipt would accept any receipt from anyone. Domain separation. The signature covers PAE(type, B), not B alone. A signature made by the same key for another purpose over the same bytes, or over the same bytes under another type, does not verify as a receipt, and a receipt signature does not verify as a signature over B in another protocol that also signs with PAE under a different type. The type is fixed () so that this separation does not depend on a value the attacker controls. Ambiguous bytes. Duplicate member names (also when they differ only in escapes), trailing data, a byte order mark, surrogate or noncharacter code points, non-canonical base64 and payload bytes that are not their own RFC 8785 form, for example a number written as 1800.0, would let two parsers see different content behind one signature. The procedure of rejects each of them, so that one B has one meaning. The receipt object around B is not canonical and not signed (). Ed25519 edge cases. Implementations of Ed25519 differ in whether they accept a non-reduced S, non-canonical point encodings, points of small or mixed order, and whether they use the cofactored or the cofactorless equation . A receipt format whose verdict depends on the library would let one Receiver accept what another rejects. The profile of fixes each choice. Vector N12 shows why rule 2 refuses points of small order: with the neutral element as verification key, R = S*B' satisfies the cofactorless equation for every message. N61 and N59 show why rule 2 requires order L: under a key or with an R of mixed order the cofactored and the cofactorless equation can disagree (N59), and a verifier that does not check the order accepts N61 under either equation. In the measurements of , the plain Ed25519 verification of a general library accepted the signatures of vectors N12, N16, N18 and N61 and rejected those of N6, N17 and N59; the profile of rejects all seven. A Receiver that relies on a library verdict alone therefore does not implement this format. Resource limits. This document defines no universal input-size limit. Oversized inputs, long strings and deeply nested invalid JSON can exhaust memory or processing time before verification completes. Implementations SHOULD apply documented resource limits before and during processing of untrusted input. Reaching a limit MUST NOT produce PASS and is reported as a resource-limit error, not as a completed format or signature verdict under . Commitments. A commitment with a short or guessable salt can be tested against candidate identifiers. The salt is therefore 16 bytes from a cryptographically secure source and stays with the Issuer. Criteria digest. criteria_digest binds the bytes of a criteria set, not a time. Whoever wants to show that the criteria set existed before the run needs an anchor outside the receipt, for example the digest of the criteria set registered with a Transparency Service before the run began. The member also carries weight only when the Receiver compares it with bytes of the criteria set that it obtained independently of the state it checks: criteria bytes taken from the same place as the result can have been changed together with it, and their digest then matches. Replay. A receipt is a static statement, not an authentication token. Showing a valid receipt proves nothing about the party that shows it. Key compromise. A compromised key can sign receipts with any content. This document defines no revocation; a Receiver that needs it uses means outside this document.

Privacy Considerations Model and dataset identifiers appear only as salted commitments. Reusing the same salt and identifier produces the same commitment across receipts. Fresh salts avoid this equality link but do not make receipts unlinkable, because verification keys and other shared values may still link them: identical suite, metric and timestamp values link receipts, and so does the same criteria_digest. Disclosing salt and identifier to one Receiver discloses them to everyone that Receiver passes them on to.

IANA Considerations This document has no IANA actions. Registering the media type of in the vendor tree goes directly to IANA ( Section 3.2) and is not an action of this document.

Media Type Registration Template The following template for application/vnd.signed-evidence.eval-receipt+json is the one for its registration in the vendor tree; it is given for information. This media type identifies the canonical payload bytes B defined in . It does not identify the receipt object of , which may be transferred as application/json. The receipt object's schema member remains the fixed format discriminator defined in .

Type name:

application

Subtype name:

vnd.signed-evidence.eval-receipt+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

Binary. The representation is B, a UTF-8 JSON text in the canonical form defined in , without a byte order mark.

Security considerations:

B is data and contains no active content: it carries no directive and nothing a recipient executes. B is not compressed. A receipt that carries B gives integrity and origin of B only under a key the Receiver fixed before verification, and only with the procedure of ; a key named in the receipt is never used on its own. B gives no confidentiality: its members are readable by anyone who holds it, and model and dataset identifiers appear in it only as salted commitments (, ). Parsing untrusted input needs documented resource limits; reaching a limit is not a verdict. See of this document and Section 12.

Interoperability considerations:

When the verification-key input is 32 octets and processing completes without a resource-limit error, the procedure of and the signature profile of determine the verdict and first failing step on the vectors of . The type string enters every signature ().

Published specification:

This document.

Applications that use this media type:

Issuers and Receivers of evaluation payloads, including DSSE envelopes that carry B and digest references that identify B.

Fragment identifier considerations:

As specified for the +json structured syntax suffix in Section 3.1. This document defines no fragment identifier of its own.

Additional information:

Deprecated alias names for this type: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.

Person & email address to contact for further information:

Konrad Gruszka <kontakt@b7n0de.com>

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Konrad Gruszka

Change controller:

Konrad Gruszka <kontakt@b7n0de.com>

Implementation Status This section records the status of known implementations at the time of writing, following , and is to be removed before publication. The vectors of were produced by a generator script whose two runs are byte-identical, and verified by two verifiers: one written by the author of the generator, and one written from the text of this document alone, without access to the generator. Both verifiers reach the expected verdict and the expected first failing step on every vector. An implementation of this format in the proofbundle project, behind an explicit option and with these vectors as conformance tests, is under way on a work branch and not released. The show-eval command of that implementation with --expect-issuer refuses a verification key whose y-coordinate is not below p or that is a point of small order, as in vectors N12, N18, N53 and N54, before starting the receipt verification procedure, with exit status 2. The receipt verification function reads the receipt first. It refuses a key of mixed order, as in N61, at step 11. The early refusals are checks the command makes before the procedure runs; under , a 32-octet key of these kinds is not an input error, and the procedure gives FAIL unless it stops at a resource limit. On 2026-10-12, the implementation named above, at commit a339424e07fd58fa261d8ca3f41af5de4dcbf751 of its work branch, was run on the 66 vectors of with the bytes given there, and for each vector its verdict and first failing step were compared with the expected ones: it reached the expected verdict and the expected first failing step on all 66 vectors. A further verifier, written from the published text of this document alone, agreed with the verifier written by the author of the generator on the verdict and the first failing step of each of the 66 vectors, on 23000 targeted inputs across all eleven steps and on 4002 serializations of numbers by , with no deviation on these inputs (measured on 2026-10-11). In the measurements behind , the plain Ed25519 verification of pyca/cryptography 41.0.7 accepted the signatures of vectors N12 (small-order key), N16 (small-order R), N18 (non-canonical key) and N61 (mixed-order key), and rejected those of N6 (S not below L), N17 (non-canonical R) and N59 (mixed-order R). In a local measurement on 2026-10-10, a receipt made from the result of a test run was checked by the implementation named above and by the verifier written from the text of this document alone. Both passed it, and both refused the same receipt with one byte of B changed, at step 11.

References Normative References Informative References Secure Systems Lab

Test Vectors Vector identifiers are labels: a P vector expects PASS, an N vector expects FAIL, and gaps in the numbering carry no meaning. The vector set has 66 vectors, those of Table 2 (). gives ten of them in full; the file of holds all of them. A verifier needs only the bytes of a vector and the verification key named for it.

Constants and Test Material Receipt schema, also the type of : Payload schema: commit_alg: PURE TEST KEYS AND SALTS. They MUST NOT be used for any real receipt. Issuer test key, Ed25519 seed (hex, 32 bytes) and public key (base64, 32 bytes): Second test key, used only as a wrong hint, Ed25519 seed (hex, 32 bytes) and public key (base64, 32 bytes): Mixed-order test key, used only by vector N61: the public point of the issuer test key plus a point of order 8. It has no RFC 8032 seed; the discrete logarithm of its prime-order part is the secret scalar of the issuer test key. The point of order 8, which vector N59 also adds to its R (hex, 32 bytes), and the public key (base64, 32 bytes): The model commitment: salt (hex, 16 bytes), identifier, commitment: The dataset commitment: salt (hex, 16 bytes), identifier, commitment: The example criteria set of vectors P10 and N57: its bytes (hex), and criteria_digest over them:

Vector Set The ten vectors below are P1, P2, P4, P6, N5, N7, N12, N13, N14 and N59. Where the payload bytes of a vector are those of P1, their hex is not repeated: the list item gives their size and SHA-256, and the bytes are B of P1.

P1 (pass; expected PASS, step all) A well-formed receipt: the signature over PAE(TYPE, B) verifies under the verification key, the commitments have the fixed pattern, and passed = true agrees with score >= threshold.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 02036d1f57509858330383755ec16c532bdc58b0f2d949464488d57abc9f95e7

B (hex): Receipt (hex):

P2 (recorded-failure; expected PASS, step all) A recorded failure (score below the threshold, passed = false) verifies exactly like a recorded success.

• verification key: the issuer test key
• payload bytes B: 459 bytes, SHA-256 07182e9bff69baa8ab9a5646d69b5118ccf3780b903b9a9d5b4bd0d9c9d70b87
• receipt bytes: 871 bytes, SHA-256 2405d1783d1803ddea207c027622fba40b3e82161686505ee96988e306e17278

B (hex): Receipt (hex):

P4 (escaped-receipt-string; expected PASS, step all) The receipt writes the schema with the JSON escape \/ for each solidus; compared after unescaping it is the receipt media type. The receipt object is not canonicalized.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 872 bytes, SHA-256 c2a7943f0ea3de6e9da88c11925b1e112d32f697a403f07fcfbc3776bca10e72

Receipt (hex):

P6 (no-key-hint; expected PASS, step all) The signature object has exactly alg and sig, without a key hint; step 10 has nothing to compare.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 818 bytes, SHA-256 2c8144d50b4cc42a712d84e4d0417e52b0d8cbc484ad8e6d8d4b36a429b94ec1

Receipt (hex):

N5 (jcs-form; expected FAIL, step 5) The payload bytes are a valid JSON text of the same object but not its own RFC 8785 form (insignificant whitespace, member order). Note: the signature over these bytes is valid; re-serializing the parsed payload gives other bytes.

• verification key: the issuer test key
• payload bytes B: 498 bytes, SHA-256 fa97d7e9e6e2560d3025761ebfbae46635427dd2856b8c9b965679456cef2318
• receipt bytes: 923 bytes, SHA-256 f4573f3c66570e347f4fa305b61cd189211824d9c02c603942766ff082c391c4

B (hex): Receipt (hex):

N7 (pae-type; expected FAIL, step 11 (profile 4)) The signature was made over PAE with a different type string; under the fixed type it does not verify.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 18b1b6dc631cf0f00d8b0d2c237b28a67b12c2d7088ae0313a2fb27760f96bdd

Receipt (hex):

N12 (small-order-key; expected FAIL, step 11 (profile 2, key)) The verification key is the neutral element (a point of small order). The signature R || S with R = S*B' satisfies the cofactorless equation for any message under that key; the profile rejects small-order keys. Note: the receiver fixed this key; the vector shows why the profile refuses it.

• verification key: the neutral element, canonical encoding (01 followed by 31 zero bytes)
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 19d798c4199635a8bc637e09466633a270f1502ce5f802e57908a063443b3e60

Receipt (hex):

N13 (canonical-base64; expected FAIL, step 3) payload_b64 decodes to the same B but is not its canonical base64 encoding (non-zero padding bits, RFC 4648 Section 3.5).

• verification key: the issuer test key
• payload bytes carried (not B: the procedure stops at step 3 before it obtains B): 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 31a34194edd90bade6568a3cb00dbb983dabab9efccfd7a8b38650bd3e8d5201

Receipt (hex):

N14 (receipt-duplicate-names; expected FAIL, step 1) The signature object repeats the member name "sig"; a parser that keeps the last value and one that keeps the first disagree.

• verification key: the issuer test key
• payload bytes carried (not B: the procedure stops at step 1 before it obtains B): 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 968 bytes, SHA-256 8966f27c5f2566d986b0ab7821060ea0c901504fe984d450dfc7f8ca7d1c27e1

Receipt (hex):

N59 (mixed-order-R; expected FAIL, step 11 (profile 2, R)) R is the point r*B' plus the point of order 8, a canonical encoding of a point of mixed order, and S = r + k*a mod L with the issuer's secret scalar a. The cofactored equation 8*S*B' = 8*R + 8*k*A holds and the cofactorless equation does not; rule 2 rejects R before rule 4 is reached.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 2c913638dc4b977574a2582a60aeb934a87b3492a0da5dc451e1de84d9e4c3cc

Receipt (hex):

The Complete Vector Set All 66 vectors, the ten of included, are in one file:

• URL: https://signed-evidence.org/eval-receipt/v1/test-vectors.json
• size: 232309 bytes
• SHA-256: 710cb8abab7ca51cf61b85c5610018f9a153add4c3db4f71b2d597e57b1671d1

A verifier uses the file only after its size and SHA-256 are those above. The file is one JSON text in UTF-8: an object with the members document, the name of this draft; title and note, two strings for a human reader; count, the number of vectors; and vectors, an array with one object per vector, in the order of Table 2. Each object has the members id, label, expected and step, as in the vector's heading; description, an array of the paragraphs that describe the vector; items, an array of its list items, which name the verification key and the size and SHA-256 of each byte string; and bytes, an array with one object per byte string, with the members label (B, Receipt, or Payload bytes carried), length, sha256 and hex. For the ten vectors of the file holds the same words and bytes as this appendix, the payload bytes included.

Changes (to be removed before publication)

Since draft-gruszka-signed-evaluation-receipts-03

• The vector set is unchanged. gives ten of its 66 vectors in full, without repeating B of P1, and names the file that holds all of them by its URL, size and SHA-256. , the text before Table 2 and the opening of say so.
• cites draft-chueayen-attestation-receipts-05 and describes the two records that revision defines; its first three drafts are now as read on 2026-10-25.
• Section 5 states that a verification-key input that is not exactly 32 octets is an input error and not a verdict, and Sections 10.1 and 11 are worded to match; no vector changes.

Since draft-gruszka-signed-evaluation-receipts-02

• adds six individual drafts, read on 2026-10-19, and the informative references to them.
• calls the mode of hash-only, as that draft does.

Since draft-gruszka-signed-evaluation-receipts-01

• ends with the scope of this document and its interoperability target.
• opens with what PASS does not mean and says that establishing who controls the key is outside the procedure.
• The security considerations of also refer to Section 12.
• adds the conformance run of the implementation named there, at commit a339424e, on the vectors of , and the result of a further verifier written from the text. It also limits the description of early key rejection to the command-line interface.
• The Open Items section is removed. The references were checked against the published documents on 2026-10-12, and now gives the conformance result it asked for.
• This appendix is added.

Since draft-gruszka-signed-evaluation-receipts-00

• names the two parties the format serves, an Issuer and a Receiver that share no infrastructure, and says why the receipt object stands next to the DSSE-compatible signature.
• states that the vectors of this version are maintained in and that a later version of the format uses a different identifier with its own vectors.
• adds that a receipt does not show where B came from.
• adds that criteria_digest binds bytes, not a time, and carries weight only against criteria bytes the Receiver obtained independently.
• writes out the security considerations of the registration template and names contact, author and change controller.
• adds a local measurement on 2026-10-10 of a receipt made from the result of a test run.