Citing Signed Evaluation Receipts from Existing Envelopes

3.1. Definition

The receipt digest is SHA-256 over B, the payload bytes of the receipt as defined in [RECEIPTS] Section 3.4: the bytes that steps 1 to 3 of [RECEIPTS] Section 5 obtain from payload_b64. A candidate for which one of those steps fails has no B, even if a lenient decoder would produce bytes from it (cases C6 and C7). It is not computed over the receipt bytes or over PAE(type, B). An envelope that carries the digest as text uses the text form that step 1 of Section 3.3 fixes for its carrier; one that carries it as bytes uses the 32 bytes. This document defines no other hash algorithm.¶

3.2. Why B

The digest runs over B for two reasons.¶

• B is what is signed. The signing input PAE(type, B) depends on B alone, because the type is fixed ([RECEIPTS] Section 4.2). A digest over B therefore names exactly the signed content; a digest over the signing input would carry no further information.¶

• The receipt bytes are not stable. The receipt object around B is not canonicalized, and its key hint is not signed. Vectors P1, P4 and P6 of [RECEIPTS] are three different receipt byte strings that all verify and all carry the same B (cases C1 to C3 of Table 1). A digest over the receipt bytes would give one signed statement three names, and it would change whenever the receipt object is written again. In-toto resource descriptors and the COSE Hash Envelope each name content by the digest of its bytes, and a DSSE envelope carries the bytes themselves.¶

The price of this choice: the receipt digest identifies the signed content, not the signature and not the key. Two receipts with the same B under different keys have the same digest. The iss and kid of a citing Signed Statement (Section 5.2) identify its signer, which need not be the receipt signer. This mapping does not encode a constraint on the receipt signer. A Receiver verifies the cited receipt under the receipt key it fixed independently.¶

3.3. Matching Rule

Given a citation and a candidate receipt, the result is computed as follows. For the JSON representation in Section 5.1, first apply that section's extraction rule; it either gives INDETERMINATE or supplies the algorithm and value for the steps below. The matching result is independent of the typed reference's processing state.¶

1. If the citation's algorithm is not SHA-256, or its value is not 32 bytes in the form that its carrier fixes, the result is INDETERMINATE. SHA-256 is named sha256 as the key of an in-toto digest set [INTOTO-DIGESTSET], -16 as the value of COSE header parameter 258, and sha-256 as the algorithm label of the examples (Appendix A); each name counts only in its own carrier, and names are compared exactly, so SHA256 is none of them. A typed digest reference names it SHA-256 (Section 5.1), an evidence descriptor of [EQR] names it sha-256 in hash_alg (Section 6.2), and in an ExternalRef of [AIR], which carries no algorithm, the type as ref_type names it (Section 6.3). The value is 64 lowercase hexadecimal digits in text form in a digest set (Section 4.3), in a typed digest reference (Section 5.1), in an ExternalRef (Section 6.3) and in the examples (Appendix A.2); it is the base64url encoding without padding of Section 5 of [RFC4648], 43 characters, in an evidence descriptor (Section 6.2), and a string that is not exactly that encoding of 32 bytes is not such a value; and it is 32 bytes as the payload of a statement whose parameter 258 is -16 (Section 5.2). A digest set with several entries is matched on its sha256 entry alone; this document does not judge the other entries. This is narrower than the matching guidance of [INTOTO-DIGESTSET], under which two digest sets match if any acceptable field matches: here a digest set without a sha256 entry gives INDETERMINATE, and one whose sha256 entry passes step 1 but differs from SHA-256 over B gives NO_MATCH, whatever its other entries are.¶

2. If steps 1 through 3 of [RECEIPTS] Section 5 do not all complete successfully, including when processing stops at a resource limit, B is not obtained and the result is INDETERMINATE.¶

3. Otherwise the result is MATCH when SHA-256 over B equals the cited value, and NO_MATCH when it does not.¶

A MATCH establishes neither that the candidate verifies, nor who signed it, nor that its assertion is true. A Receiver that relies on a cited receipt runs the full procedure of [RECEIPTS] Section 5 under a key it fixed. Case C5 is a candidate that matches and fails that procedure at step 11.¶

3.4. Against the Identification Requirements

[STATEMENT-ID] proposes requirements A1 to A5 for references to signed statements. This section checks the receipt digest against them. It is the author's analysis, not a conformance claim.¶

A1, unambiguous target and matching rule:

The scheme names the hash algorithm (SHA-256), the input bytes (B, as steps 1 to 3 of [RECEIPTS] Section 5 obtain it from payload_b64) and the encoding (the text form that step 1 of Section 3.3 fixes for each carrier, or 32 bytes). Section 3.3 is the matching rule. An unsupported algorithm or a candidate without B gives INDETERMINATE, never MATCH (C6 to C8). Identity is preserved under every difference outside B that leaves steps 1 to 3 of [RECEIPTS] Section 5 succeeding: the receipt's whitespace and escapes, its key hint, and its signature value. In the terms of [STATEMENT-ID] Section 5 the receipt digest is a digest of the payload. Because the type is fixed and nothing else enters the signature, it also determines the signing input; neither names the signer.¶

A2, readable without interpreting the carrier's payload:

In the COSE Hash Envelope of Section 5.2 the citation is read from header parameters 258 and 259 and the payload, as [RFC9995] defines them, without interpreting application content. In an in-toto Statement the citation lies inside the predicate, which is the Statement's application content; a reader has to know the predicate to find it. A2 is met by the first and not by the second.¶

A3, matching independent of registration:

B does not change when the receipt is registered anywhere or its object is written again. Cases C2 and C3 carry other receipt bytes and still match.¶

A4, acceptance test for A3:

Cases C2 and C3 apply local changes that a re-encoding may cause (another JSON escape, a key hint left out), and the result stays MATCH. This is not a measurement of registration in two services.¶

A5, receipt-verification dependency:

Matching does not depend on a leaf hash or a COSE Receipt. A receipt has no inclusion proof of its own; a Transparency Service that registers a statement naming it fixes its own leaf construction, and matching does not use it.¶

4.1. DSSE

The signature of a receipt is a valid DSSE signature without any new signature. DSSE [DSSE] signs PAE(payloadType, payload) with the same pre-authentication encoding that [RECEIPTS] Section 4.1 defines. The envelope¶

