]> b7n0de

Germany kontakt@b7n0de.com

Security evaluation receipt DSSE in-toto SCITT COSE A Signed Evaluation Receipt records one evaluation result as signed payload bytes B. This document describes how existing envelopes cite such a receipt by the SHA-256 digest of B, and how a DSSE envelope carries B with the receipt's own signature. It fixes those bytes and a matching rule, maps the parts of a receipt onto DSSE, the in-toto Statement with the test-result predicate and the SLSA Verification Summary Attestation, shows that the signature of a receipt is already a valid DSSE signature, gives a SCITT Signed Statement that names a receipt only by its digest, in a key profile and a certificate profile, declares the receipt digest as an artifact type for typed digest references, states how three formats for records of agent actions can cite a receipt, and relates a receipt to a pre-run criteria set written in PRML. It defines no new format and no new predicate.

Introduction A Signed Evaluation Receipt (receipt) holds one assertion, whether a threshold held for a metric of a test suite, as payload bytes B. B is signed with Ed25519 over a pre-authentication encoding with a fixed type. A receipt carries no inclusion proof and does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement that names the receipt and verifying the resulting SCITT Receipt (). Other parties will want to refer to a receipt from the envelopes they already use: a DSSE envelope, an in-toto Statement, a SLSA Verification Summary, or a SCITT Signed Statement. This document is the third part of one line of work: asks how a signed statement is named unambiguously, fixes the bytes of a receipt, and this document shows how existing envelopes cite such a receipt by digest. It states how three formats for records of agent actions can cite a receipt (), relates a receipt to a criteria set fixed before the run in PRML (), and says where it meets the requirements of for exchanging evaluation evidence (). This document defines no second receipt format, no new in-toto predicate and no new COSE header parameter. What a receipt does not prove stays unproven when an envelope cites it ().

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The terms receipt, B, Issuer, Receiver and type are used as in . The type is the fixed string The type identifies B ( Section 10.1). The receipt object uses the same fixed string as its schema discriminator, but is a different JSON representation.

Receipt digest:

SHA-256 over B ().

Citation:

A hash algorithm and a digest value that an envelope carries to name a receipt.

Citing envelope:

An in-toto Statement or a COSE Signed Statement that carries a citation. A DSSE envelope carries B itself, not a citation ().

The Receipt Digest

Definition The receipt digest is SHA-256 over B, the payload bytes of the receipt as defined in Section 3.4: the bytes that steps 1 to 3 of 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 fixes for its carrier; one that carries it as bytes uses the 32 bytes. This document defines no other hash algorithm.

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 ( 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 are three different receipt byte strings that all verify and all carry the same B (cases C1 to C3 of ). 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 () 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.

Matching Rule Given a citation and a candidate receipt, the result is computed as follows. For the JSON representation in , 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 , -16 as the value of COSE header parameter 258, and sha-256 as the algorithm label of the examples (); 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 (), an evidence descriptor of names it sha-256 in hash_alg (), and in an ExternalRef of , which carries no algorithm, the type as ref_type names it (). The value is 64 lowercase hexadecimal digits in text form in a digest set (), in a typed digest reference (), in an ExternalRef () and in the examples (); it is the base64url encoding without padding of Section 5 of , 43 characters, in an evidence descriptor (), 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 (). 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 , 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 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 Section 5 under a key it fixed. Case C5 is a candidate that matches and fails that procedure at step 11. Citation cases

Case	Candidate	Result	Verification of the candidate	What it shows
C1	P1	MATCH	PASS	the receipt the citation was made from
C2	P4	MATCH	PASS	other receipt bytes (an escaped character in schema), same B
C3	P6	MATCH	PASS	other receipt bytes (no key hint), same B
C4	P2	NO_MATCH	PASS	another receipt with another B
C5	N7	MATCH	FAIL, step 11 (profile 4)	same B, signature made over another type: a match is not a verification
C6	N13	INDETERMINATE	FAIL, step 3	payload_b64 is not canonical base64: B is not obtained
C7	N14	INDETERMINATE	FAIL, step 1	the receipt has duplicate member names: B is not obtained
C8	P1	INDETERMINATE	PASS	the citation names an algorithm this document does not define

Against the Identification Requirements 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 Section 5 obtain it from payload_b64) and the encoding (the text form that step 1 of fixes for each carrier, or 32 bytes). 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 Section 5 succeeding: the receipt's whitespace and escapes, its key hint, and its signature value. In the terms of 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 the citation is read from header parameters 258 and 259 and the payload, as 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.

Mapping to Existing Envelopes shows, for each part of a receipt, where it has a place in three envelopes and what that envelope does not have: DSSE , the in-toto Statement v1 with the test-result predicate v0.1 (test-result in the table), and the SLSA Verification Summary Attestation v1 (VSA). "None" means that the envelope has no field for it. This document defines no predicate of its own. Receipt parts in three envelopes

Receipt part	Envelope	Field there, or what is missing
B	DSSE	payload, base64 of B
	test-result	none; a Statement that restates the members is other bytes
	VSA	none; inputAttestations[].digest names B by its digest
type	DSSE	payloadType
	test-result	none; the Statement's envelope carries an in-toto type
	VSA	inputAttestations[].mediaType
signature.sig	DSSE	signatures[].sig, the same bytes (vector M1)
	test-result	none; the Statement's envelope carries a new signature
	VSA	none; the VSA is signed by its verifier
signature.alg	DSSE	none; DSSE names no signature algorithm
	test-result, VSA	none
signature.key	DSSE	keyid, optional and not signed
	test-result, VSA	none
passed	DSSE	inside B
	test-result	result PASSED or FAILED; WARNED has no receipt counterpart
	VSA	none; verificationResult is the verifier's result
payload schema	DSSE	inside B
	test-result	none; predicateType names test-result, not the payload schema
	VSA	none
suite, suite_version	DSSE	inside B
	test-result	no field of its own; configuration or url can name the suite
	VSA	none
