A SCITT Profile for Pre-Run Evaluation Criteria (PRML)
draft-ozturk-scitt-prml-profile-00

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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

   [RFC9597]  Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
              COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
              <https://www.rfc-editor.org/rfc/rfc9597>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9942>.

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

Ozturk                    Expires 15 March 2027                [Page 11]
Internet-Draft             SCITT PRML Profile             September 2026

   [STD96]    Internet Standard 96,
              <https://www.rfc-editor.org/info/std96>.
              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,
              <https://www.rfc-editor.org/info/rfc9052>.

              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Countersignatures", STD 96, RFC 9338,
              DOI 10.17487/RFC9338, December 2022,
              <https://www.rfc-editor.org/info/rfc9338>.

12.2.  Informative References

   [AEF-1]    AI Evaluator Forum, "AEF-1: Minimum Operating Conditions
              for Independent Third Party AI Evaluations", December
              2025, <https://aef.one/aef-one.pdf>.

   [PRML]     Falsify OU, "PRML: Pre-Run Manifest Language, version
              0.1", May 2026, <https://spec.falsify.dev/v0.1>.

   [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, <https://www.rfc-editor.org/rfc/rfc3161>.

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]