Network Working Group C. Öztürk Internet-Draft Falsify OÜ Intended status: Informational 11 September 2026 Expires: 15 March 2027 A SCITT Profile for Pre-Run Evaluation Criteria (PRML) draft-ozturk-scitt-prml-profile-00 Abstract This document defines a profile for carrying pre-run evaluation criteria as a SCITT Signed Statement payload, using the architecture of RFC 9943. It specifies the payload media type, the selection of the Issuer and Subject CWT claims, the encoding of hash-only statements for criteria that must remain confidential, a sequencing requirement that makes amendment order verifiable, and the semantics of amendment itself. It does not define a new transparency architecture; it describes how an existing artefact type is carried by the one RFC 9943 already defines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Ozturk Expires 15 March 2027 [Page 1] Internet-Draft SCITT PRML Profile September 2026 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Payload Type . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Canonicalisation . . . . . . . . . . . . . . . . . . . . . . 4 5. CWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Unprotected Header . . . . . . . . . . . . . . . . . . . . . 6 7. Detached (Hash-Only) Statements . . . . . . . . . . . . . . . 6 7.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Mode Signalling -- Open Issue . . . . . . . . . . . . . . 7 7.3. Reveal . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.4. Multiple Registrations . . . . . . . . . . . . . . . . . 7 8. Amendment Semantics . . . . . . . . . . . . . . . . . . . . . 8 8.1. Two Complementary Histories . . . . . . . . . . . . . . . 8 8.2. Sequencing Requirement . . . . . . . . . . . . . . . . . 9 9. Verification Procedure . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Relationship to Other Work . . . . . . . . . . . . . 12 Appendix B. Worked Examples . . . . . . . . . . . . . . . . . . 12 Appendix C. Implementation Status . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction An evaluation of an AI system is reported as a claim: a metric, a comparator, a threshold, a dataset and a seed. A reader of such a report cannot tell from its prose when that combination came into existence. A threshold chosen after the numbers were seen and a threshold chosen beforehand are textually identical. Where the evaluation data is withheld, which [AEF-1] condition 4.1 explicitly permits in order to protect evaluation integrity, the reader additionally cannot tell whether an artefact disclosed later is the same artefact that existed at the time. Ozturk Expires 15 March 2027 [Page 2] Internet-Draft SCITT PRML Profile September 2026 [RFC9943] already provides the machinery to evidence both points: a Signed Statement registered with a Transparency Service, optionally made over the hash of a payload rather than its bytes ([RFC9943], Section 6.2), and a defined way to supersede a statement when the state it describes changes ([RFC9943], Section 6.3). What is missing is a payload profile: an agreement on what the payload is, what identifies it across revisions, and how a verifier canonicalises it before comparing digests. This document supplies that profile for PRML [PRML], an existing serialisation of pre-run evaluation criteria with a registered media type. 1.1. Scope and Non-Goals This profile is deliberately narrow. What a conforming Statement establishes depends on the mode, and the difference matters. In full-payload mode, the canonical bytes of a specific criteria object were signed and registered no later than the time recorded by the Transparency Service. In hash-only mode, a commitment to a digest was signed and registered no later than that time. A Relying Party holding only the ledger entry cannot know that any object with that digest exists: a digest is 32 octets and committing to one is possible without a preimage. What the commitment gives is binding after the fact -- a later- revealed object that canonicalises to the committed digest is cryptographically bound to that commitment, and one that does not is not the committed object. Implementations MUST NOT describe hash- only registration as establishing the existence of the object before it is revealed. Neither mode establishes: * that the evaluation run occurred after registration. Execution linkage is out of scope; a separate dated artefact is required and is not defined here. * that the criteria are appropriate for the system under evaluation. * anything about the correctness of the reported result. Ozturk Expires 15 March 2027 [Page 3] Internet-Draft SCITT PRML Profile September 2026 * any property of the Issuer's independence. [AEF-1] treats assessment carried out in terms set by the party being evaluated as a lower standard of independence than an independent audit; registration of a criteria object does not change that classification. Implementers and specification readers are asked to preserve these boundaries when summarising this profile. 2. Conventions and Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Criteria object: A PRML manifest, as defined in [PRML], carrying at minimum the nine required fields version, claim_id, created_at, metric, comparator, threshold, dataset, seed and producer. Canonical bytes: The byte string produced by the PRML canonicalisation algorithm (Section 4). 3. Payload Type The payload type (COSE [STD96] header parameter 3, content type) of a conforming Signed Statement MUST be application/vnd.prml+yaml. This media type is registered in the IANA Media Types registry. Registration records a media type; it does not constitute review or endorsement of this profile by IANA. 4. Canonicalisation A digest over a serialisation format with degrees of freedom is ambiguous. Before hashing, a criteria object MUST be rendered to canonical bytes. PRML canonicalisation is defined as the output of a YAML block-style serialisation with keys sorted lexicographically, no flow style, Unicode permitted unescaped, and an effectively unbounded line width. The normative definition and its conformance vectors are in [PRML]. The digest algorithm for this profile is SHA-256. Ozturk Expires 15 March 2027 [Page 4] Internet-Draft SCITT PRML Profile September 2026 Implementations MUST NOT hash the bytes as received from a producer. Two producers expressing identical criteria will generally not emit identical bytes; only the canonicalised form is comparable. 5. CWT Claims [RFC9943], Section 6 requires the protected header of a Signed Statement to include the CWT Claims header parameter [RFC9597] carrying at least the Issuer claim (label 1) and the Subject claim (label 2). This profile constrains their values. 5.1. Issuer The iss claim identifies the Issuer that signs the criteria Statement, cryptographically bound as required by [RFC9943], Section 5.1.1.1. The Issuer is not necessarily the party that submits the Statement. [RFC9943] allows a Client to register Signed Statements on behalf of one or more Issuers, so a conforming deployment may have an evaluation platform register on an evaluator's behalf. This profile constrains who signs, not who submits. A criteria object also carries a producer field. That field is self- asserted text inside the payload and is NOT authenticated by registration. Where the two disagree, the iss claim is authoritative as to who signed the Statement, and the producer field is to be read only as the Issuer's own description of the originating party. Verifiers MUST NOT treat the producer field as an authenticated identity. 5.2. Subject The sub claim MUST be the claim_id of the criteria object. This choice is not an invention of this profile. [RFC9943], Section 6.3 says that an Issuer aware of a changed state SHOULD register a new Signed Statement using the same iss and sub claims. [PRML], Section 6.1 independently requires that a producer changing any field of a previously registered claim create a new manifest whose prior_hash is the manifest hash of the previous claim, and that the new manifest "MUST retain the claim_id of the previous claim". claim_id is therefore already normatively stable across an amendment chain, while the payload digest changes with each revision. Ozturk Expires 15 March 2027 [Page 5] Internet-Draft SCITT PRML Profile September 2026 If sub were instead the digest of the criteria object, every amendment would carry a different sub and the relationship between successive versions would be lost. Binding sub to claim_id yields a stable subject and a changing body, which is what [RFC9943], Section 6.3 assumes. 6. Unprotected Header [RFC9943], Section 6.3 requires that the unprotected header of a Signed Statement be set to an empty map before the Statement can be included in a Statement Sequence. A conforming Statement under this profile therefore carries an empty unprotected header, and this profile defines no parameters to place there. 7. Detached (Hash-Only) Statements Where the criteria object must remain confidential, the Statement MUST be made over the SHA-256 digest of the canonical bytes rather than over the bytes themselves, as permitted by [RFC9943], Section 6.2 for payloads that are too large or too sensitive to transmit. This is the mode intended for the case in [AEF-1] condition 4.1, where an evaluator withholds testing data. The dataset and thresholds are not transmitted to the Transparency Service and do not appear on the ledger. 7.1. Encoding [RFC9943], Section 6.2 permits a Statement over a payload hash but does not specify how that hash is encoded. Interoperability requires an exact answer, so this profile fixes one. In hash-only mode: * The Statement payload MUST be the 32 raw octets of SHA-256 over the canonical bytes (Section 4), carried as a CBOR byte string. It MUST NOT be hex-encoded, base64-encoded, or wrapped in any further structure. * The payload is present in the COSE_Sign1 rather than detached, so that a Relying Party holding only the ledger entry can read the committed digest without holding the criteria object. Publishing the digest is the point of this mode; a detached payload would put nothing on the ledger to compare a later disclosure against. * iss, sub and the amendment semantics of Section 8 are unchanged. Ozturk Expires 15 March 2027 [Page 6] Internet-Draft SCITT PRML Profile September 2026 7.2. Mode Signalling -- Open Issue A verifier must be able to distinguish the two modes before parsing. Thirty-two octets of digest and a YAML manifest are both legitimate payloads under this profile, and a verifier that reads the first as the second fails in a confusing way rather than a safe one. Full-payload mode uses the payload type application/vnd.prml+yaml (Section 3). Hash-only mode requires a distinct signal, and this document does not fix one. The two candidates are a separately registered payload type for the digest form, or a COSE header parameter declaring the digest algorithm over the committed object. Until it is settled, an Issuer MUST NOT assert application/ vnd.prml+yaml as the payload type of a hash-only Statement: 32 octets of digest are not a YAML manifest, and a false type is worse than an absent one. An Issuer SHOULD omit the payload type in this mode and convey it out of band. This is an interim measure, not the intended end state. This is the one open interoperability question in this profile. It is left open deliberately rather than settled unilaterally in a -00, and comment is invited. 7.3. Reveal A later disclosure to a party entitled to receive it is verified by canonicalising the disclosed object and comparing its digest to the registered one. A disclosure that does not reproduce the digest is not the registered object. Nothing in this mechanism obliges an Issuer to disclose, or evidences that a disclosure is complete. 7.4. Multiple Registrations An Issuer may register several criteria objects under the same sub and disclose only the one that suits a later narrative. This profile does not prevent that, and implementers MUST NOT describe it as preventing it. A Relying Party concerned with selective disclosure SHOULD use a Transparency Service or Auditor interface capable of enumerating all Statements for the relevant iss/sub pair. The append-only Statement Sequence ([RFC9943], Section 5.1.3) is what makes such completeness auditable; this profile does not define the discovery API, and [RFC9943] does not require a Transparency Service to offer subject-based query. Ozturk Expires 15 March 2027 [Page 7] Internet-Draft SCITT PRML Profile September 2026 8. Amendment Semantics A threshold that changes after testing is not, by itself, evidence of bad faith. Public evaluation guidance recognises legitimate post-hoc refinement with justification. What is objectionable is an undated change presented as the original. Accordingly, this profile does not treat a criteria object as immutable. It treats the history as immutable. An Issuer amending criteria MUST register a new Signed Statement under the same iss and sub per [RFC9943], Section 6.3, rather than attempting to replace an existing registration, and the new payload MUST set prior_hash to the digest of the superseded object per [PRML], Section 6.1. The earlier statement remains on the ledger. [PRML], Section 6.2 requires that verifiers treat the latest manifest in a chain as operative while also exposing the full chain on request; this profile adopts that requirement unchanged. The sequence of statements under a sub is the change history, and a justified later change is dated rather than hidden. 8.1. Two Complementary Histories A conforming deployment carries two records of the same sequence. They are not two independent time sources, and must not be presented as such. The prior_hash chain is intrinsic and Issuer-asserted. It is a link structure written into the payload by the party making the claim; it establishes which object supersedes which, and nothing about time. The created_at field is likewise Issuer-asserted. The ledger is extrinsic and Service-asserted. [RFC9943] records the registration time as the time the Transparency Service added the Signed Statement to its Verifiable Data Structure, which the Issuer does not control. *The ledger does not authenticate created_at.* A verifier MUST treat created_at as Issuer-asserted, and the registration time as the independently evidenced upper bound on the object's existence. In particular, a created_at earlier than the registration time is consistent with the record and is not evidence of anything: an object may genuinely have been authored well before it was registered. Back-dating created_at is therefore NOT detectable from the ledger, and implementers MUST NOT claim otherwise. What checking both records does detect: Ozturk Expires 15 March 2027 [Page 8] Internet-Draft SCITT PRML Profile September 2026 * a created_at later than the Statement's own registration time, which is self-contradictory; * amendments registered in an order that disagrees with the prior_hash links; * a Transparency Service that omits or reorders entries, which the prior_hash links contradict. Verifiers SHOULD check both and MUST report a disagreement between them rather than selecting one. 8.2. Sequencing Requirement The ledger order is not, by itself, evidence of issuance order. [RFC9943], Section 9.1 is explicit: "Unless advertised in the TS Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the VDS matches the ordering of their issuance." A comparison between the prior_hash chain and the ledger is therefore meaningless unless something makes the two comparable. This profile supplies that something as its own requirement rather than assuming it of the Transparency Service: An Issuer MUST obtain a Receipt for a predecessor Statement before registering a successor that names it in prior_hash. For a conforming Issuer the registration order of a chain is then necessarily the amendment order, and a ledger that shows otherwise indicates either a non-conforming Issuer or a Transparency Service fault. Verifiers MUST NOT apply the check in Section 9 step 6 to chains whose Issuer does not claim conformance with this requirement. 9. Verification Procedure Steps 1 and 3 through 6 are common to both modes. Step 2 and step 7 differ, because the two modes register different things. Given a criteria object and a Receipt, a verifier: 1. verifies the Receipt as a COSE Receipt per [RFC9942]; 2. determines the mode: * *Full-payload mode:* confirms the payload type is application/ vnd.prml+yaml (Section 3) and that the payload is the canonical bytes. Ozturk Expires 15 March 2027 [Page 9] Internet-Draft SCITT PRML Profile September 2026 * *Hash-only mode:* confirms the payload is 32 octets (Section 7). How the two modes are distinguished on the wire is unresolved in this revision; until it is settled, a verifier obtains the mode out of band, and an implementation MUST NOT infer full-payload mode from the payload type alone when a 32-octet payload is possible. 3. confirms the sub claim equals the claim_id of the object under examination; 4. canonicalises the object per Section 4 and computes its SHA-256 digest; 5. compares that digest to the registered payload (full-payload mode) or to the committed digest (hash-only mode); 6. where the object carries prior_hash, and only where the Issuer claims conformance with Section 8.2, resolves the chain and checks that its order is consistent with the ledger order of the corresponding Statements; 7. reports the Transparency Service's recorded time as an upper bound -- in full-payload mode, on the existence of the object; in hash-only mode, on the registration of the commitment. The object's own existence is evidenced only once a disclosure reproduces the digest. A verifier MUST report step 7 as an upper bound. It is not evidence of when the evaluation ran. 10. Security Considerations The guarantees of this profile are those of the underlying Transparency Service; it adds no cryptographic mechanism of its own. Canonicalisation is security-relevant. An implementation that hashes non-canonical bytes will produce digests that fail to match for semantically identical objects, and may be induced to accept a non- matching object as matching if it normalises after comparison rather than before. Implementations SHOULD validate against the published conformance vectors. Registration is not authentication of content. A Transparency Service authenticates the Issuer of a statement, not the truthfulness of the payload. A registered criteria object is evidence of existence and integrity, not of accuracy. Ozturk Expires 15 March 2027 [Page 10] Internet-Draft SCITT PRML Profile September 2026 Hash-only mode publishes the digest and the time. It is a commitment, not a concealment scheme: *this profile provides no hiding against a dictionary attack over a low-entropy criteria object.* Where the plausible criteria space is small enough to enumerate -- a handful of metrics against round-numbered thresholds, for instance -- an adversary can recover the committed object by trying candidates until one reproduces the digest. [PRML] defines no commitment nonce, and claim_id cannot serve as one because this profile publishes it as sub. Issuers for whom this matters should not rely on hash-only mode for confidentiality. Adding a salt would change the PRML object model and is not proposed here. 11. IANA Considerations This document has no IANA actions. The media type application/ vnd.prml+yaml is already registered. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Ozturk Expires 15 March 2027 [Page 11] Internet-Draft SCITT PRML Profile September 2026 [STD96] Internet Standard 96, . At the time of writing, this STD comprises the following: Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, . 12.2. Informative References [AEF-1] AI Evaluator Forum, "AEF-1: Minimum Operating Conditions for Independent Third Party AI Evaluations", December 2025, . [PRML] Falsify OU, "PRML: Pre-Run Manifest Language, version 0.1", May 2026, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . Appendix A. Relationship to Other Work Several individual Internet-Drafts published in 2026 define SCITT profiles for AI-related artefacts, including agent action authorisation and transparency receipts for regulatory disclosure obligations. This profile does not claim priority over or compatibility with any of them. It addresses a different artefact: the evaluation criteria themselves, before a run. Appendix B. Worked Examples Two Signed Statements over the same criteria object, one per mode, are published alongside this draft together with the public key, the canonical bytes, the generator and an independent verifier that follows Section 9 step by step. Ozturk Expires 15 March 2027 [Page 12] Internet-Draft SCITT PRML Profile September 2026 The criteria object is conformance vector TV-001 of the published PRML v0.1 suite. Its canonical form is 294 octets and its SHA-256 is 1a3466cc08ee7fb60a726ea1c4db6ecf48a9f847b9b7523bfb54b2ffaefee546, which a reader can check against the published vector without trusting this document. The full-payload Statement is 488 octets; the hash-only Statement is 197. Both are signed with EdDSA over Ed25519 under a throwaway key published alongside them. The algorithm was chosen so that the examples are byte-reproducible: EdDSA is deterministic, so a reader who regenerates them gets the same octets and can diff. The profile itself is algorithm-agnostic. Two things in this document exist because building these examples exposed them: the interim rule against asserting a payload type in hash-only mode (Section 7.2), and the empty unprotected header requirement above. Neither was visible from the prose alone. Appendix C. Implementation Status Four byte-equivalent reference implementations of the PRML canonicalisation and digest algorithm exist, in Python, JavaScript, Go and Rust. All four were authored by the same maintainer and are validated against a shared conformance vector suite; they are not independent implementations in the sense usually meant by an interoperability report. A public PRML registry implements a hash-only sealed-commitment mechanism with application semantics similar to Section 7, using [RFC3161] time-stamping and a public transparency log. It is *not* an implementation of this profile: it accepts unsigned submissions, so there is no Issuer-signed Statement, and it emits neither COSE Signed Statements nor COSE Receipts. It is therefore not a conforming Transparency Service under [RFC9943]. No conforming implementation of this profile is known to the author at the time of writing. This status note is included so that readers do not infer a conforming deployment from the existence of this document. Author's Address Cüneyt Öztürk Falsify OÜ Estonia Email: cuneyt@falsify.dev Ozturk Expires 15 March 2027 [Page 13]