metric, comparator, threshold, score, n	DSSE	inside B
	test-result, VSA	none
criteria_digest, when present	DSSE	inside B
	test-result, VSA	none
model_id_commit, dataset_id_commit, commit_alg	DSSE	inside B
	test-result	none; subject wants a digest of the artifact, and a commitment is not one
	VSA	none; subject and resourceUri name the verified artifact
timestamp	DSSE	inside B
	test-result	none
	VSA	none; timeVerified is the verifier's time

In the other direction, a receipt has no counterpart for the required VSA fields verifier, resourceUri, policy and verifiedLevels, for its optional timeVerified, or for the subject of an in-toto Statement.

DSSE The signature of a receipt is a valid DSSE signature without any new signature. DSSE signs PAE(payloadType, payload) with the same pre-authentication encoding that Section 4.1 defines. The envelope , "payload": , "signatures": [{"sig": }]} ]]> therefore verifies as DSSE under the Issuer's key when payloadType is exactly the type and payload decodes to B. Vector M1 () gives the bytes; its signature is the signature of vector P1 of , 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 Section 3.1, and runs 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 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.

in-toto Statement with test-result The test-result predicate records result (PASSED, WARNED or FAILED), configuration (a required list of resource descriptors), url, and the lists passedTests, warnedTests and failedTests. A 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 . 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.

SLSA Verification Summary A Verification Summary Attestation states that a verifier verified an artifact against a policy. Its inputAttestations is a list of resource descriptors , 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 Section 5, cites the receipt there; the artifact itself is the VSA's subject: "}, "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 ) can be the input of a VSA whose verificationResult is PASSED, when the verifier's policy asks only for a valid receipt.

COSE and SCITT A Signed Evaluation Receipt is not a COSE Receipt. Its format is JSON with Ed25519 over PAE, not COSE; it carries no inclusion proof, and no Transparency Service or Registration Policy takes part in making it. In SCITT, a Transparency Service registers a Signed Statement and returns a COSE Receipt proving its inclusion. Two existing constructions carry the receipt digest without a new field: a typed digest reference () and a Signed Statement whose payload is the digest (). Both name the receipt; neither carries it.

