]> 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 those of ; they are maintained in this document. 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. 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 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-10.

• 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).
• records AI inference decisions in a closed set of twelve required members, the signature among them, and three optional members, signed with Ed25519, under 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 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. 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 vectors below are complete: a verifier needs only the bytes given here and the verification key named for each vector.

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

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

B (hex): 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

B (hex): Receipt (hex):

P7 (comparator-le; expected PASS, step all) comparator <= with score 0.762 below threshold 0.800 and passed = true; read as >= the comparison would not hold.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 9ed224ee6c53d1a6d66a7d5336f4079cead25b306e00f2b10fd1bc71ddc42742
• receipt bytes: 871 bytes, SHA-256 a42bc3303128f7e18a5c05fabcb57904e054d9d4f1f5ba19186dad5c2e00130a

B (hex): Receipt (hex):

P8 (exact-decimal; expected PASS, step all) comparator > with score 0.30000000000000001 and threshold 0.3: as exact decimals the score is greater; as binary floating-point numbers the two are equal.

• verification key: the issuer test key
• payload bytes B: 469 bytes, SHA-256 cb8d8913846e3ebdf7dae561682f122a09738c430a28137b083beb7722eaab48
• receipt bytes: 887 bytes, SHA-256 9f24aa20ea7740cc4735d2fda04d50f19352b2c4769c5995e9bb2747e04110fb

B (hex): Receipt (hex):

P9 (year-0000; expected PASS, step all) The timestamp is 0000-02-29T00:00:00Z: under the leap-year rule of RFC 3339 Appendix C the year 0000 exists and is a leap year.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 05e1786bef7020811b1643058645b8d77821b036d3e44c656120cc35f8c96ba3
• receipt bytes: 871 bytes, SHA-256 c2358560b53847832e31dffbad8b1c52a93a7a10960cea5aee1e646ec137defa

B (hex): Receipt (hex):

P10 (criteria-digest; expected PASS, step all) The Payload carries the optional member criteria_digest: sha256: followed by the 64 lowercase hexadecimal digits of SHA-256 over the bytes of the example criteria set. A Receiver checks only its pattern.

• verification key: the issuer test key
• payload bytes B: 550 bytes, SHA-256 2241d1bcc2da953c9d7d7725398ef852363f3b4fa80c372754b1de539a26d846
• receipt bytes: 995 bytes, SHA-256 75d4029e2470131e8e88d8ec129efd7b9d15092b668bf0ecb7b32eea3361b7ed

B (hex): Receipt (hex):

P12 (receipt-trailing-whitespace; expected PASS, step all) The receipt bytes of P1 followed by one line feed (0a), insignificant whitespace after the end of the JSON text (RFC 8259 Section 2), which step 1 admits.

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

B (hex): Receipt (hex):

P13 (receipt-leading-whitespace; expected PASS, step all) One line feed (0a) followed by the receipt bytes of P1, insignificant whitespace before the JSON text (RFC 8259 Section 2), which step 1 admits.

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

B (hex): Receipt (hex):

N1 (no-duplicate-names; expected FAIL, step 4) The payload repeats the member name "passed" (RFC 7493 Section 2.3, RFC 8785 Section 3.1). Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 117 bytes, SHA-256 a27339f6948cb3acb0c0c529ad33452708c7c7a5c90c8cc1c9f818cc85060f08
• receipt bytes: 415 bytes, SHA-256 37e6ef34cffc4f9ded8c3bfab5060680233fe0f27742d5aad4a802191e0fdbbb

B (hex): Receipt (hex):

N2 (receipt-schema; expected FAIL, step 2) The receipt schema is not the receipt media type.

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

Payload bytes carried (hex): Receipt (hex):

N3 (no-trailing-data; expected FAIL, step 4) The payload bytes carry data after the end of the JSON text (RFC 8259 Section 2). Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 469 bytes, SHA-256 a43f0ec906e97e50202458a0dc6c7ec44bcc00b3779e9e882c9ef3f95eb786f6
• receipt bytes: 887 bytes, SHA-256 e11f4c7d69052c6a9356429d54176f6bce585aca5981ba5880939e4dc34e7419