{"payloadType": <type>, "payload": <base64 of B>,
 "signatures": [{"sig": <the receipt's signature.sig>}]}

therefore verifies as DSSE under the Issuer's key when payloadType is exactly the type and payload decodes to B. Vector M1 (Appendix A) gives the bytes; its signature is the signature of vector P1 of [RECEIPTS], byte for byte. M1 leaves out keyid, which DSSE treats as an optional, unauthenticated hint.¶

A successful DSSE signature check alone is not a receipt verdict. DSSE also requires a supported payloadType and parsing the authenticated payload according to that type. To obtain a receipt verdict, a Receiver decodes the payload and the selected signature once, uses those same bytes to construct the receipt object with canonical base64 as required by [RECEIPTS] Section 3.1, and runs [RECEIPTS] Section 5 under its independently selected receipt verification key.¶

The signature is expected to be valid as DSSE only under this payloadType, because Ed25519 binds the exact signing input; this is not measured beyond sample types. Vector N7 of [RECEIPTS] shows the converse for the receipt itself: its signature, made over PAE with the type application/vnd.example.other+json, fails under the fixed type.¶

4.2. in-toto Statement with test-result

The test-result predicate [TEST-RESULT] records result (PASSED, WARNED or FAILED), configuration (a required list of resource descriptors), url, and the lists passedTests, warnedTests and failedTests. A Statement [INTOTO-STATEMENT] that restates a receipt maps passed to result PASSED or FAILED. No member of the predicate carries the metric, the comparator, the threshold, the score, the sample count or the timestamp; passedTests and failedTests are lists of test names, not a count. The Statement's subject names the tested artifact by digest; a commitment is not a digest of the artifact's bytes, so the model commitment cannot stand as subject without changing what subject means.¶

Such a Statement is a new statement by whoever signs its envelope [INTOTO-ENVELOPE]. It does not carry the receipt's signature and the predicate has no member for the evidence a result rests on. This document therefore does not cite receipts from test-result; the mapping states what a party loses when it restates a receipt in that form.¶

4.3. SLSA Verification Summary

A Verification Summary Attestation [VSA] states that a verifier verified an artifact against a policy. Its inputAttestations is a list of resource descriptors [INTOTO-RD], each of which carries a digest of the attestation it names. A verifier that used a receipt as evidence when it verified an artifact, for example the evaluated model, and verified the receipt under [RECEIPTS] Section 5, cites the receipt there; the artifact itself is the VSA's subject:¶

{"digest": {"sha256": "<receipt digest, 64 hex digits>"},
 "mediaType": "application/vnd.signed-evidence.eval-receipt+json"}

The mediaType identifies B. verificationResult is the verifier's result under its policy, not the receipt's passed: a receipt that verifies and records passed false (vector P2 of [RECEIPTS]) can be the input of a VSA whose verificationResult is PASSED, when the verifier's policy asks only for a valid receipt.¶

5.1. A Typed Digest Reference

[CPB] Section 9 defines a typed digest reference with the members type, purpose, digest_alg and digest, and leaves the declaration of artifact types to the profiles that accept them ([CPB] Section 9.1). This document declares one artifact type for the receipt digest:¶

• type is application/vnd.signed-evidence.eval-receipt+json, the type, which identifies B;¶

• there is one digest context, so purpose is absent;¶

• the context has no purpose label, so a well-formed reference that carries purpose is Unresolved ([CPB] Section 9.1);¶

• the canonicalization algorithm is as-transmitted ([CPB] Section 5.4), with the byte-boundary selector [RECEIPTS] Section 3.4, "The Bytes B";¶

• the pre-image is B as Section 3.1 defines it, the bytes that steps 1 to 3 of [RECEIPTS] Section 5 obtain, with no exclusion set, no further encoding and no domain separation;¶

• the hash function is SHA-256, and digest_alg is exactly SHA-256;¶

• digest is the receipt digest as its 64 lowercase hexadecimal digits, a text value; in the cpb-refs header parameter of [CPB] Section 9.3 it is a text string.¶

For the JSON representation defined here and used in Appendix A.7, a reference is one JSON object [RFC8259] with the required members type, digest_alg and digest, and the optional member purpose. Each of these members, when present, has a JSON string value. No other member is allowed. Member names of this object are compared after JSON string unescaping, without case folding or Unicode normalization; repeated names are detected before any conversion that could discard them. Input that violates the JSON grammar, is not an object, has a repeated member name, lacks a required member, has a non-string value for one of the named members, or has another member is Malformed ([CPB] Section 4). A byte order mark before the JSON text is not part of the JSON grammar, so such input is Malformed, although [RFC8259] Section 8.1 allows a parser to ignore it. Input that is not UTF-8 is Malformed as well ([RFC8259] Section 8.1); no replacement character is substituted before this check. This form check precedes reference resolution and verification. The rules assigning Unresolved, Failed or Verified apply only to well-formed references. These form requirements define this JSON representation; they do not replace the rules for cpb-refs or another profile's own serialization.¶

For this JSON representation, the independent matching result of Section 3.3 is INDETERMINATE unless the input is UTF-8, conforms to the JSON grammar, its top-level value is an object, and that object contains exactly one digest_alg member and exactly one digest member, both with string values. Otherwise Section 3.3 applies to those two values regardless of the reference state. No occurrence is chosen from repeated digest_alg or digest members, even if their values agree, and non-string values are not converted to strings. A matching result does not change the reference state or make a Malformed reference Verified.¶

A reference under this declaration can stand in the cpb-refs header parameter of a Signed Statement, or in a payload that carries references in its own serialization, for example in the references of [CAPSULE]. For a well-formed reference, context selection and verification follow [CPB] Section 9.1. A well-formed reference whose type is not the type of this declaration is not under it; where no other declaration that the consuming profile accepts matches it, it is Unresolved ([CPB] Section 9.1). A consuming profile that does not name this declaration by normative reference leaves a well-formed reference to it Unresolved; no profile names it at the time of writing. Once this digest context has been selected, a digest_alg other than SHA-256 or a digest outside the declared text representation of 64 lowercase hexadecimal digits makes the reference Failed. Section 3.3 gives INDETERMINATE for either case. After those checks, a verifier that does not implement the construction of this context leaves the reference Unresolved (cause: unimplemented), whether or not a receipt can be obtained. A verifier that implements it obtains the cited receipt and takes B from it by steps 1 to 3 of [RECEIPTS] Section 5. If no receipt is obtained, the reference is Unresolved (cause: unavailable), and the matching result is INDETERMINATE, as in step 2 of Section 3.3. If a receipt is obtained and those steps fail, it is not input that the construction of this context accepts, and the reference is Failed ([CPB] Section 9.1). If those steps stop at a resource limit, the verifier reports the resource-limit error of [RECEIPTS] Section 5 instead of a state, as in Section 5.2.2. When those steps fail or stop at a resource limit, the matching result is INDETERMINATE. Otherwise the verifier computes SHA-256 over B and compares its hexadecimal text with digest: equality gives Verified and MATCH, and inequality gives Failed and NO_MATCH. Vectors R1 to R16 (Appendix A.7) illustrate these states and Malformed.¶

Only the digest crosses, as for the Signed Statement below. A reference that is Verified shows that the cited bytes are B; it does not show that the receipt verifies, who signed it, or that its assertion is true ([CPB] Section 9.5).¶

5.2. A Signed Statement that Cites a Receipt

A Signed Statement that cites a receipt is a COSE_Sign1 [RFC9052] with CBOR tag 18 in the form of a COSE Hash Envelope [RFC9995]. It has one of two profiles, which differ in how the statement names its signer. In the key profile, kid names an Ed25519 statement key that the Receiver has configured for the issuer. In the certificate profile, the protected header carries an X.509 certificate chain [RFC9360] whose last certificate is a trust anchor that the Receiver has configured for a did:x509 issuer [DIDX509]. The labels of the protected header select the profile (step 2 of Section 5.2.2). Vector M2 (Appendix A) is a statement in the key profile, vector X1 one in the certificate profile.¶

Both profiles share these rules:¶

• The protected header holds exactly the parameters of its profile, given below, and no other. Three of them are the same in both profiles:¶

  • 15 (CWT Claims) [RFC9597]: a map with exactly 1 (iss), whose form each profile gives, and 2 (sub), the text value of model_id_commit of B;¶

  • 258 (payload hash algorithm): -16 (SHA-256);¶

  • 259 (preimage content type): the type, as a text string.¶

• The unprotected header is the empty map.¶

• The payload is the receipt digest, 32 bytes.¶

• The COSE_Sign1, its protected header included, is encoded with the core deterministic encoding of [RFC8949] Section 4.2.1.¶

Key profile. The protected header holds exactly the five parameters 1, 4, 15, 258 and 259:¶

• 1 (alg): -19, Ed25519 as fully specified in [RFC9864], or -8, EdDSA [RFC9053]. A party that makes a statement MUST write -19. A Receiver MUST accept both values and applies every other check of Section 5.2.2 to either; under the Ed25519 statement keys that step 3 selects, both values select the same signature algorithm. Changing alg changes the protected header bytes and requires a new signature (Section 5.2.4);¶

• 4 (kid): the COSE Key Thumbprint [RFC9679] with SHA-256 of the statement key, a byte string of 32 bytes. For an Ed25519 public key x, kid is SHA-256 over the core-deterministically encoded COSE_Key map {1: 1, -1: 6, -2: x}; no optional COSE_Key parameter enters the thumbprint;¶

• 15 (CWT Claims): iss is an absolute URI ([RFC3986] Section 4.3) that names the party that makes the statement.¶

Its form is fixed, so that one receipt digest, one statement key, one issuer and one algorithm value give one byte string.¶

Certificate profile. The protected header holds exactly the six parameters 1, 4, 15, 33, 258 and 259:¶

• 1 (alg): -7, ECDSA with SHA-256 ([RFC9053] Section 2.1); the signature is r and s, 32 bytes each, under the P-256 public key of the leaf certificate (Section 5.2.4);¶

• 4 (kid): SHA-256 over the DER encoding of the SubjectPublicKeyInfo [RFC5280] of the leaf certificate, a byte string of 32 bytes;¶

• 15 (CWT Claims): iss is a did:x509 identifier [DIDX509] that is exactly the concatenation of the text did:x509:0:sha256:, F, the text ::eku: and O, with no other character, where F is SHA-256 over the DER bytes of the last certificate of x5chain, encoded in base64url without padding (43 characters), and O is an object identifier in dotted decimal form: the first arc is 0, 1 or 2, it is followed by one or more further arcs, the second arc is at most 39 when the first arc is 0 or 1, the arcs are separated by full stops, and each arc is a decimal number without leading zeros;¶

• 33 (x5chain) [RFC9360]: an array of exactly two byte strings, each a DER-encoded X.509 certificate [RFC5280]: first the leaf certificate, whose P-256 public key verifies the statement signature, then the trust anchor certificate, whose RSA public key signed the leaf certificate with sha256WithRSAEncryption (RSASSA-PKCS1-v1_5 with SHA-256, [RFC8017]).¶

This profile names one trust anchor and no intermediate certificate. The profile is limited to this form, two certificates with an RSA trust anchor, because it is the form measured to work (Section 14). An x5chain array with more or fewer than two elements, an x5chain that is a single byte string, and an iss with a predicate other than one eku give outside_profile in step 2 of Section 5.2.2. Certificate contents, key restrictions and their bindings are checked in step 3, which gives untrusted_key when one of those checks fails. An ECDSA signature depends on a per-signature nonce, so one statement in this profile can have more than one byte string; the vectors use the deterministic nonce of [RFC6979], which a Receiver does not check.¶

The value of sub is a choice of this example; the receipt digest does not depend on it. The key that signs a statement and the receipt key can be the same key or different keys. The statement carries its own signature over its own Sig_structure; it is not the receipt's signature, even when one key makes both. Registering M2 or X1 with a Transparency Service yields a COSE Receipt for that statement, not for the evaluation receipt.¶

6.1. Control Delivery Evidence

[ACDE] (revision -02) states evidence requirements for the delivery of control instructions, such as stop or suspend, to enforcement points. It defines a logical evidence model and no wire format; its illustrative record is, in its own words, "deliberately not a wire format". Every observation used to correlate an instruction binds the instruction identifier to a digest of either the exact instruction or a declared canonical projection of it, and the applicable protocol or profile identifies the projection, the digest algorithm, the canonicalization rule and the domain-separation rule, if any (its Section 5.2, R-CD-2). Records within one declared identity-uniqueness scope that reuse one instruction identity with different governed content are SUBSTITUTION, also between issuer and receiver records (its Section 6.1).¶

A receipt that motivates a control can therefore be cited inside the governed instruction: an instruction whose exact bytes contain a typed digest reference to the receipt (Section 5.1) carries the citation, and every observation that binds the digest of those bytes binds the citation with them. An observation that binds the digest of an instruction with another citation does not bind the same content. Section 7 of [ACDE] also lists, next to the instruction identifier, an attachment point for a reference to the upstream decision, action, task or session; whether a receipt on which such a decision rested may be referenced there is left open by that draft.¶

Matching applies Section 3.3 to the typed digest reference that is the value of the citing member of the instruction; the rule of Section 5.1 that takes digest_alg and digest from a top-level object applies to that value. The matching result does not change a disposition of [ACDE], and a disposition does not change the matching result.¶

Open in [ACDE] -02, and not assumed here:¶

• the format of a control instruction, and so the member that holds a citation, and whether the exact bytes or a projection of them are hashed (the vectors hash the exact bytes of a JSON object in the serialization of [RFC8785], with no domain separation, and use a member basis);¶

• the form of the reference to an upstream decision in its Section 7, whether it may name a receipt, and whether it may carry a digest;¶

• the representation of a content digest (the vectors use sha-256: followed by 64 lowercase hexadecimal digits; the illustrative record of [ACDE] writes sha-256:<digest> and fixes no encoding of the digest).¶

6.2. Evidence Qualification Receipts

[EQR] (revision -00) defines the Evidence Qualification Receipt (EQR), a JSON object that binds a proposition to a versioned evidence profile and lists evidence descriptors. Each descriptor binds at least a digest and an evidence class; sha-256 is the mandatory-to-implement digest algorithm, and digest values are base64url without padding (its Section 5). Its Section 5 also says that an implementation that computes a digest over a JSON payload should use [RFC8785] before hashing, and that the applicable profile defines the bytes hashed for an object that is not JSON.¶

An EQR cites a receipt with one evidence descriptor, written with the member names of the example in its Section 5.2: class is the type, hash_alg is sha-256, and digest is the receipt digest in base64url without padding. B is in the serialization of [RFC8785] (step 5 of [RECEIPTS] Section 5), so its RFC 8785 bytes are B itself and the digest over them is the receipt digest. The bytes cited are B, not the receipt object (Section 3.2); an EQR profile that admits receipts as evidence is where that choice would be stated.¶

Matching applies Section 3.3 to hash_alg and digest of the descriptor. An EQR that is valid under Section 8 of [EQR] and qualifies under its Section 8.1 shows nothing about the cited receipt, and the two results stay apart.¶

Open in [EQR] -00, and not assumed here:¶

• a vocabulary of evidence classes, and whether the local trust policy of step 7 of its Section 8 accepts the type as a class;¶

• the member names of an evidence descriptor, which appear only in its example (the vectors use class, hash_alg and digest);¶

• the format of an evidence profile, which it does not define (the vectors use a JSON object of their own);¶

• how a profile states which bytes of a cited object are hashed;¶

• local metadata such as a retrieval reference for the receipt, which it leaves to deployments.¶

6.3. Agent Interaction Records

[AIR] (revision -01) defines the AgentInteractionRecord (AIR), the payload of a COSE_Sign1 Signed Statement that records one action of an agent. The payload is the serialization of the record under [RFC8785] (its Sections 5.6 and 5.7); external_refs is a required array of ExternalRef objects, each with the members ref_type and ref_value, both text, and ref_system, text or null, for references into other systems (its Sections 5.2 and 5.3). Its Section 10.1 names external_refs as the place for a reference to a related authorization record.¶

An AIR cites a receipt with one ExternalRef: ref_type is the type, ref_value is the receipt digest as 64 lowercase hexadecimal digits, and ref_system is null. The citation lies in the payload, so the content_hash of the record and its signature cover it (Sections 5.5 to 5.8 of [AIR]).¶

Matching applies Section 3.3 to the ref_value of an ExternalRef whose ref_type is the type; that ref_type names SHA-256. A record that passes the four steps of Section 5.8 of [AIR] is VERIFIED in the sense of that document, which shows nothing about the cited receipt.¶

Open in [AIR] -01, and not assumed here:¶

• a vocabulary of ref_type values, and whether a digest may be a ref_value;¶

• the JSON representation of the members that its CDDL gives as byte strings, such as input_hash and outcome_hash, in a payload that is JSON (the vectors write lowercase hexadecimal digits);¶

• whether content_hash is taken over the content of the payload byte string or over its CBOR encoding (its Section 5.7 calls the payload both "the raw byte string" and "the CBOR-encoded canonical JSON serialisation"; the vectors hash the content, the JSON bytes);¶

• whether members whose value is null are written or left out (the vectors write every member of the CDDL);¶

• the encoding of a protected header that mixes integer and text labels (the vectors use the core deterministic encoding of [RFC8949] Section 4.2.1), and how the text operator_pubkey_id becomes the byte string kid (the vectors use its UTF-8 bytes).¶

15.1. Normative References

[CPB]

Mih, S. and A. Sokolov, "Canonicalization Declaration for SCITT Signed Statements", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-06, 26 October 2026, <https://datatracker.ietf.org/doc/draft-mih-sokolov-scitt-payload-binding/06/>.

[DSSE]

Secure Systems Lab, "DSSE: Dead Simple Signing Envelope, protocol specification, version 1.0.2", 28 May 2024, <https://github.com/secure-systems-lab/dsse/blob/v1.0.2/protocol.md>.

[INTOTO-DIGESTSET]

in-toto project, "in-toto Attestation Framework: DigestSet field type, v1 (release v1.2.0)", 18 March 2026, <https://github.com/in-toto/attestation/blob/v1.2.0/spec/v1/digest_set.md>.

[INTOTO-RD]

in-toto project, "in-toto Attestation Framework: ResourceDescriptor field type, v1 (release v1.2.0)", 18 March 2026, <https://github.com/in-toto/attestation/blob/v1.2.0/spec/v1/resource_descriptor.md>.

[INTOTO-STATEMENT]

in-toto project, "in-toto Attestation Framework: Statement layer, v1 (release v1.2.0)", 18 March 2026, <https://github.com/in-toto/attestation/blob/v1.2.0/spec/v1/statement.md>.

[PRML]

Öztürk, C., Ed., "PRML: Pre-Registered ML Manifest Specification, Version 0.1", 1 May 2026, <https://spec.falsify.dev/v0.1>.

[RECEIPTS]

Gruszka, K., "Signed Evaluation Receipts", Work in Progress, Internet-Draft, draft-gruszka-signed-evaluation-receipts-04, October 2026, <https://datatracker.ietf.org/doc/draft-gruszka-signed-evaluation-receipts/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC8017]

Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, <https://www.rfc-editor.org/info/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, August 2022, <https://www.rfc-editor.org/info/rfc9053>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, February 2023, <https://www.rfc-editor.org/info/rfc9360>.

[RFC9597]

Prorock, M., Steele, O., Mahy, R., and H. Birkholz, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, July 2024, <https://www.rfc-editor.org/info/rfc9597>.

[RFC9679]

Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object Signing and Encryption (COSE) Key Thumbprint", RFC 9679, December 2024, <https://www.rfc-editor.org/info/rfc9679>.

[RFC9864]

Jones, M. B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, October 2025, <https://www.rfc-editor.org/info/rfc9864>.

[RFC9995]

Steele, O., Lasker, S., and H. Birkholz, "CBOR Object Signing and Encryption (COSE) Hash Envelope", RFC 9995, July 2026, <https://www.rfc-editor.org/info/rfc9995>.

[VSA]

OpenSSF SLSA project, "SLSA Verification Summary Attestation (VSA), version 1", n.d., <https://slsa.dev/spec/v1.2/verification_summary>.

15.2. Informative References

[ABAK]

Abak, A. T., "Claim-Preserving Exchange of AI Evaluation Evidence", Work in Progress, Internet-Draft, draft-abak-ai-evaluation-claim-preservation-00, 23 September 2026, <https://datatracker.ietf.org/doc/draft-abak-ai-evaluation-claim-preservation/00/>.

[ACDE]

Abak, A. T., "Evidence Requirements for Agent Control Delivery and Outcome Reconciliation", Work in Progress, Internet-Draft, draft-abak-agent-control-delivery-evidence-02, 11 October 2026, <https://datatracker.ietf.org/doc/draft-abak-agent-control-delivery-evidence/02/>.

[AIR]

Emirdag, P. and D. Feichtinger, "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-execution-01, 12 October 2026, <https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/01/>.

[CAPSULE]

Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action-capsule-05, 26 September 2026, <https://datatracker.ietf.org/doc/draft-mih-scitt-agent-action-capsule/05/>.

[DIDX509]

Riechert, M. and A. Delignat-Lavaud, "did:x509 Method Specification, method version 0 (status: draft)", 6 October 2026, <https://github.com/microsoft/did-x509/blob/054f1f6e364580c42fad862747903f2a6ee19976/specification.md>.

[EQR]

Watts, D., "Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts", Work in Progress, Internet-Draft, draft-watts-agent-evidence-boundary-00, 12 September 2026, <https://datatracker.ietf.org/doc/draft-watts-agent-evidence-boundary/00/>.

[FRAMING-SPACE]

Templeman, N., "Measuring the CBOR Framing Space of COSE_Sign1 Data-Hash Pre-images", Work in Progress, Internet-Draft, draft-templeman-scitt-framing-space-01, 27 September 2026, <https://datatracker.ietf.org/doc/draft-templeman-scitt-framing-space/01/>.

[INTOTO-ENVELOPE]

in-toto project, "in-toto Attestation Framework: Envelope layer, v1 (release v1.2.0)", 18 March 2026, <https://github.com/in-toto/attestation/blob/v1.2.0/spec/v1/envelope.md>.

[PRML-PROFILE]

Öztürk, C., "A SCITT Profile for Pre-Run Evaluation Criteria (PRML)", Work in Progress, Internet-Draft, draft-ozturk-scitt-prml-profile-00, 11 September 2026, <https://datatracker.ietf.org/doc/draft-ozturk-scitt-prml-profile/00/>.

[RFC3552]

Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC6979]

Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, June 2026, <https://www.rfc-editor.org/info/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, June 2026, <https://www.rfc-editor.org/info/rfc9943>.

[STATEMENT-ID]

Gruszka, K., "Requirements and Test Cases for Identifying SCITT Signed Statements", Work in Progress, Internet-Draft, draft-gruszka-scitt-statement-identification-03, October 2026, <https://datatracker.ietf.org/doc/draft-gruszka-scitt-statement-identification/>.

[TEST-RESULT]

in-toto project, "in-toto Attestation Framework: Test Result predicate, v0.1 (release v1.2.0)", 18 March 2026, <https://github.com/in-toto/attestation/blob/v1.2.0/spec/predicates/test-result.md>.

A.1. Constants

Type:¶

application/vnd.signed-evidence.eval-receipt+json

Issuer test key, public key (base64 and hex):¶

x7ppA99DtumHO/Au0M/gumSK8IwCzNwPiID92BSFbak=
c7ba6903df43b6e9873bf02ed0cfe0ba648af08c02ccdc0f8880fdd814856da9

Issuer URI of the Signed Statement (iss):¶

https://issuer.example/eval

A.2. Digests of Vector P1

B, 458 bytes (hex):¶

7b22636f6d6d69745f616c67223a227368613235362d73616c7465642d763122
2c22636f6d70617261746f72223a223e3d222c22646174617365745f69645f63
6f6d6d6974223a227368613235363a6132316261346439366338303364343236
3364643364323136316263303339613330663434363262643539343730653331
626135613961623061396233623633222c226d6574726963223a226163637572
616379222c226d6f64656c5f69645f636f6d6d6974223a227368613235363a39
3034646534323536326639613139363531653139656237616231363565346666
6531313463653561326639386535376461353833383935393638346662306622
2c226e223a313830302c22706173736564223a747275652c22736368656d6122
3a2268747470733a2f2f7369676e65642d65766964656e63652e6f72672f6576
616c2d726563656970742f7631222c2273636f7265223a22302e383334222c22
7375697465223a2261636d652d7361666574792d7375697465222c2273756974
655f76657273696f6e223a22312e322e30222c227468726573686f6c64223a22
302e383030222c2274696d657374616d70223a22323032362d31302d30325430
303a30303a30305a227d

Receipt digest, SHA-256 over B:¶

8cd849a6dcce08aee334511d7b2f31c54e478885dda1795d3c8f972dd0d4811c

SHA-256 over the receipt bytes of P1; not the receipt digest:¶

02036d1f57509858330383755ec16c532bdc58b0f2d949464488d57abc9f95e7

A.3. Citation Cases

Every case cites B of P1. Cases C1 to C7 cite, with the algorithm sha-256, the receipt digest given in Appendix A.2. C8 cites, with the algorithm sha-512, this value over the same B:¶

d5cccf69bb4f9b2c6d102e1a4da3d057cf8fc00bbbae69c0889bb423d243e246
1685c907c22f86f34c15290063ee3cd0c5815a85e25e40ef1609fcd4e11c2dc8

The candidates are the vectors of [RECEIPTS] named in Table 1, whose bytes are given there. Case and SHA-256 over the candidate's receipt bytes:¶

C1 02036d1f57509858330383755ec16c532bdc58b0f2d949464488d57abc9f95e7
C2 c2a7943f0ea3de6e9da88c11925b1e112d32f697a403f07fcfbc3776bca10e72
C3 2c8144d50b4cc42a712d84e4d0417e52b0d8cbc484ad8e6d8d4b36a429b94ec1
C4 2405d1783d1803ddea207c027622fba40b3e82161686505ee96988e306e17278
C5 18b1b6dc631cf0f00d8b0d2c237b28a67b12c2d7088ae0313a2fb27760f96bdd
C6 31a34194edd90bade6568a3cb00dbb983dabab9efccfd7a8b38650bd3e8d5201
C7 8966f27c5f2566d986b0ab7821060ea0c901504fe984d450dfc7f8ca7d1c27e1
C8 02036d1f57509858330383755ec16c532bdc58b0f2d949464488d57abc9f95e7

The expected results are those of Table 1; the reasons are:¶

• C1: SHA-256 over the candidate's B equals the cited digest.¶

• C2: SHA-256 over the candidate's B equals the cited digest.¶

• C3: SHA-256 over the candidate's B equals the cited digest.¶

• C4: SHA-256 over the candidate's B differs from the cited digest.¶

• C5: SHA-256 over the candidate's B equals the cited digest.¶

• C6: B not obtained, step 3 of [RECEIPTS] Section 5 fails.¶

• C7: B not obtained, step 1 of [RECEIPTS] Section 5 fails.¶

• C8: Citation algorithm not defined.¶

A.4. M1, DSSE Envelope with the Receipt's Signature

The envelope is a JSON object with the members payloadType, payload and signatures, serialized without insignificant whitespace and with members sorted by name. Its only signature is signature.sig of P1, unchanged; it verifies as Ed25519 over PAE(payloadType, payload) under the issuer test key.¶

PAE(type, B) of [RECEIPTS] Section 4.1: 522 bytes, SHA-256 6ffed54e62fa5d5e37830be8435f44466a4016013049b6f3307b6adef909aecc.¶

Envelope, 806 bytes (hex):¶

7b227061796c6f6164223a2265794a6a62323174615852665957786e496a6f69
633268684d6a55324c584e686248526c5a4331324d534973496d4e7662584268
636d4630623349694f69492b50534973496d52686447467a5a58526661575266
5932397462576c30496a6f69633268684d6a55324f6d45794d574a684e475135
4e6d4d344d444e6b4e4449324d32526b4d3251794d545978596d4d774d7a6c68
4d7a426d4e4451324d6d4a6b4e546b304e7a426c4d7a4669595456684f574669
4d474535596a4e694e6a4d694c434a745a58527961574d694f694a6859324e31
636d466a65534973496d31765a47567358326c6b58324e766257317064434936
496e4e6f595449314e6a6f354d44526b5a5451794e5459795a6a6c684d546b32
4e54466c4d546c6c596a6468596a45324e5755305a6d5a6c4d54453059325531
59544a6d4f54686c4e54646b595455344d7a67354e546b324f44526d596a426d
49697769626949364d5467774d4377696347467a6332566b496a7030636e566c
4c434a7a5932686c625745694f694a6f64485277637a6f764c334e705a32356c
5a43316c646d6c6b5a57356a5a533576636d63765a585a68624331795a574e6c
615842304c3359784969776963324e76636d55694f6949774c6a677a4e434973
496e4e316158526c496a6f6959574e745a53317a59575a6c64486b7463335670
644755694c434a7a64576c305a5639325a584a7a61573975496a6f694d533479
4c6a41694c434a3061484a6c63326876624751694f6949774c6a67774d434973
496e52706257567a6447467463434936496a49774d6a59744d5441744d444a55
4d4441364d4441364d444261496e303d222c227061796c6f616454797065223a
226170706c69636174696f6e2f766e642e7369676e65642d65766964656e6365
2e6576616c2d726563656970742b6a736f6e222c227369676e61747572657322
3a5b7b22736967223a22434247744e323639464f68505372357865307a6c4a47
53424e427a47696e457a38693031664d36312b4a4e614a50646e5a793148626f
596934656d686d384b5a715055337973546d726d434578537653786f637a4241
3d3d227d5d7d

SHA-256 over the envelope bytes; not the receipt digest:¶

d96e0b9635949045a6f7c7b29eac8c163f6fad0d6d0bff446beeff601e45fed0

A.5. M2, SCITT Signed Statement Citing the Receipt by Digest

A COSE_Sign1 with CBOR tag 18 in the form of a COSE Hash Envelope. The protected header holds these parameters, in this order:¶

• 1 (alg): -19¶

• 4 (kid): a 32-byte string, given below¶

• 15 (CWT Claims): a map with 1 (iss), the URI of Appendix A.1, and 2 (sub), the text string given below¶

• 258 (payload hash algorithm): -16¶

• 259 (preimage content type): the type, as a text string¶

kid, the COSE Key Thumbprint (SHA-256) of the issuer test key (hex):¶

c94d618c32417cedb44280d4d66029e6486aa834802d12cd919c817453eb1561

sub, the model commitment of B:¶

sha256:904de42562f9a19651e19eb7ab165e4ffe114ce5a2f98e57da5838959684fb0f

Protected header, the deterministic encoding of these parameters: 202 bytes, SHA-256 6d9a1e26f95a4588e6a6907669ee721680b270776533cad1a5c4688877b388ab.¶

The unprotected header is the empty map. The payload is the receipt digest given in Appendix A.2.¶

Sig_structure (ToBeSigned) of [RFC9052] Section 4.4, with external_aad the empty byte string: 251 bytes, SHA-256 4d2c862f04a9af14e7da56df52898ac4abb0f20fca6e3e0a04b918a7f063132d. The signature, Ed25519 over it under the issuer test key, is the last 64 bytes of the COSE_Sign1.¶

COSE_Sign1, 307 bytes (hex):¶

d28458caa50132045820c94d618c32417cedb44280d4d66029e6486aa834802d
12cd919c817453eb15610fa201781b68747470733a2f2f6973737565722e6578
616d706c652f6576616c0278477368613235363a393034646534323536326639
6131393635316531396562376162313635653466666531313463653561326639
38653537646135383338393539363834666230661901022f1901037831617070
6c69636174696f6e2f766e642e7369676e65642d65766964656e63652e657661
6c2d726563656970742b6a736f6ea058208cd849a6dcce08aee334511d7b2f31
c54e478885dda1795d3c8f972dd0d4811c5840f8be22ab6b1c196611d884ea63
5f610ac45c042ab7958828c2af46dd5e35ac8d66b0c01fc115f7d93597f3cf78
3e95df37ef78da9006b773e08e6239af01a10e

SHA-256 over the COSE_Sign1 bytes:¶

64e78be4636b8d1e90cb7a1ebe06c4cfba2848603d6f64958d7c2080a901c575

A.6. Status Vectors

Each vector is a Signed Statement presented with a candidate receipt of [RECEIPTS], whose bytes are given there. The Receiver's receipt key is the issuer test key, and its one configured pair is the issuer URI of Appendix A.1 with the issuer test key. With M2, the vectors give one statement for each status of Section 5.2.2; S1 is the statement with alg -8 that every Receiver accepts (Section 5.2.4).¶

What each vector shows:¶

• M2: the statement of Appendix A.5, with the receipt it was made from.¶

• S1: M2 with alg -8 in place of -19, signed again under the issuer test key.¶

• S2: the bytes of M2 with CBOR tag 98 (COSE_Sign) in place of tag 18.¶

• S3: alg -7 (ES256), signed again under the issuer test key.¶

• S4: kid names the foreign test key, which signs it; no configured pair has that key.¶

• S5: kid names the issuer test key, the foreign test key signs it.¶

• S6: M2, presented with N7, which fails step 11 of [RECEIPTS] Section 5.¶

• S7: a statement on B of P2, with sub its model commitment, presented with P1.¶

• S8: M2 with sub the dataset commitment of P1, signed again.¶

S4 and S5 are signed by a foreign test key whose seed is SHA-256 over the UTF-8 bytes of "foreign statement key, PURE TEST KEY"; it MUST NOT be used for anything real. Its public key (base64 and hex):¶

8Jv/BfSuPxDYgM2PeOlxCSUOFRF/ZC53c2PTs7sjvnM=
f09bff05f4ae3f10d880cd8f78e97109250e15117f642e777363d3b3bb23be73

Each of S1, S3, S4, S5, S7 and S8 is a COSE_Sign1 with tag 18 in the deterministic encoding whose protected header is the deterministic encoding of the protected header of M2 with the change named above, whose unprotected header is the empty map, whose payload is that of M2 except for S7, whose payload is SHA-256 over B of P2, and whose signature, given below, is Ed25519 over its own Sig_structure. S2 is the bytes of M2 with the first byte d2 replaced by the two bytes d8 62. S6 is M2.¶

S1, signature (hex):¶

a4a112c376243af157d0335babe0d43aa1d6b6e50137a4c95d8b93a345786565
546f009bd739bc3dcadf69f78ef1f7870eba885d123dd480b528acb2f83c960c

S3, signature (hex):¶

76d76d742ee817df32f456dae6ddf646442962a4e8993a00041bb4fb5bed9595
33bb7bc10ffd4bf2a2fa6365565e0015e99b0f46809db250778f203921482201

S4, signature (hex):¶

613b433477c5ff77148e22ac70044244a13fc352dc18717827598c313c56e656
d317880d09c975139772499a7ba5fb48601147ce6de47d86bf9217da85ab5e0e

S5, signature (hex):¶

778e57e38d8e4f3ed08c291362a5803a364b41a4d6ebe112ea411abe7aaa946f
bfae6907adddf81ecb2a8efb898bdf55b2c96425f6a264a87e71ca2594f0370d

S7, signature (hex):¶

e98ea4b9da8e6568c9905f308cfdf4c609f941fe311c3484cae0813502201137
a0fdd92fc83f542718508ccf6122d80e73c42ec4dd61b366e9860a8bb472d700

S8, signature (hex):¶

1a820d86d8615d7b60d5e7d7f9791a7ae27b49fbce1d554bb7444407b0a9926b
ec5ea93f45d342f86291b14c79ee84d3d50e1bf915c21621b852afe91a613201

Vector and SHA-256 over its bytes:¶

S1 4ffcd0d2a970d9dfa17cc9ffed00d7ff84b368177390bb170ee270bc1a336bda
S2 652517f5fe70201d687a073ad81a5057079aa0f4575a6055950c50b472b6a90e
S3 75acb36c52ff43f1ee137aa816967f75142535213a08fb3b95d306cba38b227d
S4 88463392ccefcd436f17e36e647830c5e4fd8f3e7714f7c5e2ad9f54dae8c3ec
S5 f422a35282e540745e1d982847a79dbbacb13a9de9ef6353bf37ec3850f76224
S6 64e78be4636b8d1e90cb7a1ebe06c4cfba2848603d6f64958d7c2080a901c575
S7 8f275a639482390b6e187fd9e224e4c5af38b9985a321c7d148674e9ece0aae7
S8 7460b48972153c566ad6eaaad35a4d335f24d7f52512d58a519de215b016cc30

A.7. Typed Digest References

Each vector supplies an input to the typed digest reference processing of Section 5.1. R1 is a JSON object with exactly three members: type, the type; digest_alg, SHA-256; and digest, the receipt digest of Appendix A.2 as 64 lowercase hexadecimal digits. Each other vector is R1 with the change in Table 6; "names B of P2" means SHA-256 over B of vector P2 of [RECEIPTS], as 64 lowercase hexadecimal digits. The candidate is the vector of [RECEIPTS] named in the table. For State, assume a consuming profile that accepts the declaration in Section 5.1, and no other, by normative reference, and a verifier that implements the construction of its context and obtains the candidate. State is the reference processing state in the terms of [CPB] Sections 4 and 9.1. Matching rule is the independent result of Section 3.3, including the JSON extraction rule in Section 5.1.¶

What each vector shows:¶

• R1: a reference under the declaration, with the receipt it names.¶

• R2: R1 with a purpose member; the context has no purpose label.¶

• R3: R1 with digest_alg sha-256, not the exact token SHA-256.¶

• R4: R1 with the digest in uppercase hexadecimal digits.¶

• R5: a reference that names B of P2, presented with P1.¶

• R6: R1 presented with N13, which fails step 3 of [RECEIPTS] Section 5, so B is not obtained from it; N13 is not input that the construction accepts.¶

• R7: R1 with a member that the declaration does not name.¶

• R8: R1 with a second digest member that names B of P2; neither value is chosen.¶

• R9: R1 without digest_alg.¶

• R10: R1 inside a JSON array, which is not a JSON object.¶

• R11: R1 with purpose set to null, not a JSON string. Unlike R2, this is a form error before context selection.¶

• R12: R1 with the sole digest member name written as "\u0064igest" in the JSON text; the decoded name is unchanged.¶

• R13: R1 with an additional member named "\u0064igest" whose value equals the original digest. The decoded names are equal; equal values do not make a repeated name acceptable.¶

• R14: R1 with the UTF-8 byte order mark EF BB BF before the JSON text; this representation does not ignore it.¶

• R15: R2 with the byte FF, which is not UTF-8, in place of the first letter of the purpose value. A decoder that substituted a replacement character would read a well-formed reference with purpose, as in R2; this representation does not.¶

• R16: R1 with type text/⁠plain, a well-formed reference that is not under the declaration. The consuming profile accepts no other declaration, so it is Unresolved; its algorithm and digest are still extracted and compared.¶

The matching rule compares an unambiguously extracted algorithm and digest independently of the reference state. Thus R2 and R16 give MATCH while Unresolved, and R7 and R11 give MATCH while Malformed. Neither result makes the reference Verified.¶

A.8. Certificate-Profile Vectors

Each vector is a Signed Statement in the form of the certificate profile, or one change away from it, presented with vector P1 of [RECEIPTS]. The Receiver's receipt key is the issuer test key, and its one configured certificate pair is the did:x509 identifier below with the test root certificate. The test root holds an RSA-3072 key and the test leaf a P-256 key; both certificates, and the other P-256 key that signs X6, are test material made by the generator of Appendix A, and they MUST NOT be used for anything real. The signatures use the deterministic nonce of [RFC6979].¶

iss of X1, the identifier of the configured pair, is the concatenation that Section 5.2 defines, 84 characters long, with F, SHA-256 over the test root certificate in base64url without padding, and O, the object identifier of code signing:¶

F 27XKFJ4cMLsuFMzbCyW81i24r8Un94N9wwLkmA5QE20
O 1.3.6.1.5.5.7.3.3

Test leaf certificate, 819 bytes (hex):¶

3082032f30820197a003020102020102300d06092a864886f70d01010b050030
3f313d303b06035504030c346576616c2d72656365697074206d617070696e67
73207465737420726f6f742028505552452054455354204d4154455249414c29
301e170d3236303130313030303030305a170d3335313233313233353935395a
304b3149304706035504030c406576616c2d72656365697074206d617070696e
677320746573742073746174656d656e74207369676e65722028505552452054
455354204d4154455249414c293059301306072a8648ce3d020106082a8648ce
3d030107034200042b7ff297baafbcd54b9c2804c2025d5e84d51d24151ffe62
af08557f4cba8841c0b05fc73ddaf743e4a05f06c872da47c8af27d87a5a93c4
b85bc16a6f603735a3753073300c0603551d130101ff04023000300e0603551d
0f0101ff040403020780301d0603551d0e0416041492e1e87ec4a7fc7192a549
9386d6203c19ea2ab6301f0603551d230418301680144c0bb4bc8ca56a0d1643
ee21bb1e7c3dbf66305030130603551d25040c300a06082b0601050507030330
0d06092a864886f70d01010b050003820181002d0db050da36399de8a05cadf7
dbf3309a522c7c10dfdacd5f2538d689a147227dc1aaac7966f978f878c39420
c6ebb006b7dee8f359ad33fed0e3efd4d452448342a32b60b4a970c1f13370e0
f61e45545058aeaa911caf61c01f022770e11bd9f5c339e60b3a2a415b3a5827
dc35dda2515672ef6fdc2bcbe4301524a437636ec3f2da7ddecedd4b93842a27
f563842882b64c3baee82c73c1740cbeb90472e1a59c113a5e9fe72af4f8f5e5
cb8016e2a6db5c1f6ff0a47e1767ce8143955ba391ca97e18c24b4a86f0e6de0
1dfa74baab5f921fe751317ab3bc55892e5a76718a66f85c8b2a587b52f0b54c
8d54fb2122dcc9a52ca7dc81e1bc67304fe96df38f83b39e8ab3a07628a246f3
b19b74f7f7f30cbc4639db12e6807e3c3369952e8fc4ddd19cb048928ac2559b
3a10de43860b69dc2afdb1c2184940e8ceee3641e2e11251f47544b30534afd3
aa5a6bc7a1997042e442faf102d664a292dde70bfb266ed96ae87c0a63064947
fcefa92658e0f2684771c99688d1017a5a1838

Test root certificate, the trust anchor of the configured pair, 1120 bytes (hex):¶

3082045c308202c4a003020102020101300d06092a864886f70d01010b050030
3f313d303b06035504030c346576616c2d72656365697074206d617070696e67
73207465737420726f6f742028505552452054455354204d4154455249414c29
301e170d3236303130313030303030305a170d3335313233313233353935395a
303f313d303b06035504030c346576616c2d72656365697074206d617070696e
6773207465737420726f6f742028505552452054455354204d4154455249414c
29308201a2300d06092a864886f70d01010105000382018f003082018a028201
8100bf2c98f756260c3bdfa487f85009454ed25b4191589b4c6451cf683b69fc
b883f29f710166bf9f0c2a474c340d25fbd5b21514afbf2dfff6333e4f1ab5e1
58e38e5d8eddcd4d883337dc11aae54b0954b94e5b5e41964f4fc600fde25a8c
2406e24940fc5da14862d55fb86a7de2e7477d28d19c56cb4d404da14fd3a464
fe52015f93a504162b87807dc636a7dd2671c64e2eff4307609e12d68a5085f4
d80539bb9599b8aaf83e1abf37ed2671a08034e56c77faf8aa5743767b2dbe56
1e7adc2069164d62214e444799bdacbd6917d2219c83dff5b910ad6256e57302
16eb57fc0021a26e4581a06ded76f0f1c289b67577ba43db6a68c154a01e3512
558f618aac5c738f97b163164a6a76f3b07d48dd9b94fbcdc3a2edbd486cb385
3844e4c04653ae9c2b2060b7802cebb44a8cb918626c6ccb448d96f908579319
63196610d64a4cd2480a12410f3580ac7ceee44316b6930f585dfbe6abfdd0db
288552e03baee551a6c5b697e2537e32156ee66d644522d63640591f69d47cb0
d68d0203010001a3633061300f0603551d130101ff040530030101ff300e0603
551d0f0101ff040403020204301d0603551d0e041604144c0bb4bc8ca56a0d16
43ee21bb1e7c3dbf663050301f0603551d230418301680144c0bb4bc8ca56a0d
1643ee21bb1e7c3dbf663050300d06092a864886f70d01010b05000382018100
678c28e3f30305df549eac036a15ebfdad96843501900ac45dc5a3c632cd94b2
4e80df9ddc63998b354a1e51074cf763937306db4cb2961b2a0eb0f4e37e0301
bdc7dd06240e8ceaa1af908b1f83db81247f61c32166830c539ac6d488b0bced
7fa830c9e5c5d67f35c5f357007ce8cbfe004d210f54b1fd0cf84a240856759b
e99ea4e933f37a818c0dd355faef418350e40818274babc0e35debe3f04507c8
f84bdfd75ffa1f2aea2a440933c9d4d2c58a9b23655ff7783e21728d74c00343
69567e399133d06f5df1a44aa9c245a35d2db598265b9c01f3c9904ca2a43c2c
4ffe4e04459c8fa933be3ca466584673a0a7ad43305f428b82e8f201db81d625
235d4f5a520889a1b59df8e385f05ea617514cb82708361fd18eb942d6c9b1c0
ac1d1c3a00c58e3edf39403d56ee5affcad4faedcb0ebbeaa789b8140c0ea07d
165363808b7cb511eb080aefca268ddf446447dba0d6f472e6f04ec2c422b5b4
24721a7e8c1b792cda88aeef7ce3c6c851012c8c80c10635d7b26d53454b5d89

SHA-256 over the test leaf and over the test root certificate:¶

dafe68bab183c88b167482d58243e1eb99d490b2fac60515903103ec3286d034
dbb5ca149e1c30bb2e14ccdb0b25bcd62db8afc527f7837dc302e4980e50136d

kid of X1, SHA-256 over the SubjectPublicKeyInfo of the test leaf (hex):¶

a17f91f02052b42e799a7b1fc1061fe90f105bccac812a407c0e236005809fba

The protected header of X1 holds these parameters, in this order:¶

• 1 (alg): -7¶

• 4 (kid): the kid above¶

• 15 (CWT Claims): a map with 1 (iss), the identifier above, and 2 (sub), the sub of Appendix A.5¶

• 33 (x5chain): an array of the test leaf and the test root certificate¶

• 258 (payload hash algorithm): -16¶

• 259 (preimage content type): the type, as a text string¶

The unprotected header is the empty map, and the payload is the receipt digest of Appendix A.2.¶

X1 is a COSE_Sign1 with tag 18 in the deterministic encoding of these parts and this signature, ECDSA with SHA-256 over its own Sig_structure under the test leaf key; 2313 bytes.¶

X1, signature (hex):¶

a6c0730a565a1ab3e0a2a490fd18c9d885b317b1ff47d6c4c8ab71b3c5b1d11b
c94e3350ab2edc2ad5b3504d400ef79971f3493e477d6bc44d73fc8b56212c05

Each of X2 to X6 is a COSE_Sign1 with tag 18 whose protected header is the deterministic encoding of the protected header of X1 with the change below, whose unprotected header is the empty map, whose payload is that of X1, and whose signature is given below, ECDSA with SHA-256 over its own Sig_structure, under the test leaf key except for X6, which the other P-256 test key signs.¶

X2: X1 with 1 (alg) -9 in place of -7. Signature (hex):¶

ae307dd37eb66ad7f53885d1bfbb638c60a2d531564414261c8a41c651839c67
2380e33157627c3e41815129a9232464eb8c8981a50ec022bb8302d01825e0e9

X3: X1 without parameter 33 (x5chain). Signature (hex):¶

884255369e0044d654ec7b2adf62df7275d8d7192228fe76c31432016c3ac895
8a40b0108236b4a3e797f6597f1532f1daf552a4f73fa465fd5186c639fc7260

X4: X1 with iss in the form of Section 5.2, whose F is SHA-256 over the test leaf certificate. Signature (hex):¶

1b9cf8ccc06086f9c87dc7cf44eda63a170f52818aab54b28684a28092240946
93f04574344a566777981423c9aa7f918bd092f8fc09c5e5e12b986434391db2

X5: X1 with one more parameter, 16 (typ), the text string "application/cose". Signature (hex):¶

e7f13c54e7ac52cd8080404fe5856da616195652ddfd3386da794388b4231fdb
fc4b232c87b0572dea5ed014619b722d69154c38dc1da1bfd28c87dfab9318f6

X6: X1's protected header unchanged. Signature (hex):¶

a902939e4d89caeae6a5e7f683ffb76c01273d0c4f0f099ebc499f9894064a11
fcb423d6238fd9d93df18a16d2f577b46464afaa1cbfb0bb5b0a6fe85945961b

What each vector shows:¶

• X1: the certificate profile: alg -7, x5chain of the test leaf and the test root, iss a did:x509 identifier that names the test root.¶

• X2: X1 with alg -9 (ESP256) in place of -7, signed again under the test leaf; the Transparency Service of Section 14 refuses it at registration.¶

• X3: X1 without x5chain, signed again under the test leaf: its labels are those of the key profile, and -7 is not an alg value of that profile.¶

• X4: X1 with an iss whose fingerprint names the test leaf certificate and not the test root, signed again under the test leaf.¶

• X5: X1 with one more protected parameter, 16 (typ), signed again under the test leaf.¶

• X6: X1 signed by another P-256 test key; kid and x5chain still name the test leaf.¶

Vector and SHA-256 over its bytes:¶

X1 fcf278cc997cbae6fbc9fa76c7b38da21231ee394c331c3477ea8a7aa060e1df
X2 2322eb9197b41fddbcbc9e68223b3be016111654f4017e77fd046d2e89271721
X3 c6c017fc3c6b1340c10b88c513e06a91c536c928fd0cb0ad350ace733ea139ce
X4 ef7a6ac337943b9bc8984749a3ab5d5bfc8ac33e62b7639220e6ca42a7bec7aa
X5 18fa79f5b6159308994129affcdd9ea9f1b0ebf57dd65d9f77d9423647c29c93
X6 a01501daefafa0c32793612675999e25c83fa8f1d5d5431eb2094727fc01091a

A.9. Transparent Statements

T2 is the Transparent Statement that a local instance of a Transparency Service returned on 2026-10-11 when X1 was registered (see Section 14). It is X1 with one COSE Receipt R under unprotected label 394; nothing else differs from X1. R was made by the service with the key of that test instance and is given here as recorded. Each vector below is a COSE_Sign1 with tag 18 in the deterministic encoding, made of the parts named, and is presented with vector P1 of [RECEIPTS]. The Receiver's configured pairs are the pair of Appendix A.6 and the certificate pair of Appendix A.8. The steps of Section 5.2.2 do not read R.¶

R, 472 bytes (hex):¶

d284588da5013822045840633566393532643661306331653364616537356434
3139313739343064366462366637393938663138303566643639313635356664
31643231353763386432300fa3016e3132372e302e302e313a38303030027673
636974742e6363662e7369676e61747572652e7631061a6acb64c519018b0266
6363662e7631a1647478696464322e3133a119018ca1208158dba2018358200c
1484f4d094e618cfb5f6c65c44ef651006c589c932aaca1d8ba0f441a54d9078
4863653a322e31323a3963363236346130383637653135366330303138363830
6264353832326639343431396632353533353737333933356239376364613038
6666306235383335335820fcf278cc997cbae6fbc9fa76c7b38da21231ee394c
331c3477ea8a7aa060e1df028282f558200b1afcd5a9b3799142e015598e429d
2d5572b686189b3737f9064b27465a548b82f558206e44317d4a8df07c74e928
c3fe66b5e01fd66f0ac6e3406ba7d61d72dfc4158df6586012cda8a3bb20d82c
d3c1e36e428bf18b7b6a4f6e4c63c7c3e84f7fdca13bb4a157e17fd3458dad91
95f1fb540b590a2b067ad16ae5c87e7fe0a205fbe98833c3eee31fdbf6e4f6c9
13df773b799896d6916a03d43142f6d37cd4cb1e19a50b1c

• T1: the protected header, payload and signature of M2; unprotected header {394: [ R ]}.¶

• T2: the protected header, payload and signature of X1; unprotected header {394: [ R ]}.¶

• T3: as T2; unprotected header {4: the kid of X1, 394: [ R ]}.¶

• T4: as T2; unprotected header {394: R}, the byte string not in an array.¶

• T5: as T2; unprotected header {394: []}.¶

What each vector shows:¶

• T1: M2 with the receipt of T2 under unprotected label 394; that receipt is one for X1, and the steps of the checking procedure do not read it.¶

• T2: the Transparent Statement that a local Transparency Service returned for X1: X1 with one receipt under unprotected label 394.¶

• T3: T2 with one more unprotected parameter, 4 (kid), the kid of X1.¶

• T4: T2 with the receipt under label 394 as a byte string and not in an array.¶

• T5: T2 with an empty array under label 394.¶

Vector and SHA-256 over its bytes:¶

T1 241496e7136bf76a26cf916ef868ce172ef1915d18127a6ffacb63cef4290a82
T2 312a7d2a840607d4251c260f815fda0e0e1da8c11b1e5ae125c2927a32fcacbe
T3 5308f2023566dc02ab6039afc85053f79e1a5d85c0358df989d99a8f29734973
T4 cbb701b815313232d111dbfd7653267ef7bdf4fe2134212b231e7e22380279ca
T5 aabfeefa90488172b30c6913db50ab5bdc181e043a0c1202c52d66694567080e

A.10. Agent Evidence Format Vectors

Each vector is presented with the candidates of [RECEIPTS] named in its table; the matching result is that of Section 3.3 after the extraction of the subsection of Section 6 for its format. The result under the neighbouring draft is that draft's own, given for orientation; it does not enter the matching result.¶

7b226261736973223a7b22646967657374223a22303731383265396266663639
6261613861623961353634366436396235313138636366333738306239303362
3961396435623462643064396339643730623837222c226469676573745f616c
67223a225348412d323536222c2274797065223a226170706c69636174696f6e
2f766e642e7369676e65642d65766964656e63652e6576616c2d726563656970
742b6a736f6e227d2c22636f6e74726f6c223a2273757370656e64222c22676f
7665726e6564223a226465706c6f796d656e74206f66206d6f64656c2061636d
652f6d6f64656c2d7840323032362d3039227d

9Z58iP2s9ESi8Oy4aKlBngE797Qy3M1soYQ68rFJGnY
eqr-test-1

7b22636f6e74726164696374696f6e223a226661696c222c226d697373696e67
223a22696e64657465726d696e617465222c2270726f66696c65223a22657661
6c756174696f6e2d67617465642d70726f6d6f74696f6e222c22726571756972
65645f636f6e646974696f6e73223a5b227369676e65645f6576616c75617469
6f6e5f726563656970745f7665726966696564225d2c227374616c65223a2269
6e64657465726d696e617465222c2276657273696f6e223a317d

7b22636c61696d223a226d6f64656c2061636d652f6d6f64656c2d7840323032
362d3039206d6574206163637572616379203e3d20302e383030206f6e206163
6d652d7361666574792d737569746520312e322e30227d

7b22636c61696d223a7b22646967657374223a22396e4275452d5f456564534d
625456795834784b6e7258582d4b6b514f4a686d555f5f596436355f33396b22
2c22686173685f616c67223a227368612d323536222c226964223a2275726e3a
6578616d706c653a636c61696d3a6d6f64656c2d782d6163637572616379227d
2c226576616c756174696f6e223a7b22626c6f636b696e675f636f6e74726164
696374696f6e73223a5b5d2c22726571756972656d656e74735f736174697366
696564223a747275652c22737461747573223a2270617373227d2c2265766964
656e6365223a5b7b22636c617373223a226170706c69636174696f6e2f766e64
2e7369676e65642d65766964656e63652e6576616c2d726563656970742b6a73
6f6e222c22646967657374223a226a4e684a70747a4f434b376a4e4645646579
387878553548694958646f586c6450492d584c644455675277222c2268617368
5f616c67223a227368612d323536227d5d2c22657870697265735f6174223a22
323032362d31302d30325430303a32353a30305a222c226973737565645f6174
223a22323032362d31302d30325430303a31303a30305a222c22697373756572
223a2268747470733a2f2f7175616c69666965722e6578616d706c65222c2270
726f66696c65223a7b22646967657374223a227743504a6234614f5341654352
6e566250567a634d70427355535869647969526b6f546f587a5471367173222c
22686173685f616c67223a227368612d323536222c226964223a226874747073
3a2f2f6578616d706c652e6f72672f70726f66696c65732f6576616c75617469
6f6e2d67617465642d70726f6d6f74696f6e2f7631227d2c2272656365697074
5f6964223a2275726e3a757569643a33663163396132652d376234342d346430
652d396135312d306336653262376438663130222c2276657273696f6e223a22
31227d

878adebdb043bf5f1847ec5ec5f638bf8c84062a3fbfe8607c1384228121c217
4f10bff17ea761f6fadb13470f6be5791c64d1ecb5543b4fb8902eceb307e407

c583493759b300de04c0fe36a9f59333173ee77866618671cf95b05dcd95d587
1d88ef78467b7915101e3ae4ff891907b7f04527f86e42e1c7a4467f3f7a3201

04691c2dc7328c790c83bfc0e2a5b437d19d9e6e8dc18373e0b47ae25ac34f13
ce67ccb94224f878de9cf0e77974c143495c0e6165a02f4f53848e52193eb068
0b

d28459011aa90126044e6169722d746573742d6b65792d310fa2017818687474
70733a2f2f6f70657261746f722e6578616d706c6502716167656e742d70726f
6d6f74696f6e2d31686167656e745f6964716167656e742d70726f6d6f74696f
6e2d316a636861696e5f6861736858206f24488e7024580e8644adfefbaa6207
8866534204a13c1fa6439a39197370616c636f6e74656e745f686173685820ff
d0f00f280920c1ed018268869d7b2870a582e55ecdbf57e26452d0aa2557956f
707265765f636861696e5f686173685820000000000000000000000000000000
00000000000000000000000000000000006f73657175656e63655f6e756d6265
720073616374696f6e5f74696d657374616d705f6d731b000001a118cf4800a0
5904e57b22616374696f6e5f73756274797065223a6e756c6c2c22616374696f
6e5f74696d657374616d705f6d73223a313739313431373630303030302c2261
6374696f6e5f74797065223a22636f6e66696775726174696f6e5f6368616e67
65222c226167656e745f646964223a6e756c6c2c226167656e745f6964223a22
6167656e742d70726f6d6f74696f6e2d31222c226167656e745f76657273696f
6e223a226578616d706c652d6167656e7420312e303b206578616d706c652d6d
6f64656c20323032362d30393b206578616d706c652d6672616d65776f726b20
322e33222c226167656e745f776f726b6c6f61645f6964223a6e756c6c2c2261
7574685f636f6e74657874223a6e756c6c2c2263617074757265645f74696d65
7374616d705f6d73223a313739313431373630303132302c22636f6e73756d65
725f696e737472756374696f6e73223a6e756c6c2c2264656c65676174696f6e
5f636861696e223a6e756c6c2c2265787465726e616c5f72656673223a5b7b22
7265665f73797374656d223a6e756c6c2c227265665f74797065223a22617070
6c69636174696f6e2f766e642e7369676e65642d65766964656e63652e657661
6c2d726563656970742b6a736f6e222c227265665f76616c7565223a22386364
3834396136646363653038616565333334353131643762326633316335346534
3738383835646461313739356433633866393732646430643438313163227d5d
2c22696e7075745f68617368223a223963383065356535326637396331353532
3863353233643766363434623262623761303535333466366661366637343337
613361316538663165633733306532222c22696e7075745f73756d6d61727922
3a6e756c6c2c22696e74656e745f6174746573746174696f6e223a6e756c6c2c
226a7572697364696374696f6e223a224445222c226f70657261746f725f6964
223a2268747470733a2f2f6f70657261746f722e6578616d706c65222c226f70
657261746f725f7075626b65795f6964223a226169722d746573742d6b65792d
31222c226f7574636f6d655f68617368223a2233343161356366346431626237
3732343565666638323037386636383963616363623165663261396239316433
30353135646332313061336330646263336364222c226f7574636f6d655f7374
617465223a22636f6d706c65746564222c226f7574636f6d655f73756d6d6172
79223a6e756c6c2c22706172656e745f7265636f72645f6964223a6e756c6c2c
22706f6c6963795f72656673223a5b5d2c227072696e636970616c5f6964223a
6e756c6c2c22726561736f6e696e675f68617368223a6e756c6c2c227265636f
72645f6964223a2230313932306633652d386130302d376333612d396231652d
346632643663386130623131222c22726564616374696f6e5f72656365697074
73223a5b5d2c22726574656e74696f6e5f636c617373223a226f706572617469
6f6e616c5f317972222c22736368656d615f76657273696f6e223a226169722d
312e30222c2273657373696f6e5f6964223a2230313932306633652d38613030
2d376333612d396231652d346632643663386130623130222c22746f6f6c5f63
616c6c73223a5b5d2c2274726163655f6964223a6e756c6c2c22776f726b666c
6f775f6964223a6e756c6c2c227772697474656e5f74696d657374616d705f6d
73223a6e756c6c7d5840811c2edf8cefb9d82abdfeac70a983f916029e3c5778
269aa546e83e304daba75b0992ed2b4cf9cbe96e259ce8a7a2e56d27098697b2
ee1b73a38b4a1463739d

b433e17925384a304c39e2ab3f21f702283f466109f3f11ea6346057dc59fee1
40d4c11249c4b2a5044126e1f9e8797d309183aa347a89facb9e50ad83646989

Since draft-gruszka-evaluation-receipt-mappings-03

• Section 10 is new. It cites the framing-space measurement [FRAMING-SPACE] and states what the restriction of Section 5.2 leaves of the 64 encodings it measures.¶

• Section 6 is new. It states how records of [ACDE], [EQR] and [AIR] can cite a receipt and what each of those drafts leaves open, and Appendix A.10 gives six vectors. Step 1 of Section 3.3 names the form of the value in the two further carriers.¶

• [RECEIPTS] is cited as revision -04 and [STATEMENT-ID] as revision -03. Section 9 now repeats [RECEIPTS] Section 6 of that revision word for word, with its two further sentences.¶

• [CPB] and [PRML] are normative references because Sections 5.1 and 7 depend on their procedures. [DIDX509] is now informative. [RFC4648] is normative; [RFC8785] is informative.¶

• Section 3.1 takes the text form of the digest from step 1 of Section 3.3. Section 5.1 states the result for input that is not UTF-8 and for a well-formed reference of another type, with the vectors R15 and R16 in Appendix A.7. Section 5.2 writes the form of iss as a concatenation without spaces. Section 5.2.2 and Section 7 pass on the input error of [RECEIPTS] Section 5.¶

• The foreign test key of S4 and S5 has a seed label without a module name; S4 and S5 are signed again with it.¶

• In Appendix A, byte strings that follow from others in this document by a stated construction are given by that construction, their length and their SHA-256: PAE(type, B), the protected header and the Sig_structure of M2, S1 to S8 and X1. A signature that appears nowhere else is given in full. No vector changed except S4 and S5.¶

• The sections that followed Section 5 in -03 are numbered one higher, and those from Section 11 on two higher.¶

• [CPB] is cited as revision -06, and its section numbers follow that revision. Section 5.1 states the pre-image of its digest context and, following [CPB] Section 9.1, gives Unresolved (cause: unimplemented) for a verifier that does not implement the construction, Unresolved (cause: unavailable) if no receipt is obtained, and Failed if steps 1 to 3 of [RECEIPTS] Section 5 fail for the receipt obtained; if processing stops at a resource limit, it gives the resource-limit error of [RECEIPTS] Section 5 instead of a state, and Section 11 does not rely on such a reference. R6 is now Failed; its matching result stays INDETERMINATE. Appendix A.7 assumes a verifier that implements the construction and obtains the candidate, and Section 14 says how the state of R6 was checked and which scripts implement Section 5.1.¶

Since draft-gruszka-evaluation-receipt-mappings-02

• The certificate profile does not admit alg -9 (ESP256). Section 5.2.4 gives the measured reason, Section 14 the measurement, and vector X2 (Appendix A.8) is the statement that was refused.¶

• The Open Items section is removed. The in-toto references stay pinned to release v1.2.0, the draft names of [RECEIPTS] and [STATEMENT-ID] stay as cited, Section 5.1 already says that no profile names its declaration, and Section 5.2 now states the measured reason for retaining the certificate profile's existing limits.¶

• Section 5.1 makes explicit that a byte order mark is not ignored in this JSON representation, and vector R14 illustrates the resulting Malformed state and INDETERMINATE matching result.¶

• This appendix is added.¶

Since draft-gruszka-evaluation-receipt-mappings-01

• Section 5.1 defines the JSON representation of a typed digest reference. Input outside it is Malformed before the other states, member names are compared after unescaping, and repeated names are found before any conversion. The matching rule takes exactly one digest_alg and one digest, both strings, whatever the state.¶

• Vectors R7 to R13 (Appendix A.7) give Malformed inputs and an escaped member name.¶

• Step 1 of Section 3.3 names the form of the value in each carrier.¶

• Section 9 and Section 11 say that a MATCH is not a Verified reference, and [RFC8259] is a normative reference.¶

Since draft-gruszka-evaluation-receipt-mappings-00

• Section 5.2 adds a certificate profile next to the key profile. Its statement carries an X.509 chain in x5chain and a did:x509 issuer and is signed with alg -7, and step 3 of Section 5.2.2 checks it against a did:x509 identifier and trust anchor that the Receiver configured. Vectors X1 to X6 (Appendix A.8) cover it.¶

• Section 5.2.2 checks a Transparent Statement after removing its receipts under label 394 unread, and step 1 fixes the encoding choices that [RFC8949] Section 4.2.2 leaves to a protocol. Vectors T1 to T5 (Appendix A.9) are Transparent Statements, and Appendix A.6 gives a statement for each status other than accepted.¶

• Section 5.1 assigns the states Unresolved and Failed of [CPB] Section 9.1 to typed digest references, with vectors R1 to R6 (Appendix A.7).¶

• Section 9 adds that a receipt does not show where B came from, and Section 11 adds that an accepted status says nothing about registration and that registration alone does not establish that the payload is the receipt digest.¶

• Section 14 records the registration of a statement in the certificate profile with a local Transparency Service and the offline verification of the Transparent Statement it returned.¶