A Typed Digest Reference 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 ( 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 ( Section 9.1);
• the canonicalization algorithm is as-transmitted ( Section 5.4), with the byte-boundary selector Section 3.4, "The Bytes B";
• the pre-image is B as defines it, the bytes that steps 1 to 3 of 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 Section 9.3 it is a text string.

For the JSON representation defined here and used in , a reference is one JSON object 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 ( Section 4). A byte order mark before the JSON text is not part of the JSON grammar, so such input is Malformed, although Section 8.1 allows a parser to ignore it. Input that is not UTF-8 is Malformed as well ( 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 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 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 . For a well-formed reference, context selection and verification follow 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 ( 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. 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 Section 5. If no receipt is obtained, the reference is Unresolved (cause: unavailable), and the matching result is INDETERMINATE, as in step 2 of . 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 ( Section 9.1). If those steps stop at a resource limit, the verifier reports the resource-limit error of Section 5 instead of a state, as in . 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 () 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 ( Section 9.5).

A Signed Statement that Cites a Receipt A Signed Statement that cites a receipt is a COSE_Sign1 with CBOR tag 18 in the form of a COSE Hash Envelope . 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 whose last certificate is a trust anchor that the Receiver has configured for a did:x509 issuer . The labels of the protected header select the profile (step 2 of ). Vector M2 () 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) : 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 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 , or -8, EdDSA . A party that makes a statement MUST write -19. A Receiver MUST accept both values and applies every other check of 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 ();
• 4 (kid): the COSE Key Thumbprint 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 ( 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 ( Section 2.1); the signature is r and s, 32 bytes each, under the P-256 public key of the leaf certificate ();
• 4 (kid): SHA-256 over the DER encoding of the SubjectPublicKeyInfo of the leaf certificate, a byte string of 32 bytes;
• 15 (CWT Claims): iss is a did:x509 identifier 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) : an array of exactly two byte strings, each a DER-encoded X.509 certificate : 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, ).

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

Making a Statement A party makes a statement for a receipt only after the receipt has passed the verification procedure of Section 5 under a key that party fixed. A receipt that fails it gives no statement. The party computes the receipt digest over B, takes sub from the model_id_commit of B, writes the protected header of one profile, signs the Sig_structure of Section 4.4 with an empty external_aad, under the statement key in the key profile and under the private key of the leaf certificate in the certificate profile, and encodes the COSE_Sign1.

Checking a Statement The Receiver holds the statement, a candidate receipt, its independently selected receipt verification key, and configured pairs. A pair for the key profile is an issuer URI with an Ed25519 statement key; a pair for the certificate profile is a did:x509 identifier with a trust anchor certificate. The received iss value does not establish either association. It applies the following steps in order. The first step that fails gives the status named in it, and the statement is refused; only a statement that passes every step is accepted. A Receiver that stops because it reached a resource limit, in any step, reports a resource-limit error; that is no status, and the statement is not accepted.

1. If the bytes are not one CBOR data item in the deterministic encoding, if the item is not a COSE_Sign1, or if its protected header is not a map in the deterministic encoding, the status is malformed. A data item that is well-formed but not valid under Section 5.3.1, such as a text string that is not valid UTF-8 or a map with duplicate keys, is malformed; two keys are duplicates only when they are equal under the key equivalence of Section 5.6.1, so the integer 1 and true are two keys and 0.0 and -0.0 are one. For the choices that Section 4.2.2 leaves to a protocol, step 1 uses these: a NaN is in the deterministic encoding only as the half-precision quiet NaN 0xf97e00, and any other encoding of a NaN is malformed; no tag, the bignum tags 2 and 3 included, adds a rule of its own. Step 1 does not check whether the content of a tag inside the COSE_Sign1 is valid for that tag ( Section 5.3.2); the data items inside a tag are checked like any other data item. For step 1, the COSE_Sign1 check concerns only the outer tag, the four-element array and its element types: a wrapping in a CBOR tag other than 18 is not a COSE_Sign1 and is malformed, and an otherwise valid COSE_Sign1 without a tag goes on to step 2 and is outside_profile there. The protected-header byte string is decoded as a CBOR map, with the empty byte string treated as an empty map ( Section 3), which fails in step 2. CBOR validity and deterministic encoding are checked before step 2. Header label types are checked only in step 2; a header label that is not a label of either profile gives outside_profile if step 1 succeeds.
2. A Transparent Statement carries COSE Receipts in its unprotected header under label 394. If the unprotected header holds label 394 and no other label, and the value of 394 is an array of one or more byte strings, the Receiver removes label 394 and applies the rest of this step and the following steps with the empty unprotected header; the protected header, the payload and the signature stay as they are. These steps do not read the receipts. The labels of the protected header select the profile: exactly the integer labels 1, 4, 15, 258 and 259 select the key profile, and exactly the integer labels 1, 4, 15, 33, 258 and 259 select the certificate profile. If the item is not tagged 18, the unprotected header is not empty, or the labels select neither profile, the status is outside_profile. In both profiles, kid is a byte string of 32 bytes; 15 is a map with exactly the integer labels 1 (iss) and 2 (sub), both text strings; 258 is the integer -16; and 259 is the type as a text string. In the key profile, alg is the integer -19 or -8, and iss is an absolute URI. In the certificate profile, alg is the integer -7, iss has the syntactic form given in , and x5chain is an array of exactly two byte strings. This step checks only the syntax of iss and the container form of x5chain; the certificate contents, key properties, and the bindings of iss and kid are checked in step 3. A violation of these structural rules, a detached payload, a payload that is not 32 bytes, or a signature that is not 64 bytes gives outside_profile. sub MUST match sha256: followed by exactly 64 lowercase hexadecimal digits; otherwise the status is outside_profile. Step 7 compares sub byte for byte with model_id_commit of B.
3. Key profile. A configured pair counts only if its statement key is 32 octets and its point A meets rules 1 and 2 of Section 4.4: A is a canonical encoding of a point of order L. A point of small order or of mixed order does not count. If no configured pair that counts has both an issuer URI exactly equal to iss and a statement key whose SHA-256 COSE Key Thumbprint equals kid, the status is untrusted_key. Subsequent signature verification uses only keys selected by this pairwise match. Certificate profile. A configured pair counts only if its identifier is exactly equal to iss, its trust anchor certificate is byte for byte the second certificate of x5chain, and F of iss is SHA-256 over that certificate. The status is untrusted_key if no configured pair counts, or if any of the following does not hold: both certificates are DER-encoded X.509 certificates; the public key of the trust anchor is an RSA key with a modulus of at least 2048 bits; the leaf certificate is signed by that key with sha256WithRSAEncryption; the issuer name of the leaf certificate is byte for byte the subject name of the trust anchor; the extended key usage of the leaf certificate contains O of iss; the public key of the leaf certificate is a P-256 key; and kid is SHA-256 over its SubjectPublicKeyInfo. This step is not certification path validation ( Section 6) and does not resolve iss as a DID: it evaluates no validity period, revocation status, name constraint, certificate policy or other extension. requires path validation for resolution. An application that additionally performs path validation reports its result separately from the status of this procedure and may refuse to use a statement whose status is accepted.
4. Key profile. If the signature does not meet the four rules of Section 4.4 under a key that step 3 selected, with the Sig_structure of Section 4.4 in place of PAE(type, B) in rule 4, the status is signature_invalid. Certificate profile. Read r and s as unsigned big-endian integers from the first and the last 32 bytes of the signature. If r or s is not in the range 1 to n-1, where n is the order of the P-256 base point, or the signature is not a valid ECDSA signature with SHA-256 over the Sig_structure under the public key of the leaf certificate, the status is signature_invalid.
5. Run the verification procedure of Section 5 under the Receiver's receipt key. Continue to step 6 only if it returns PASS. If it returns FAIL, the status is receipt_not_verified. If it stops with a resource-limit error, or with the input error of Section 5 because the receipt key is not 32 octets, propagate that error and stop without accepting the statement.
6. If the payload is not the receipt digest of the candidate, the status is digest_mismatch.
7. If sub is not the model_id_commit of B, the status is subject_mismatch.

If every step passes, the status is accepted. Vector M2 with vector P1 of is accepted, and gives a statement for each other status. Vector X1 with P1 is accepted under the certificate pair of , and X2 to X6 fail at steps 2, 3 and 4 in the certificate profile. Vectors T1 to T5 () are Transparent Statements: T1 and T2 are accepted, and T3 to T5, whose unprotected headers hold more than the receipts or the receipts in another form, are outside_profile. Steps 1 to 4 do not use the receipt. For the key profile, a general COSE verifier that implements the statement's alg value checks the signature under the rules of its own Ed25519 implementation, which can accept a signature that step 4 refuses, for example one whose R is a point of small order. For either profile, a COSE signature check alone does not apply steps 5 to 7, and its success does not show that the statement cites a receipt that verifies.

What Crosses and What Is Lost What a Signed Statement carries of a receipt

Receipt	Signed Statement
B	only its receipt digest, as the payload
model_id_commit of B	sub (2) of the CWT Claims
the type	parameter 259
the other members of B (schema, suite, suite_version, metric, comparator, threshold, score, passed, n, dataset_id_commit, commit_alg, timestamp), including criteria_digest when present	not carried; named only through the digest
the receipt's signature and its key hint	not carried
(none)	iss, kid, alg and, in the certificate profile, x5chain: the statement of the party that signs it

A Receiver that relies on the assertion of a receipt needs the receipt itself; the statement only names it.

Choice of alg In the key profile, value -19 is the fully specified Ed25519 identifier of , which sets the polymorphic EdDSA identifier -8 of to Deprecated. A party that makes a statement therefore writes -19 only. Every Receiver accepts -8 as well, for statements made before a producer moved to -19 and for general COSE verifiers that implement -8 but not -19 (), so that one statement gives one status. -8 names EdDSA for any curve; step 3 of counts only Ed25519 statement keys, so a statement with -8 under any other key is untrusted_key. Vector S1 () is M2 with alg -8, signed again under the same key; it is accepted. The certificate profile fixes -7. also sets -7 to Deprecated and registers -9 (ESP256) for ECDSA with SHA-256 on P-256. The certificate profile does not admit -9: the Transparency Service measured in refuses a statement with -9 at registration, also when its configuration names ESP256, and neither the offline verifier nor the two general COSE libraries named there implement -9. A statement with -9 is outside the certificate profile (vector X2). -7 does not name a curve; step 3 counts only a P-256 leaf key, so -7 selects one signature algorithm here. The payload follows the pattern of the hash-only mode of : the 32 raw octets of a SHA-256, carried as a byte string and not as hexadecimal text. That profile leaves open how a verifier tells such a payload from a full one, and names a COSE header parameter that declares the digest algorithm as one candidate. Header parameters 258 and 259 of , used here, are such a declaration.

Citations in Agent Evidence Formats Three individual drafts define records about the actions of software agents. Each subsection below states, for one of them and only from the revision it names, where its record can carry a citation of a receipt, in which form, and what that revision leaves open. A citation names B (). The verification that a neighbouring format defines for its own record shows nothing about the receipt: a Receiver that relies on the receipt runs Section 5 under a key it fixed. The vectors are in .

Control Delivery Evidence (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 () 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 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 to the typed digest reference that is the value of the citing member of the instruction; the rule of that takes digest_alg and digest from a top-level object applies to that value. The matching result does not change a disposition of , and a disposition does not change the matching result. Open in -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 , 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 writes sha-256:<digest> and fixes no encoding of the digest).

Evidence Qualification Receipts (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 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 (step 5 of 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 (); an EQR profile that admits receipts as evidence is where that choice would be stated. Matching applies to hash_alg and digest of the descriptor. An EQR that is valid under Section 8 of and qualifies under its Section 8.1 shows nothing about the cited receipt, and the two results stay apart. Open in -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.

Agent Interaction Records (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 (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 ). Matching applies 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 is VERIFIED in the sense of that document, which shows nothing about the cited receipt. Open in -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 Section 4.2.1), and how the text operator_pubkey_id becomes the byte string kid (the vectors use its UTF-8 bytes).

Criteria Sets in PRML PRML serializes an evaluation claim fixed before the run: a metric, a comparator, a threshold, a dataset content hash and a seed, in canonical YAML whose SHA-256 is the manifest hash. A receipt records one result after the run. A receipt names a criteria set at most through its optional criteria_digest ( Section 3.5). When the criteria set is a PRML manifest, the bytes that PRML fixes for it are its canonical bytes, whose SHA-256 is the manifest hash, and criteria_digest over them is sha256: followed by the manifest hash. maps the members of a PRML manifest, version 0.1, onto a receipt. A PRML manifest and a receipt

PRML	Receipt	Lost or changed
version	none	which PRML rules apply
claim_id	none	the claim and its amendment chain; only one manifest is named, by criteria_digest
created_at	none	timestamp is when the Issuer states the evaluation ran, not when the criteria were written
metric	metric	nothing when the string is copied exactly
comparator	comparator	== has no counterpart; such a claim has no receipt
threshold	threshold	a number becomes a decimal string; the rule below compares values
dataset.id, dataset.hash	dataset_id_commit	the content hash; the receipt commits to an identifier with a salt, not to the content
seed	none	the seed
producer	none	the producer; the receipt names no issuer, the Receiver fixes the key
model	model_id_commit	the clear identifier; checking an opening requires the salt and identifier
prior_hash, metric_args, code, notes	none	all of them
none	suite, suite_version, score, passed, n, timestamp	a manifest has no result

A Receiver that holds a receipt and a PRML manifest compares them as follows and reports the two results separately.

1. Run the procedure of Section 5 under the Receiver's receipt key. Continue only if it returns PASS. If it returns FAIL, do not perform the comparison. If it stops with a resource-limit error, or with the input error of Section 5 because the receipt key is not 32 octets, propagate that error and stop without reporting binding or agreement results.
2. The manifest is canonicalized as Section 3 requires, and its manifest hash is computed. A manifest that PRML rejects is not compared.
3. Binding. The result is BOUND when the receipt carries criteria_digest and it equals sha256: followed by the manifest hash, and UNBOUND otherwise.
4. Agreement. The result is AGREE when metric is the same string in both, comparator is the same and is not ==, and the receipt's threshold and the manifest's threshold are the same decimal number, the manifest's value read as the decimal that its canonical rendering denotes (so 0.8 in the manifest and 0.800 in the receipt agree, and 0.80000000000000001 in the receipt does not). Otherwise it is DIFFER.

BOUND says that the Issuer states this result belongs to that manifest; AGREE says that the two documents state the same metric, comparator and threshold. Neither result shows that the manifest existed before the run, which needs a time-anchored record of the manifest, such as a registration under , and evidence of when the run began. Neither shows that the dataset with the manifest's content hash was the one evaluated, or that the seed was used.

Relation to Claim-Preservation Requirements states format-neutral requirements for converting and consuming evaluation evidence. This document addresses parts of these requirements for the conversions it describes; the correspondences below are not a conformance claim. and name what each envelope or document loses, in the sense of its requirement R-CP-9. gives INDETERMINATE when B cannot be obtained or the algorithm is unknown, never a match (R-CP-8, R-CP-10). keeps the result of a verifier or of a registration apart from the receipt's passed, and claims no order of criteria and run (R-CP-5, R-CP-11). It does not meet the requirements on coverage and attempts (R-CP-6) or on records of a mapping instance (R-CP-1): a receipt has no field for them, and this document defines none.

What Is Not Proven The list of Section 6 applies unchanged to a cited receipt. It is repeated here word for word; its one cross-reference is written as a reference to Section 5 of . Verification establishes that the receipt passes the format, consistency and signature checks in Section 5 of 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.

Each envelope adds what it does not prove:

• A citation. A MATCH does not show that the candidate verifies, who signed it, or that its assertion is true (case C5). The digest names B; it names neither a signature nor a key.
• DSSE. A successful DSSE signature check authenticates PAE(type, B) under the selected key. A receipt verdict additionally requires the verification profile and all checks of Section 5. The unauthenticated keyid is only a key-selection hint.
• in-toto test-result. A Statement that restates a receipt is the statement of its signer. It does not show that a receipt exists, and its result does not show that the receipt's passed is true; both are statements.
• SLSA VSA. A VSA shows that its verifier states that it verified its subject under its policy, with the cited receipt among its inputs. verificationResult is not passed, and the VSA does not make the receipt's assertion true. The digest in inputAttestations names B, not the signature or the key the verifier used.
• SCITT Signed Statement and COSE Receipt. The Hash Envelope carries only the digest. Its registration shows that a Transparency Service registered a statement naming that digest under its Registration Policy. It does not show that a receipt with that B exists or that it verifies, and sub binds nothing beyond the commitment it repeats.
• Typed digest reference. A Verified reference shows that the cited bytes are B, nothing about the signature, the key or the assertion. A MATCH alone does not establish that the reference is well formed or that its digest context has been resolved.
• PRML. BOUND and AGREE () do not show that the criteria were fixed before the run.

No envelope in this document carries sample data: a receipt commits to no sample result ( Section 6), and a citation names only B.

Related Work measures the CBOR framing space of one COSE_Sign1 object under six encoding freedoms: with or without tag 18, definite or indefinite length for the outer array and for the unprotected header map, and whole or chunked byte strings for the protected header, the payload and the signature. It reports 64 distinct octet sequences that share one Sig_structure, and so one signature, while each has its own digest over the transmitted octets. It notes that the core deterministic encoding of Section 4.2.1 excludes five of these freedoms and leaves the choice between the tagged and the untagged form. The Signed Statement of is restricted in both respects: the whole COSE_Sign1, its protected header included, is in the core deterministic encoding, and step 2 of requires tag 18. For a statement whose header contents, payload and signature bytes are fixed, one of the 64 combinations therefore remains. A digest over the transmitted octets and a digest over the Sig_structure still identify different objects: in the certificate profile one statement can have more than one byte string (), each with its own digest over the transmitted octets and all with one Sig_structure. This document names a receipt by the digest of B () and defines no identifier for a statement that cites it.

Security Considerations This section follows the guidance of . The attacker can read, create, modify, replay and reorder receipts and citing envelopes, and controls every input except the Receiver's choice of verification key. Collisions. A citation names B only as well as SHA-256 resists collisions and second preimages. Signer not bound. The receipt digest does not name a key. An attacker who signs the same B with its own key produces a receipt that matches every citation of B. It fails verification under the Receiver's key (). Signature reuse across envelopes. By design the signature of a receipt is a valid DSSE signature under payloadType equal to the type (). A DSSE consumer that accepts that payloadType holds the B and the signature of a receipt, and applies Section 5 before it relies on them. Under any other payloadType the signature is expected to be invalid (). It is not a COSE signature, because COSE signs a Sig_structure and not PAE. Digest confusion. For one receipt, the receipt digest, the SHA-256 of the receipt bytes and the SHA-256 of a DSSE envelope are three different values. A Receiver compares only the receipt digest with a citation. lists the first two for vector P1 and the third for M1. The type identifies B, but a receipt object carries the same string as its schema: a Receiver that fetches a receipt object for a citation takes B from it by steps 1 to 3 of Section 5 and compares the digest of that B, never the digest of the object. Algorithm. Only SHA-256 is defined. A citation with another algorithm gives INDETERMINATE (case C8), so it cannot be satisfied by a weaker digest. Reference parsing. For the JSON representation in , duplicate detection precedes any conversion that could discard member names. Selecting a first or last occurrence can change the reference state or matching result. A MATCH is not a substitute for Verified: a Malformed, Unresolved or Failed reference is not relied on as evidence of a content binding ( Section 9.1), and neither is a reference whose processing stopped at a resource limit. Receipts not read. Step 2 of removes the receipts of a Transparent Statement without reading them; vector T1 carries a receipt made for another statement and is accepted. An accepted status therefore says nothing about registration. A Receiver that relies on registration verifies each receipt under with a Transparency Service key that it fixed itself. It fixes the key, not the issuer name in the receipt: two instances of a Transparency Service can carry the same issuer name and differ only in their keys (). Digest not checked by registration alone. The Signed Statement carries a digest, not B. Registration under a Transparency Service's policy does not by itself establish that the payload equals SHA-256 over B; records the registration of a statement whose payload was not that digest. The Receiver recomputes the receipt digest in step 6 of . Configured trust. A Receiver trusts a statement key or a trust anchor because it configured it. In the certificate profile, the procedure checks the leaf under the configured anchor but evaluates no validity period or revocation status. A compromised leaf key can therefore continue to pass this procedure while the configured pair remains. Additional path validation or other acceptance policy can refuse its use separately. Removing a configured pair makes statements that would pass step 2 and whose only matching pair was removed fail at step 3 with untrusted_key.

Privacy Considerations The receipt digest lets anyone who holds a candidate B confirm it. B carries salted commitments, so B cannot be guessed without them; a party that knows them can test guesses for the remaining members, such as score and threshold. A citation registered with a Transparency Service publishes the digest for as long as that service keeps its log. The sub of M2 repeats the model commitment of B in clear; registered, it links every receipt and statement that commit to the same model identifier with the same salt ( Section 9). The same holds for a criteria_digest that a receipt carries.

IANA Considerations This document has no IANA actions.

Implementation Status This section records the status of known implementations at the time of writing, following , and is to be removed before publication. The examples of were produced by a generator script whose two runs are byte-identical, and checked by a separate script that re-derives every value of Appendices A.1 to A.9 from the bytes, except the vectors R15 and R16 added in this revision and the state of R6, which this revision changes: the match result of every case, with its own implementation of steps 1 to 3 of Section 5; the status of M2, of every status vector and of every certificate-profile vector, with its own implementation of the steps of in both profiles; and the state and the matching result of each of R1 to R14, the state of R6 aside, with its own implementation of the rules of . R15, R16 and the state of R6 were checked against the text of by a separate checker written from this document and the documents it cites alone. An implementation of both directions of the key profile of , the open-source package proofbundle (module receipt_cose, experimental), reproduces M2 byte for byte from vector P1 of and returns each status of for a set of 49 statements and 6 receipts. M2 and the status vectors other than S4 and S5 of are, byte for byte, statements of that set, made independently by the generator of . It writes -19 only and reads -8 only under an Ed25519 statement key. Measured on 2026-10-08 with these pinned versions: pycose 1.1.0 (with cbor2 5.9.0) and go-cose v1.3.0 verified the statement with alg -8, refused the same statement with one signature bit changed, and reported alg -19 (vector M2) as an unknown algorithm; microsoft/scitt-verifier 0.4.0 evaluated the signature of neither statement (its result for both was cannot-evaluate, with the statement signature not evaluated). The certificate profile and the typed digest references of are implemented only by the scripts named in this section. Registration with a Transparency Service was measured on 2026-10-10 with a local instance of microsoft/scitt-ccf-ledger at commit 00101f76 (CCF 7.0.17, virtual mode); no hosted service took part. No statement in the exact form of the key profile was registered: the service refused its https issuer ("CWT_Claims issuer is unsupported") with alg -19 and with alg -8, and, under a did:x509 issuer with x5chain, refused alg -19 ("COSE algorithm -19 is not supported") and an Ed25519 key with alg -8 ("Unsupported key type"). A statement in the form of the certificate profile, with an RSA-3072 test root, a P-256 test leaf and alg -7, was registered, and microsoft/scitt-verifier 0.4.0 verified the Transparent Statement it returned offline, with the network unavailable, under a policy that fixed the receipt issuer, the statement issuer and the statement subject and compared the payload with SHA-256 over B. On 2026-10-12 the same service, built again at commit 00101f76 and configured for the test root, registered X1 again and refused X2, which is X1 with alg -9 signed again under the test leaf, with "COSE algorithm -9 is not supported", also when ESP256 was named among its accepted algorithms; its source at that commit and at commit d68579b5, the head of its main branch inspected that day, maps no -9. pycose 1.1.0 and go-cose v1.3.0 refused -9 as an unknown algorithm before verifying, and the source of microsoft/scitt-verifier at commit bd6fb8ba (package version 0.4.0) maps no -9 for the statement signature. The steps of , applied on 2026-10-11 to the registered statement under the certificate pair of its test root, give accepted, and so they do for the Transparent Statement that the service returned for it. In the earlier registration and offline-verification measurement, the service registered a statement whose payload was not SHA-256 over the B it named, and two local instances of the service carried the same receipt issuer name (127.0.0.1:8000) and differed only in their service keys. microsoft/scitt-verifier 0.4.0 reported a receipt taken from another entry, a receipt with one byte changed and a receipt of the other instance as cannot-evaluate (exit status 3), not as untrusted (exit status 1); this document maps no verdict of another tool to a status of . scitt-verifier 0.4.0 did not anchor a chain whose leaf certificate was signed with ECDSA (exit status 3) and verified the chain with an RSA root. Vector T2 is the Transparent Statement that a local instance of the same service returned on 2026-10-11 for X1: X1 with one receipt under label 394, byte for byte. The signature of M2 (alg -19) is checked from the text alone, without a COSE library: a script written from the texts of this document and of builds the Sig_structure by hand and verifies the signature over it with a general Ed25519 implementation (its checks M2-17 and M2-18). The vectors of were made by a generator script from the texts named in . Two of the three families were run, on 2026-10-25, through readers of the drafts concerned that were written separately from the generator, each from the text of its draft alone. The two readers named here are kept in the proofbundle repository on branches other than main; their run on these vectors is not recorded there, and the readers' run records in those commits are of earlier runs over their own vectors. A reader of at commit 6388f20201b9cb210e97e9d640f5fb74d3424b27 on the branch feat/⁠interop‑acde01‑reads‑abak‑02 gives CONFIRMED for both obligations of A1, and CONFIRMED for EP-A and SUBSTITUTION for EP-B in A2; a reader of at commit 834796d306290c3215967eee43ae30db42554cb7 on the branch feat/⁠interop‑eqr00‑reader finds W1 valid and qualifying, and W2 invalid for the form of its digest. For V1 and V2 no implementation of other than the generator's own check of its Section 5.8 was run.

References Normative References Secure Systems Lab in-toto project in-toto project in-toto project OpenSSF SLSA project n.d. Informative References in-toto project in-toto project

Examples The values below are derived from vectors of (P1, and the candidates named in and ) and from the issuer test key of that document, whose seed is given there; the issuer URI of the Signed Statement is a constant of this example. PURE TEST KEY. It MUST NOT be used for anything real.

Constants Type: Issuer test key, public key (base64 and hex): Issuer URI of the Signed Statement (iss):

Digests of Vector P1 B, 458 bytes (hex): Receipt digest, SHA-256 over B: SHA-256 over the receipt bytes of P1; not the receipt digest:

Citation Cases Every case cites B of P1. Cases C1 to C7 cite, with the algorithm sha-256, the receipt digest given in . C8 cites, with the algorithm sha-512, this value over the same B: The candidates are the vectors of named in , whose bytes are given there. Case and SHA-256 over the candidate's receipt bytes: The expected results are those of ; 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 Section 5 fails.
• C7: B not obtained, step 1 of Section 5 fails.
• C8: Citation algorithm not defined.

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 Section 4.1: 522 bytes, SHA-256 6ffed54e62fa5d5e37830be8435f44466a4016013049b6f3307b6adef909aecc. Envelope, 806 bytes (hex): SHA-256 over the envelope bytes; not the receipt digest:

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 , 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): sub, the model commitment of B: 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 . Sig_structure (ToBeSigned) of 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): SHA-256 over the COSE_Sign1 bytes:

Status Vectors Each vector is a Signed Statement presented with a candidate receipt of , 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 with the issuer test key. With M2, the vectors give one statement for each status of ; S1 is the statement with alg -8 that every Receiver accepts (). Status vectors

Vector	Candidate	Status	First failing step
M2	P1	accepted	(none)
S1	P1	accepted	(none)
S2	P1	malformed	1
S3	P1	outside_profile	2
S4	P1	untrusted_key	3
S5	P1	signature_invalid	4
S6	N7	receipt_not_verified	5
S7	P1	digest_mismatch	6
S8	P1	subject_mismatch	7

What each vector shows:

• M2: the statement of , 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 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): 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): S3, signature (hex): S4, signature (hex): S5, signature (hex): S7, signature (hex): S8, signature (hex): Vector and SHA-256 over its bytes:

Typed Digest References Each vector supplies an input to the typed digest reference processing of . R1 is a JSON object with exactly three members: type, the type; digest_alg, SHA-256; and digest, the receipt digest of as 64 lowercase hexadecimal digits. Each other vector is R1 with the change in ; "names B of P2" means SHA-256 over B of vector P2 of , as 64 lowercase hexadecimal digits. The candidate is the vector of named in the table. For State, assume a consuming profile that accepts the declaration in , 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 Sections 4 and 9.1. Matching rule is the independent result of , including the JSON extraction rule in . Typed digest references

Vector	Change to R1	Candidate	State	Matching rule
R1	(none)	P1	Verified	MATCH
R2	purpose evaluation added	P1	Unresolved	MATCH
R3	digest_alg sha-256	P1	Failed	INDETERMINATE
R4	digest in uppercase	P1	Failed	INDETERMINATE
R5	digest names B of P2	P1	Failed	NO_MATCH
R6	(none)	N13	Failed	INDETERMINATE
R7	member x added, value 1	P1	Malformed	MATCH
R8	second digest member, names B of P2	P1	Malformed	INDETERMINATE
R9	digest_alg removed	P1	Malformed	INDETERMINATE
R10	R1 as the only element of a JSON array	P1	Malformed	INDETERMINATE
R11	purpose added, value null	P1	Malformed	MATCH
R12	sole digest name written as "\u0064igest"	P1	Verified	MATCH
R13	second name "\u0064igest", same value	P1	Malformed	INDETERMINATE
R14	R1 preceded by the UTF-8 byte order mark	P1	Malformed	INDETERMINATE
R15	purpose evaluation added, its first letter replaced by the byte FF	P1	Malformed	INDETERMINATE
R16	type text/⁠plain	P1	Unresolved	MATCH

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

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 . 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 , and they MUST NOT be used for anything real. The signatures use the deterministic nonce of . iss of X1, the identifier of the configured pair, is the concatenation that 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: Test leaf certificate, 819 bytes (hex): Test root certificate, the trust anchor of the configured pair, 1120 bytes (hex): SHA-256 over the test leaf and over the test root certificate: kid of X1, SHA-256 over the SubjectPublicKeyInfo of the test leaf (hex): 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
• 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 . 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): 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): X3: X1 without parameter 33 (x5chain). Signature (hex): X4: X1 with iss in the form of , whose F is SHA-256 over the test leaf certificate. Signature (hex): X5: X1 with one more parameter, 16 (typ), the text string "application/cose". Signature (hex): X6: X1's protected header unchanged. Signature (hex): Certificate-profile vectors