B (hex): Receipt (hex):

N4 (commitment-pattern; expected FAIL, step 7) model_id_commit is the cleartext identifier, not "sha256:" followed by 64 lowercase hexadecimal digits.

• verification key: the issuer test key
• payload bytes B: 407 bytes, SHA-256 1f62f990a568b94e4956c093a6db5fea45fa3f8ab1702ba773e5684a3f2ae522
• receipt bytes: 803 bytes, SHA-256 dbd2ddefa3a5dab6cc06bbde2f6704eaf738ee116f3476bf6f763c398d03f293

B (hex): 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):

N6 (s-less-than-L; expected FAIL, step 11 (profile 3)) The signature scalar S is not reduced (S >= L, RFC 8032 Section 5.1.7); S was replaced by S + L, which a verifier without the range check accepts.

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

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

B (hex): Receipt (hex):

N9 (key-hint; expected FAIL, step 10) The key hint in the receipt is not the verification key the receiver fixed.

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

B (hex): Receipt (hex):

N10 (payload-schema; expected FAIL, step 6) The payload schema is not the payload schema URI.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 f5a680f3c35ef0dd8777820d61f6e477edbef9bbdf2a65463ba8a8f3b88043e2
• receipt bytes: 871 bytes, SHA-256 842b9f1716b014d91079020701247ed21a371dfdf365c361631f19dbbb19862d

B (hex): Receipt (hex):

N11 (result-consistency; expected FAIL, step 8) passed = true, but the score 0.762 does not satisfy >= 0.800.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 b25d0733d5881a332a1f531670f6ab900cf1a1184af7b584dbb769aaa765944f
• receipt bytes: 871 bytes, SHA-256 e3f46618657620e9e5d28470df04a83da3f4275a9fcba3774455af7f65ef57f1

B (hex): 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

B (hex): 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

Payload bytes carried (hex): 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

Payload bytes carried (hex): Receipt (hex):

N15 (signature-alg; expected FAIL, step 9) signature.alg is not "ed25519"; the signature itself is a valid Ed25519 signature.

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

B (hex): Receipt (hex):

N16 (small-order-R; expected FAIL, step 11 (profile 2, R)) R is the neutral element (01 followed by 31 zero bytes) and S = k*a mod L with the issuer's secret scalar a. The cofactorless equation holds, R is canonical and S is below L; only the small-order rule for R rejects it.

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

B (hex): Receipt (hex):

N17 (noncanonical-R; expected FAIL, step 11 (profile 1, R)) R is the non-canonical encoding y = p + 1 of the neutral element and S = k*a mod L over these R bytes. A decoder that reduces y modulo p accepts the signature; RFC 8032 Section 5.1.3 decoding rejects R (the small-order rule would reject it too).

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

B (hex): Receipt (hex):

N18 (noncanonical-key; expected FAIL, step 11 (profile 1, key)) The verification key is the non-canonical encoding y = p + 1 of the neutral element. With R = r*B' and S = r the cofactorless equation holds for any message under a decoder that reduces y modulo p; RFC 8032 Section 5.1.3 decoding rejects the key. Note: the receiver fixed this key; the vector shows why the profile refuses it.

• verification key: the neutral element, non-canonical encoding y = p + 1 (EE, 30 bytes FF, 7F)
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 dd8e1071f833f6c5c47d499cd7224cf65f34ff12977d6551d2fcdcfbebf8e42f

B (hex): Receipt (hex):

N19 (receipt-trailing-data; expected FAIL, step 1) Data follows the end of the receipt's JSON text (RFC 8259 Section 2).

• 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: 873 bytes, SHA-256 95d6f847e43fed6d31c38b5fe3d16edf91c8f16d2c56ed141a8ce5bfcaedb60b

Payload bytes carried (hex): Receipt (hex):

N20 (receipt-member-set; expected FAIL, step 1) The receipt object has a member other than schema, payload_b64 and signature.

• 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: 885 bytes, SHA-256 ba9c9f6dcab7753cd73f462c2a18bff8a7ea40cea7fe75f8dd16583593f0d413

Payload bytes carried (hex): Receipt (hex):

