Remote ATtestation procedureS D. Condrey Internet-Draft Writerslogic Inc Intended status: Standards Track 11 February 2026 Expires: 15 August 2026 Proof of Process (PoP): A Verifiable Process Transcript Format draft-condrey-rats-pop-protocol-00 Abstract This document specifies the Proof of Process (PoP) Transcript Format, a structured data model for recording the evolutionary history of a digital document. It defines a canonical set of semantic editing events (Insertion, Deletion, Move, Replacement) and a schema for Tool Receipts, allowing distinct contributors—including human authors, AI agents, and automated editors—to cryptographically sign their specific contributions within a single provenance chain. The protocol utilizes a hash-linked Provenance DAG (Directed Acyclic Graph) to ensure the integrity and ordering of events. This format enables Verifiers to reconstruct the document's lifecycle and apply flexible, policy-based logic to determine authorship attribution. It is designed to be content-aware but policy-agnostic, supporting diverse use cases ranging from academic integrity to software supply chain security. About This Document This note is to be removed before publishing as an RFC. 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." Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Condrey Expires 15 August 2026 [Page 1] Internet-Draft PoP February 2026 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 August 2026. 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Functional Scope and Protocol Claims . . . . . . . . . . . . 5 3.1. Transcript Integrity Claims . . . . . . . . . . . . . . . 5 3.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Ranges and Identifiers . . . . . . . . . . . . . . . . . 6 5.2. Canonical Event Types . . . . . . . . . . . . . . . . . . 6 6. Event Hash Chaining . . . . . . . . . . . . . . . . . . . . . 7 6.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 7 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 7. Time Anchoring . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. External Anchors . . . . . . . . . . . . . . . . . . . . 8 7.2. Sequential Work Anchors . . . . . . . . . . . . . . . . . 8 Condrey Expires 15 August 2026 [Page 2] Internet-Draft PoP February 2026 7.3. Anchor Verification Rules . . . . . . . . . . . . . . . . 8 8. Tool Receipts and Provenance DAG . . . . . . . . . . . . . . 8 8.1. Receipt Model . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Receipt Verification Rules . . . . . . . . . . . . . . . 9 9. Envelope Structure . . . . . . . . . . . . . . . . . . . . . 9 9.1. Policy and Seed Commitments . . . . . . . . . . . . . . . 9 9.2. Claims Field . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Optional Zero-Knowledge Bundle . . . . . . . . . . . . . 10 10. Verification Procedure . . . . . . . . . . . . . . . . . . . 10 10.1. Structural Validation . . . . . . . . . . . . . . . . . 10 10.2. Hash Chain Validation . . . . . . . . . . . . . . . . . 10 10.3. Anchor Validation . . . . . . . . . . . . . . . . . . . 10 10.4. Receipt Validation . . . . . . . . . . . . . . . . . . . 11 10.5. Artifact Binding Validation . . . . . . . . . . . . . . 11 10.6. Policy Evaluation . . . . . . . . . . . . . . . . . . . 11 11. Policy-Defined Evaluation . . . . . . . . . . . . . . . . . . 11 11.1. Policy Commitments . . . . . . . . . . . . . . . . . . . 11 11.2. Seeded Evaluation (Optional) . . . . . . . . . . . . . . 11 11.3. Evaluation Outputs . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12.1. Threat Model Summary . . . . . . . . . . . . . . . . . . 12 12.2. Mitigations . . . . . . . . . . . . . . . . . . . . . . 12 12.3. Algorithm Agility . . . . . . . . . . . . . . . . . . . 13 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14.1. Media Type Registration . . . . . . . . . . . . . . . . 13 15. CDDL Summary (Normative) . . . . . . . . . . . . . . . . . . 14 16. Example Verification Flow (Informative) . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 17.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction As digital documents evolve through complex workflows involving human authors, automated tools, and AI assistants, stakeholders require a standardized method to record _what happened_ during the document's lifecycle. Existing logs are often proprietary, unstructured, or easily mutated. This document specifies the *Proof of Process (PoP) Transcript Format*, a standardized data model for recording the evolutionary history of a digital artifact. It defines a canonical set of *Semantic Events* (Insert, Delete, Replace, Move) and a mechanism for linking these events into a hash-chained *Provenance DAG (Directed Acyclic Graph)*. Condrey Expires 15 August 2026 [Page 3] Internet-Draft PoP February 2026 Designed for interoperability, this format allows disparate editing environments (word processors, code editors, CMS platforms) to produce compatible *Process Transcripts*. These transcripts can support *Tool Receipts*, allowing AI agents and automated tools to cryptographically sign and attribute their specific contributions, thereby enabling a "compositional provenance" model where human and machine contributions are clearly demarcated within a single verifiable history. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Artifact A digital object such as a document, code bundle, or media file. Event A canonical semantic editing operation applied to an artifact state. Transcript An ordered sequence of events representing a process session. Envelope A CBOR-encoded container holding transcript commitments, anchors, receipts, and policy hooks. Anchor A mechanism that binds transcript state to chronology, such as an external timestamp or sequential-work proof. Receipt A signed statement from a tool indicating that content was produced or transformed, referenced by events. Provenance DAG A directed acyclic graph constructed from receipts and references between them. Policy A verifier-defined configuration for evaluation of process evidence. Policy Commit A cryptographic commitment to a policy descriptor, included to identify the applied policy. Seed Commit A cryptographic commitment to a seed used to parameterize evaluation functions and/or audits. Deterministic Encoding CBOR encoding with a canonical ordering as Condrey Expires 15 August 2026 [Page 4] Internet-Draft PoP February 2026 required for reproducible hashing. 3. Functional Scope and Protocol Claims This section defines the scope of the transcript format regarding data integrity and provenance visibility. 3.1. Transcript Integrity Claims A valid PoP Transcript ensures: * *Event Immutability:* Once an event is recorded and covered by a subsequent hash, it cannot be altered or removed without invalidating the chain. * *Completeness:* The final hash of the transcript deterministically reconstructs the final state of the document. Any discrepancy between the transcript-derived state and the actual document content indicates tampering. * *Attribution:* Every event is associated with a specific Actor ID (Key) or Tool Receipt, allowing precise attribution of _who_ or _what_ performed a specific edit. 3.2. Out of Scope * *Content Quality or Truth:* The transcript records that text was written; it does not verify the factual accuracy or quality of that text. * *Intent:* The transcript records operations (e.g., "User deleted paragraph A"). It does not record _why_ the operation occurred. * *Surveillance:* This format is designed for _verification_, not _surveillance_. It supports privacy-preserving disclosure modes (e.g., Zero-Knowledge proofs of statistics) where the raw content of the edits remains private, revealing only the _metrics_ of the process. 4. Architecture Overview PoP is a portable evidence format intended to be produced by an editing environment (the Producer) and consumed by a Verifier. A third party (Anchor Service) MAY provide timestamps or other anchoring evidence. Tools (e.g., language models, grammar checkers, converters) MAY provide signed receipts. Condrey Expires 15 August 2026 [Page 5] Internet-Draft PoP February 2026 +-------------+ Transcript/Envelope +-------------+ | Producer +----------------------->| Verifier | | (Editor) | | (Policy) | +------+------+ +------+------+ | | | | +------+------+ Anchors (optional) | | Anchor +-------------------------------+ | Service | +-------------+ +-------------+ Receipts (optional) +-------------+ | Tools +----------------------->| Producer | | (LLM, etc.) | | / Verifier | +-------------+ +-------------+ Figure 1: PoP Evidence Flow (Informative) PoP is compatible with RATS/EAT deployments by treating the PoP envelope as evidence that can be conveyed alongside attestation tokens, referenced by claims, or embedded in artifact metadata for later validation. The overall Proof of Process architecture is defined in [I-D.condrey-rats-pop]. 5. Data Model PoP uses CBOR [RFC8949] as the encoding and CDDL [RFC8610] for data model definitions. All hashing computations depend on deterministic CBOR encoding; Producers and Verifiers MUST use a deterministic CBOR encoding profile suitable for reproducible hashing. 5.1. Ranges and Identifiers Offsets and ranges refer to a canonical byte or character indexing scheme over the logical artifact content. The indexing scheme MUST be specified by the Producer and bound in the envelope so that Verifiers can interpret ranges consistently. This specification defines a generic Range structure. Producers MAY use byte offsets, Unicode scalar offsets, or another deterministic scheme. The chosen scheme MUST be indicated in the envelope. 5.2. Canonical Event Types PoP defines canonical semantic event types. Events describe changes to artifact state at a semantic operation level rather than raw keystrokes. Raw keystroke telemetry is OPTIONAL and is not required for PoP verification. Condrey Expires 15 August 2026 [Page 6] Internet-Draft PoP February 2026 The following event types are defined: * *INS*: insert content at a range/position * *DEL*: delete content in a range * *REP*: replace content in a range with new content * *MOV*: move a range to a destination position * *PASTE*: insert content with an origin reference (e.g., receipt- bound) * *SNAP*: checkpoint snapshot of artifact hash and optional cursor state Events MUST include sufficient information to validate transcript integrity and, when required by policy, to validate that the transcript corresponds to the final artifact (e.g., via checkpoints). 6. Event Hash Chaining PoP binds transcript events in order using a hash chain. The chain depends on deterministic encoding of each Event structure. 6.1. Hash Algorithm Let H be a cryptographic hash function. This specification RECOMMENDS SHA-256. The initial hash value h_0 MUST be defined as the hash of a domain separation string and the session identifier: h_0 = H("PoP-Transcript" || session_id) For each event E_i, the chain value is computed as: h_i = H(h_{i-1} || CBOR_Deterministic(E_i)) The transcript root is defined as root = h_n for the final event E_n. 6.2. Requirements * Producers MUST use deterministic CBOR encoding for all hashed structures. * Verifiers MUST recompute the hash chain and compare the derived root to the envelope root. * Mismatch of any chain computation MUST cause verification failure. Condrey Expires 15 August 2026 [Page 7] Internet-Draft PoP February 2026 7. Time Anchoring PoP supports optional chronology binding via Anchors. Policies MAY require specific anchor types or densities. This document defines two anchor classes: External Anchors and Sequential Work Anchors. 7.1. External Anchors An External Anchor binds the transcript root (or an intermediate chain value) to an externally verifiable time assertion (e.g., a timestamping service, transparency log, or other notary). The specific external anchoring system is out of scope for this document; PoP defines a generic container for including and validating anchor evidence. 7.2. Sequential Work Anchors A Sequential Work Anchor provides evidence that a specified amount of sequential computation was performed between two transcript states. This can increase the cost of post-hoc backfilling. The concrete VDF or sequential-work scheme is policy-defined. This document defines a container to carry such evidence. 7.3. Anchor Verification Rules * If an envelope includes anchors, verifiers MUST validate each anchor according to its type. * If a policy requires anchors and they are absent or invalid, verification MUST fail. * Anchor validation MUST bind to the relevant transcript state (root or intermediate chain values) as specified by the anchor. 8. Tool Receipts and Provenance DAG PoP supports compositional provenance via signed tool receipts. Receipts enable producers to explicitly declare and bind tool- generated outputs (including AI assistance) without relying on brittle inference or detection. Receipts MAY be used for any deterministic or non-deterministic tool that emits content, patches, or transformations that contribute to the artifact. Condrey Expires 15 August 2026 [Page 8] Internet-Draft PoP February 2026 8.1. Receipt Model A Receipt is a signed statement that binds tool identity and an output commitment. An input commitment MAY be included to allow stronger binding, but is OPTIONAL to support privacy-preserving tools. Receipts MAY reference other receipts to form a provenance DAG. Policies MAY restrict recursion depth. 8.2. Receipt Verification Rules * Verifiers MUST validate each receipt signature over its canonical encoding. * Receipt public keys MUST be represented in a verifiable format; policies MAY require certificate chains or allow bare keys. * If an event references a receipt (via source_ref), the referenced receipt MUST be present or retrievable under policy. * Policies MAY require validation of the provenance DAG and MAY impose recursion and size limits. 9. Envelope Structure The PoP Envelope is the primary interchange object. It binds transcript commitments, anchors, receipts, and policy hooks. The envelope is CBOR-encoded and SHOULD be embedded into artifact metadata or conveyed alongside artifacts. 9.1. Policy and Seed Commitments PoP defines policy hooks but does not standardize a scoring model. To enable reproducible application of a policy, the envelope includes: * *policy_commit*: a commitment to a policy descriptor * *seed_commit*: a commitment to a seed used to parameterize evaluation and/or audits Commitments support commit-then-reveal workflows where the evaluation surface is unpredictable at capture time but verifiable after reveal under policy. Condrey Expires 15 August 2026 [Page 9] Internet-Draft PoP February 2026 9.2. Claims Field The envelope MAY include a claims field carrying derived values (e.g., integrity pass/fail, evaluation outputs). Claims MUST NOT be treated as authoritative unless verifiers recompute or validate them under policy. Policies SHOULD treat claims as advisory and derive evaluation from transcript evidence. 9.3. Optional Zero-Knowledge Bundle The envelope MAY include a zk bundle to support privacy-preserving verification (e.g., threshold proofs for policy-defined evaluations without full transcript disclosure). The specific ZK proof system is policy-defined. 10. Verification Procedure Verifiers MUST perform the following procedure to validate a PoP envelope. Policies MAY impose additional requirements and MAY allow partial disclosure modes. 10.1. Structural Validation 1. Parse the envelope as CBOR and validate required fields. 2. Validate version and supported algorithms. 3. Validate encoding determinism constraints where applicable. 10.2. Hash Chain Validation 1. Obtain the transcript (full disclosure or policy-authorized proofs). 2. Recompute the hash chain from h_0 through h_n. 3. Compare derived root to the envelope root. Mismatch MUST cause verification failure. 10.3. Anchor Validation 1. Validate all included anchors. 2. Confirm anchors bind to the intended transcript state (root or specified chain values). 3. Apply policy requirements for anchor presence, density, or types. Condrey Expires 15 August 2026 [Page 10] Internet-Draft PoP February 2026 10.4. Receipt Validation 1. Validate receipt signatures and canonical encodings. 2. Resolve and validate referenced receipts as required by policy. 3. Verify any policy constraints on receipt DAG depth or classes. 10.5. Artifact Binding Validation Policies MAY require validation that the transcript corresponds to the final artifact. This may be performed by verifying SNAP events, checkpoints, or other commitments that bind the transcript to the final artifact hash. 10.6. Policy Evaluation After transcript and anchoring verification, a verifier MAY compute features and apply a policy-defined evaluation. If the envelope includes a ZK bundle and the policy allows it, the verifier MAY validate a ZK proof instead of obtaining the full transcript. 11. Policy-Defined Evaluation PoP does not standardize any scoring function, threshold, or interpretation. Policies define evaluation inputs, models, and thresholds. PoP provides hooks to identify policies and support reproducible evaluation. 11.1. Policy Commitments The policy_commit field is a cryptographic commitment to a policy descriptor, e.g.: policy_commit = H(policy_descriptor) The contents and distribution of the policy descriptor are out of scope for this document. Policies MUST be uniquely identifiable by policy_commit. 11.2. Seeded Evaluation (Optional) Policies MAY use seeds to parameterize evaluation functions (e.g., to mitigate adaptive optimization against a static evaluation surface). If used, the envelope includes seed_commit, and verifiers MAY require a reveal of the seed or a ZK proof that incorporates the committed seed. Condrey Expires 15 August 2026 [Page 11] Internet-Draft PoP February 2026 11.3. Evaluation Outputs Any evaluation outputs, including derived claims, are policy-defined and MUST be expressed as assessments of evidence, not assertions of cognitive origin. Policies SHOULD provide outputs that are interpretable and auditable (e.g., quantified import ratios, refinement ratios, or other measurable evidence summaries). 12. Security Considerations PoP provides tamper-evident transcripts and optional chronology binding. It does not prevent an adversarial producer from performing arbitrary sequences of valid edits. Policies should treat PoP as evidence of recorded process, not proof of mental origin. 12.1. Threat Model Summary * *Synthetic transcript generation*: a producer may attempt to fabricate a transcript consistent with a target artifact. * *Receipt forgery*: a producer may attempt to forge or replay tool receipts. * *Anchor replay or substitution*: invalid anchors may be presented or misbound. * *Adaptive optimization*: if evaluation metrics are static and public, adversaries may optimize transcripts to pass thresholds. * *Privacy leakage*: transcripts can reveal sensitive drafting history if disclosed improperly. 12.2. Mitigations * Hash chaining over deterministic encodings provides tamper evidence. * Anchors (timestamps, sequential work) can raise the cost of post- hoc fabrication and bind chronology. * Receipt signatures and, when used, DAG validation mitigate provenance forgery. * Seeded evaluation can mitigate adaptive optimization (policy- defined; not required by PoP). * Policies should define disclosure requirements and support partial disclosure or ZK proofs. Condrey Expires 15 August 2026 [Page 12] Internet-Draft PoP February 2026 12.3. Algorithm Agility Producers and verifiers SHOULD support algorithm agility for hash functions and signature schemes. Policies SHOULD specify allowed algorithms and minimum security strengths. 13. Privacy Considerations Transcripts can reveal sensitive intermediate drafts, editing patterns, and content that was later removed. PoP supports multiple disclosure modes, but this document does not mandate a particular privacy policy. * *Full disclosure*: the entire transcript is revealed to a verifier. * *Partial disclosure*: Merkle proofs or selective event disclosure under policy. * *Zero-knowledge*: policy-defined threshold proofs without transcript disclosure. Policies SHOULD minimize disclosure and SHOULD avoid collecting raw keystrokes or invasive telemetry unless explicitly required for a deployment and accompanied by informed consent. 14. IANA Considerations This document requests IANA to register a media type for PoP envelopes encoded in CBOR. 14.1. Media Type Registration Type name: application Subtype name: pop+cbor Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: see Section 12 Interoperability considerations: none Published specification: this document Condrey Expires 15 August 2026 [Page 13] Internet-Draft PoP February 2026 Applications that use this media type: editors, provenance systems, attestation verifiers Fragment identifier considerations: none Additional information: Magic number(s): none File extension(s): .pop Macintosh file type code(s): none Person & email address to contact for further information: David Condrey (david@writerslogic.com) Intended usage: COMMON Restrictions on usage: none Author: Authors of this document Change controller: IETF 15. CDDL Summary (Normative) This appendix provides a consolidated CDDL summary for PoP-1.5 structures. Implementations MUST follow these definitions and MUST apply deterministic CBOR encoding for all hashed objects. The complete normative CDDL schema is defined in [I-D.condrey-rats-pop-schema]. ; NOTE: This CDDL is a summary skeleton. Field-level constraints and algorithm ; registries should be expanded as the draft matures. PoPEnvelope = { version: "PoP-1.5", session_id: bstr, root: bstr, transcript_commit: bstr, ? index_scheme: tstr, ; e.g., "byte", "unicode_scalar" anchors: [* Anchor], seed_commit: bstr, policy_commit: bstr, receipts: [* Receipt], import_index: ImportSummary, Condrey Expires 15 August 2026 [Page 14] Internet-Draft PoP February 2026 ? claims: Claims, ? zk: ZKBundle } Range = { start: uint, len: uint } Event = { type: tstr, ; "INS" / "DEL" / "REP" / "MOV" / "PASTE" / "SNAP" ? range: Range, ? dst_pos: uint, ? data_hash: bstr, ? old_hash: bstr, ? new_hash: bstr, ? length: uint, ? doc_hash: bstr, ; for SNAP ? cursor_pos: uint, ; optional ? source_ref: bstr, ; references Receipt.output_commit or receipt id ? aux: bstr } Anchor = { type: tstr, ; "external" / "seqwork" / policy-defined binds: bstr, ; root or intermediate chain value value: bstr, ? timestamp: uint } Receipt = { tool_id: tstr, tool_pubkey: bstr, input_commit: bstr / null, output_commit: bstr, flags: [* tstr], ? anchor: Anchor, sig: bstr } ImportSummary = { raw_import_bytes: uint, paste_events: uint, receipt_bound_events: uint, refined_pct: float } Claims = { Condrey Expires 15 August 2026 [Page 15] Internet-Draft PoP February 2026 integrity: float, time: float, liveness: float, emergence: float, topology: float, assistance: float, refinement: float, process_quality: float } ZKBundle = { score_threshold_proof: bstr, public_inputs: [* bstr] } Figure 2: PoP-1.5 CDDL Summary 16. Example Verification Flow (Informative) This appendix illustrates a typical verification sequence. 1. Verifier parses the PoP envelope and checks required fields. 2. Verifier obtains transcript disclosure (full transcript or policy-approved proofs). 3. Verifier recomputes the transcript hash chain and validates the root. 4. Verifier validates all anchors included in the envelope and applies policy requirements. 5. Verifier validates receipt signatures and resolves any referenced receipts per policy. 6. Verifier validates binding to the final artifact hash (if required by policy). 7. Verifier applies policy-defined evaluation; if ZK is provided, verifies threshold proof. 8. Verifier outputs an evidence summary as policy-defined assessment of process evidence. 17. References 17.1. Normative References Condrey Expires 15 August 2026 [Page 16] Internet-Draft PoP February 2026 [IANA.cbor-tags] IANA, "CBOR Tags", . [IANA.media-types] IANA, "Media Types", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL)", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, December 2024, . 17.2. Informative References Condrey Expires 15 August 2026 [Page 17] Internet-Draft PoP February 2026 [I-D.condrey-rats-pop] Condrey, D., "Proof of Process Provenance Protocol (PPPP): An Evidence Framework for Document Authorship Attestation", Work in Progress, Internet-Draft, draft- condrey-rats-pop, . [I-D.condrey-rats-pop-examples] Condrey, D., "Examples of Proof of Process Evidence Packets and Attestation Results", Work in Progress, Internet-Draft, draft-condrey-rats-pop-examples, . [I-D.condrey-rats-pop-schema] Condrey, D., "Proof of Process CDDL Schema", Work in Progress, Internet-Draft, draft-condrey-rats-pop-schema, . [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, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2024, . Acknowledgments The author thanks the RATS working group for foundational work on remote attestation architectures. Thanks also to reviewers who provided feedback on CBOR encoding determinism, COSE signing surfaces, and transport binding interoperability. Author's Address David Condrey Writerslogic Inc United States Condrey Expires 15 August 2026 [Page 18] Internet-Draft PoP February 2026 Email: david@writerslogic.com URI: https://writerslogic.com Condrey Expires 15 August 2026 [Page 19]