Vector	Bytes	Candidate	Status	First failing step
X1	2313	P1	accepted	(none)
X2	2313	P1	outside_profile	2
X3	365	P1	outside_profile	2
X4	2313	P1	untrusted_key	3
X5	2331	P1	outside_profile	2
X6	2313	P1	signature_invalid	4

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

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 ). 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 . The Receiver's configured pairs are the pair of and the certificate pair of . The steps of do not read R. R, 472 bytes (hex):

• 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: []}.

Transparent Statements

Vector	Bytes	Candidate	Status	First failing step
T1	786	P1	accepted	(none)
T2	2792	P1	accepted	(none)
T3	2827	P1	outside_profile	2
T4	2791	P1	outside_profile	2
T5	2317	P1	outside_profile	2

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:

Agent Evidence Format Vectors Each vector is presented with the candidates of named in its table; the matching result is that of after the extraction of the subsection of for its format. The result under the neighbouring draft is that draft's own, given for orientation; it does not enter the matching result.

Control Delivery Evidence The instruction of A1 and A2 is a JSON object with three members: basis, a typed digest reference () whose digest names B of P2; control, the text string "suspend"; and governed, the text string "deployment of model acme/model-x@2026-09". Its serialization under , 243 bytes, SHA-256 55650003507b779e0f19567b0d8fdf7b7f09379bd5e1e1e46d26d4211f9db725 (hex): Its content digest is sha-256: followed by the SHA-256 above. The same instruction with digest naming B of P1 is 243 bytes, SHA-256 fab6265f622a37d22fa82763af9681c30e4ff16abe7b7390d7a1b2009006b116. In both vectors an issuer observation and receiver observations at two required targets, EP-A and EP-B, refer to one instruction identifier within one declared identity-uniqueness scope, and they agree in every binding but the content digest. In A1 all three bind the content digest of the instruction above. In A2 the receiver observation at EP-B binds the content digest of the instruction that names B of P1. The last column of the table gives the dispositions of Section 6.1 of for the two obligations.