N21 (signature-member-set; expected FAIL, step 1) The signature object has a member other than alg, sig and the optional key.

• 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: 881 bytes, SHA-256 e3350ef79e20fa84c543adfb5853a453fd9729456f9a6ef4d77bb1dfe821a3da

Payload bytes carried (hex): Receipt (hex):

N22 (receipt-duplicate-after-unescaping; expected FAIL, step 1) The signature object has the member names "s\u0069g" and "sig", which are the same name after unescaping.

• 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: 973 bytes, SHA-256 fbd6938aa6cfb748f3e9e78a8267e5e67b0f84b72f23dda64bf791ae908f9850

Payload bytes carried (hex): Receipt (hex):

N23 (receipt-bom; expected FAIL, step 1) The receipt bytes begin with a UTF-8 byte order mark, which is not part of a JSON text.

• 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: 874 bytes, SHA-256 ee0f033e3e6e519bf5185f2cf74eedeacfe05abfe39ab81ed67c6c53b58c1d6a

Payload bytes carried (hex): Receipt (hex):

N24 (payload-not-base64; expected FAIL, step 3) payload_b64 contains a character outside the base64 alphabet.

• verification key: the issuer test key
• payload bytes B: none, payload_b64 does not decode
• receipt bytes: 871 bytes, SHA-256 fd53aaeb3d9821341a48db1f73fd7f9d0d97d9fdbe552a08f8c2e4a11214677a

Receipt (hex):

N25 (signature-length; expected FAIL, step 9) signature.sig decodes to 63 bytes, not 64.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 867 bytes, SHA-256 259e88eba23d8e72940a69211a642f03985e3125bbdaec8344bb2416285401bd

B (hex): Receipt (hex):

N26 (signature-canonical-base64; expected FAIL, step 9) signature.sig decodes to the valid signature but is not its canonical base64 encoding (non-zero padding bits).

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

B (hex): Receipt (hex):

N30 (commit-alg; expected FAIL, step 6) commit_alg is not sha256-salted-v1.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 08a3e32e0637c384a5a3546ca30c6dcf7d63cd4c2aed79ee33e1f6539dd47f13
• receipt bytes: 871 bytes, SHA-256 bb505266c5ef9bcaf1d5f259aac1bf7e044ae317c629caf4d8ceadf7cd5a730e

B (hex): Receipt (hex):

N31 (payload-member-missing; expected FAIL, step 6) The payload lacks the member n.

• verification key: the issuer test key
• payload bytes B: 449 bytes, SHA-256 b39e1ed00f019e16a4806b340e0ea4772b1b012a4725a66194519415cd8aea43
• receipt bytes: 859 bytes, SHA-256 8987d84e184fa1df5af4fdda796aa36c8dd254327e0987270a3870e863e76c42

B (hex): Receipt (hex):

N32 (payload-member-extra; expected FAIL, step 6) The payload has a member not in Table 1.

• verification key: the issuer test key
• payload bytes B: 470 bytes, SHA-256 160ead10fac9f38e9b36136ae69c3d530e8179acb4d1347333436561f02f6488
• receipt bytes: 887 bytes, SHA-256 a141fae9d60c2a00890f4bf79a66dd33e7994f53b834b5b9b671421779aedd52

B (hex): Receipt (hex):

N33 (payload-member-type; expected FAIL, step 6) n is a string, not an integer.

• verification key: the issuer test key
• payload bytes B: 460 bytes, SHA-256 cd159a2d03631e22669eab61f4da0370571d9b43d4f4343cfcf6141dea4fe1ca
• receipt bytes: 875 bytes, SHA-256 de6c58c37bc31b89ca4eec4c4f289a74daa20819b2fe172bd2f8fafb3bbb8486

B (hex): Receipt (hex):

N34 (decimal-grammar; expected FAIL, step 6) score is .834, which is not a decimal string (no leading digit).

• verification key: the issuer test key
• payload bytes B: 457 bytes, SHA-256 b8ff1f5b884a29dbec6335ff3683643b830a82e4be6822863134374503586024
• receipt bytes: 871 bytes, SHA-256 931807cdfcf32e7e930c89eb2a57f1abd1a08148b17383fd73e5264074e65cae

B (hex): Receipt (hex):

N35 (n-at-least-1; expected FAIL, step 6) n is 0.

• verification key: the issuer test key
• payload bytes B: 455 bytes, SHA-256 4ff8e0e87bb64f4447e6f46e8473f96cc3c60ded53c7524ad29a918e5398fa87
• receipt bytes: 867 bytes, SHA-256 f6f8149a5735884041bb4384ad1a7a31e9de2ffa88772b781109b8b0335399fc

B (hex): Receipt (hex):

N36 (timestamp-calendar; expected FAIL, step 6) timestamp names 30 February.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 04eac528e06a72681465808a06b3c23dc54dfc8e453dc682abfda8f6abc4105a
• receipt bytes: 871 bytes, SHA-256 f3f3a0a5f588491d10acbccc1ca8d1f94d5a69b0d0f314399feceb463fbb4b15

B (hex): Receipt (hex):

N37 (timestamp-leap-second; expected FAIL, step 6) timestamp has second 60, which this format does not admit.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 88f6d07eadb5242e05dce0b246a1415a041b29f0d540e79cfa896b36109d1c6e
• receipt bytes: 871 bytes, SHA-256 f7c1e19280ea53079b35e4a098194442b5e6603b8e59b8bcb1c5a856e31952e7

B (hex): Receipt (hex):

N38 (comparator-set; expected FAIL, step 6) comparator is => , not one of >=, >, <=, <.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 5f4c2a5be9958a57fd737ad4dce987c64cadce01300f173b077408e987ce96c7
• receipt bytes: 871 bytes, SHA-256 4a97220459e3d69d8e7e1ac159d7ab1a1628257545f110eb00260cb072aeee84

B (hex): Receipt (hex):

N39 (non-empty-string; expected FAIL, step 6) suite is the empty string.

• verification key: the issuer test key
• payload bytes B: 441 bytes, SHA-256 2025cdbb96bf3f8bc44238262f7b4430e97b4a1c3b82f821cb23120fbb68aced
• receipt bytes: 847 bytes, SHA-256 560ecebc2e4b40ee30a99fe8a411a03125ee142033705d81472bac8c3f9ccdf5

B (hex): Receipt (hex):

N40 (payload-utf8; expected FAIL, step 4) B contains the byte 0xFF, which is not UTF-8. Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 453 bytes, SHA-256 e4070c3aa058423ce8a5cea36b845bbb9a9ce776850efba925ae59f9f37d8c3d
• receipt bytes: 863 bytes, SHA-256 5dbcb20f1d321f8bcdfc6f4fa94d696bdc4795f561b10922a175b584d81b583f

B (hex): Receipt (hex):

N41 (payload-lone-surrogate; expected FAIL, step 4) B contains the escape \ud800, a lone surrogate, which I-JSON forbids (RFC 7493 Section 2.1). Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 8e45016c1374521334320ea15b5f7cd35a2f46b4e0361103fe8bd25b9a05e603
• receipt bytes: 871 bytes, SHA-256 ed4e4b86a1615e8e5b4e4f89e5bcdc5f7a46953825a2b18776e3760cfa089456

B (hex): Receipt (hex):

N42 (payload-noncharacter; expected FAIL, step 4) B contains U+FFFF, a noncharacter, which I-JSON forbids (RFC 7493 Section 2.1). Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 455 bytes, SHA-256 ebb05d1b6da24bbcf7a6c19198fd0a5ad08322b342793705e83faa9a8e5123e6
• receipt bytes: 867 bytes, SHA-256 3afb20dd37565406fbd82b5671b48725b05361a94631498c3f1b57fd47d65585

B (hex): Receipt (hex):

N43 (payload-bom; expected FAIL, step 4) B begins with a UTF-8 byte order mark. Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 461 bytes, SHA-256 3c6e404df7ae90d9e6ade9327a7e60852b3f8c09af36bd38cc78d58377c8f5c2
• receipt bytes: 875 bytes, SHA-256 30e4f5e6d7e36059f1f93e2142b601b4c51ec0e183b5ee19e5289779645e7e36

B (hex): Receipt (hex):