Vector	Candidate	Matching	Dispositions, its Section 6.1
A1	P2	MATCH	EP-A CONFIRMED, EP-B CONFIRMED
A1	P1	NO_MATCH	EP-A CONFIRMED, EP-B CONFIRMED
A2	P2	MATCH	EP-A CONFIRMED, EP-B SUBSTITUTION

Evidence Qualification Receipts The issuer test key of W1 and W2 is the Ed25519 key whose seed is SHA-256 over the UTF-8 bytes of "EQR test key, PURE TEST KEY"; it MUST NOT be used for anything real. Its public key (base64url) and key identifier: The issuer is https://qualifier.example. Under the verifier's local trust policy (step 7 of Section 8 of ), the issuer is trusted with this key and the type is the only accepted evidence class. The accepted profile has the identifier https://example.org/profiles/evaluation-gated-promotion/v1, one required condition, and a rule each for missing, stale and contradictory evidence; it compares no values and so states no tolerance. Its bytes, the serialization under of a JSON object (hex): The proposition, with claim identifier urn:example:claim:model-x-accuracy, as the serialization under of a JSON object (hex): Each vector is a JWS in compact serialization with the protected header {"alg":"EdDSA","kid":"eqr-test-1"}, whose payload is the serialization under of the EQR and whose signature is Ed25519 under the issuer test key. The verification time is 2026-10-02T00:15:00Z. W1, payload, 707 bytes, SHA-256 7e31e4d7acfcabe459e6a2c5bfd93e77b8a1d43432c8cfd729e1e3110bbccd00 (hex): W1, signature (hex): W2 is W1 with the character = appended to the evidence digest; its payload is 708 bytes, SHA-256 238293b8312d20e24d382169f303501128710c74d8985fcc904fc3a9a264d22c. W2, signature (hex): The last column of the table is the result under Section 8 of with the inputs above.