N44 (receipt-utf8; expected FAIL, step 1) The receipt contains the byte 0xFF, which is not UTF-8.

• 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: 872 bytes, SHA-256 cdf4844bfa2b06b975fef8cb76bfac9da0d20fe0981a5559fa0c05ef28e7a5ec

Payload bytes carried (hex): Receipt (hex):

N45 (receipt-lone-surrogate; expected FAIL, step 1) A string of the receipt contains the escape \ud800, a lone surrogate, which I-JSON forbids.

• 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: 877 bytes, SHA-256 b18339f4e11f57576a6386bc0a6660ff8d9f92acad2d58b441deb34190b3d90f

Payload bytes carried (hex): Receipt (hex):

N46 (receipt-noncharacter; expected FAIL, step 1) A string of the receipt contains U+FFFF, a noncharacter, which I-JSON forbids.

• 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: 874 bytes, SHA-256 5613dd7435a723ff593f1730f786cefe185e1dec31ea297a1c96c06911eddaab

Payload bytes carried (hex): Receipt (hex):

N48 (comparator-gt; expected FAIL, step 8) comparator > with score equal to threshold (0.800) and passed = true; read as >= the comparison would hold.

• verification key: the issuer test key
• payload bytes B: 457 bytes, SHA-256 1b905efaa6a5f9e62e1830196642fb84252ab649f002598b8c6ff899d313ac21
• receipt bytes: 871 bytes, SHA-256 0d58d49c4039231de5fcb49ffd0595a3c17ff903fa67dec71bbe3964f6c318b1

B (hex): Receipt (hex):

N49 (comparator-lt; expected FAIL, step 8) comparator < with score 0.834 below threshold 0.900 and passed = false; the comparison holds, so passed must be true.

• verification key: the issuer test key
• payload bytes B: 458 bytes, SHA-256 1fe4e0d27fadbe6960b1ddea0566f287994da625dea26bb255c66467c203da80
• receipt bytes: 871 bytes, SHA-256 28d17a28c5c1eaad5956069955ef50ae53fbac351fd4d916a176c9fbdfe800eb

B (hex): Receipt (hex):

N50 (n-below-2-53; expected FAIL, step 6) n = 9007199254740992 (2^53). B is its own RFC 8785 form, since 2^53 is a double, but n is not below 2^53.

• verification key: the issuer test key
• payload bytes B: 470 bytes, SHA-256 868cb0eaa38f69fcad1698b358a57cdbbe85711addaeeb8822f35fd449e53b2c
• receipt bytes: 887 bytes, SHA-256 a10a3baab62d60007f77aae358fecd132e8319e3600baebfa1730a6248af905d

B (hex): Receipt (hex):

N51 (ascii-digits; expected FAIL, step 6) The score is 0. followed by the Arabic-Indic digits U+0668 U+0663 U+0664; a digit is an ASCII digit, so the score is not a decimal string.

• verification key: the issuer test key
• payload bytes B: 461 bytes, SHA-256 5697ad5e12e2d5786be9f1cf42eb3384398943221a39cc688b0525ab61e2e715
• receipt bytes: 875 bytes, SHA-256 53227810012a48fa79dd1fe54fe18e382003150f2f4f4348d9bfdf30beee5579

B (hex): Receipt (hex):

N52 (number-without-double; expected FAIL, step 5) B writes n as 1e400, a number with no finite double; it has no RFC 8785 serialization, so B is not its own. Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 459 bytes, SHA-256 999bd423a90e8671943ddc99e0b6f94b6a5941327923a7e97347094310324fd2
• receipt bytes: 871 bytes, SHA-256 e6d6782e9d78e133f2c40a065a144dc0d25db254742894e5cd2ba35e050e2af8

B (hex): Receipt (hex):

N53 (key-before-R-rule-1; expected FAIL, step 11 (profile 1, key)) The verification key and R are both the non-canonical encoding y = p + 1 and S = 0; rule 1 fails for both and is reported for the key, which is checked first. Note: the receiver fixed this key; the vector shows the order of the profile's checks.

• verification key: the neutral element, non-canonical encoding y = p + 1 (EE, 30 bytes FF, 7F)
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 4b4a4e5fbf62f88aa3557f763a5f7c1ddb45157903d34998a8090c4bc0aa8dec

B (hex): Receipt (hex):

N54 (key-before-R-rule-2; expected FAIL, step 11 (profile 2, key)) The verification key and R are both the neutral element and S = 0; rule 2 fails for both and is reported for the key, which is checked first. Note: the receiver fixed this key; the vector shows the order of the profile's checks.

• 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 162720ee2254eae2ea5d2a1fa65e1d24e238cdcef9bafc7547cef44a1ddbcf33

B (hex): Receipt (hex):

N55 (receipt-number-at-step-2; expected FAIL, step 2) The receipt writes schema as the number 1e400. Step 1 does not judge numbers, so the receipt fails at step 2, where schema is not the type.

• verification key: the issuer test key
• payload bytes carried (not B: the procedure stops at step 2 before it obtains B): 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 825 bytes, SHA-256 70e8bdb4fe5f12d428cf26e5c87b24eb0dfa63de6714f499739253dcbade0f65

Payload bytes carried (hex): Receipt (hex):

N56 (number-serialization; expected FAIL, step 5) B writes n as 1800.0. Its RFC 8785 serialization is 1800, so B is not its own serialization, although the value is the n of P1 written another way. Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 460 bytes, SHA-256 dec848505eae6a9cfd4eae1f31f3f1e992d4e3f75ffb17bb2b0c4a38c9c174d4
• receipt bytes: 875 bytes, SHA-256 78b71cb911a1ab306d611180f6a23310ee047ddcbfa7a385342bad39e77cea4f

B (hex): Receipt (hex):

N57 (criteria-digest-pattern; expected FAIL, step 7) criteria_digest has uppercase hexadecimal digits, so it is not sha256: followed by 64 lowercase hexadecimal digits.

• verification key: the issuer test key
• payload bytes B: 550 bytes, SHA-256 10843299cd49f4de2ef357352235aae11d35f31a1ccf344fcdc2146c9ba03c31
• receipt bytes: 995 bytes, SHA-256 d56b2df1da864f8998a45eebaea9795ce872e24b666f02ac20c52b9a8bea15a4

B (hex): Receipt (hex):

N58 (criteria-digest-type; expected FAIL, step 6) criteria_digest is null, not a string.

• verification key: the issuer test key
• payload bytes B: 481 bytes, SHA-256 4e867ad1f3af62d74ebf50e1d080037886fc3c497d82d680fef7caff5effd37c
• receipt bytes: 903 bytes, SHA-256 ae586cad042461a7e8f08f530467ed2242a16fd27cb0b2aabc187660b6071af9

B (hex): 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

B (hex): Receipt (hex):

N60 (payload-trailing-whitespace; expected FAIL, step 5) B is that of P1 followed by one line feed (0a), signed anew. Step 4 admits the line feed under the rules of step 1; step 5 rejects B, because its RFC 8785 serialization has no insignificant whitespace. Note: the signature over these bytes is valid.

• verification key: the issuer test key
• payload bytes B: 459 bytes, SHA-256 9b2463824053df70b4ee5378d97ae64a8c0c4abcdbfb92a4ba02cfcfff047e60
• receipt bytes: 871 bytes, SHA-256 8ae470dfef62873bddb5e7a7c963c0e870f7dd5aec86ab5d79e85472430f4b8f

B (hex): Receipt (hex):

N61 (mixed-order-key; expected FAIL, step 11 (profile 2, key)) The verification key is the mixed-order test key: the issuer's public point plus a point of order 8. It is a canonical encoding and not a point of small order, but it is not of order L, so rule 2 rejects it. The signature satisfies the cofactorless equation under that key; a Receiver without rule 2 would accept it. Note: the key is a pure test key with no RFC 8032 seed; R is of order L and S is below L.

• verification key: the mixed-order test key
• payload bytes B: 458 bytes, SHA-256 8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c
• receipt bytes: 871 bytes, SHA-256 c60d7faea7a71147c8cf2f0013e2630fa6d3913c02462203b74299ce2dc3f596

B (hex): Receipt (hex):

Changes (to be removed before publication)

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.