Vector	Candidate	Matching	EQR, its Section 8
W1	P1	MATCH	valid, qualifies
W1	P2	NO_MATCH	valid, qualifies
W2	P1	INDETERMINATE	invalid: the digest is not base64url without padding

Agent Interaction Records The record is signed with the P-256 test key whose private scalar is d = (SHA-256 over the UTF-8 bytes of "AIR test key, PURE TEST KEY", read as a big-endian integer) mod (n - 1) + 1, where n is the order of the P-256 base point; it MUST NOT be used for anything real. Its public key, uncompressed (hex): operator_id and iss are https://operator.example, agent_id and sub are agent-promotion-1, and operator_pubkey_id is air-test-key-1, whose UTF-8 bytes are kid. V1 is the first record of its chain: sequence_number 0, prev_chain_hash 32 zero bytes, action_timestamp_ms 1791417600000. Its payload, 1253 bytes, SHA-256 ffd0f00f280920c1ed018268869d7b2870a582e55ecdbf57e26452d0aa255795, is the serialization under of a record with action_type configuration_change, outcome_state completed, empty tool_calls, policy_refs and redaction_receipts, and one ExternalRef, whose ref_type is the type, whose ref_value names B of P1 and whose ref_system is null. The signature is ECDSA with SHA-256 under the test key, with the deterministic nonce of . V1, COSE_Sign1, 1610 bytes, SHA-256 db53ccf188407ec9eb382f2146927d799fc2b525849f70d5a14393ab8b8b2ae6 (hex): V2 is V1 with ref_value in uppercase hexadecimal digits; content_hash, chain_hash and the signature follow from that change. V2, 1610 bytes, SHA-256 a80769361c304e0cd49cda542e210779ffcf19ddbbab339ab374cf874cbbdb5c; signature (hex): The last column of the table is the result of the four steps of Section 5.8 of for the first record of a chain.

Vector	Candidate	Matching	AIR, its Section 5.8
V1	P1	MATCH	VERIFIED
V1	P2	NO_MATCH	VERIFIED
V2	P1	INDETERMINATE	VERIFIED

Changes (to be removed before publication)

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

• is new. It cites the framing-space measurement and states what the restriction of leaves of the 64 encodings it measures.
• is new. It states how records of , and can cite a receipt and what each of those drafts leaves open, and gives six vectors. Step 1 of names the form of the value in the two further carriers.
• is cited as revision -04 and as revision -03. now repeats Section 6 of that revision word for word, with its two further sentences.
• and are normative references because Sections 5.1 and 7 depend on their procedures. is now informative. is normative; is informative.
• takes the text form of the digest from step 1 of . 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 . writes the form of iss as a concatenation without spaces. and pass on the input error of 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 , 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 on two higher.
• is cited as revision -06, and its section numbers follow that revision. states the pre-image of its digest context and, following 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 Section 5 fail for the receipt obtained; if processing stops at a resource limit, it gives the resource-limit error of Section 5 instead of a state, and does not rely on such a reference. R6 is now Failed; its matching result stays INDETERMINATE. assumes a verifier that implements the construction and obtains the candidate, and says how the state of R6 was checked and which scripts implement .

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

• The certificate profile does not admit alg -9 (ESP256). gives the measured reason, the measurement, and vector X2 () 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 and stay as cited, already says that no profile names its declaration, and now states the measured reason for retaining the certificate profile's existing limits.
• 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

• 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 () give Malformed inputs and an escaped member name.
• Step 1 of names the form of the value in each carrier.
• and say that a MATCH is not a Verified reference, and is a normative reference.

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

• 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 checks it against a did:x509 identifier and trust anchor that the Receiver configured. Vectors X1 to X6 () cover it.
• checks a Transparent Statement after removing its receipts under label 394 unread, and step 1 fixes the encoding choices that Section 4.2.2 leaves to a protocol. Vectors T1 to T5 () are Transparent Statements, and gives a statement for each status other than accepted.
• assigns the states Unresolved and Failed of Section 9.1 to typed digest references, with vectors R1 to R6 ().
• adds that a receipt does not show where B came from, and adds that an accepted status says nothing about registration and that registration alone does not establish that the payload is the receipt digest.
• 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.