Internet-Draft PoP Protocol February 2026
Condrey Expires 18 August 2026 [Page]
Workgroup:
Remote ATtestation procedureS
Internet-Draft:
draft-condrey-rats-pop-protocol-03
Published:
Intended Status:
Standards Track
Expires:
Author:
D. Condrey
WritersLogic

Proof of Process (PoP): Architecture, Evidence Format, and VDF

Abstract

This document specifies the Proof of Process (PoP) Evidence Framework, a specialized profile of Remote Attestation Procedures (RATS) [RFC9334] designed to validate the provenance of effort in digital authorship. Unlike traditional provenance, which tracks file custody, PoP attests to the continuous physical process of creation.

The protocol defines a cryptographic mechanism for generating Evidence Packets utilizing Proof of Biological Space-Time (PoBST) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical die thermodynamics to the document state. Technical specifications for wire formats, verifiable delay functions, and hardware-anchored trust are provided.

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 18 August 2026.

Table of Contents

1. Introduction

The rapid proliferation of generative artificial intelligence has created an authenticity crisis in digital discourse. While traditional provenance tracks the "custody of pixels," it fails to attest to the human-driven process of creation. This document specifies the Proof of Process (PoP) protocol, which extends the RATS architecture [RFC9334] to validate the "provenance of effort."

Unlike traditional attestation which captures static system state, PoP attests to a continuous physical process. It introduces Proof of Biological Space-Time (PoBST) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical state (thermodynamics) to the document's evolution.

By entangling content hashes with these physical constraints, this protocol enables an Attester to generate an Evidence Packet (.pop) that cryptographically distinguishes between human generation and algorithmic simulation, preserving privacy by design without disclosing document content.

2. Requirements Language

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.

3. Core Principles and Claims

PoP operates on five primary constraints:

4. Protocol Rationale and Terminology

The Proof of Process (PoP) framework follows the RATS architecture while introducing domain-specific extensions for physical process attestation.

PPP Evidence (.pop):
An Attester artifact containing Merkle trees, PoBST traces, and physical liveness markers (CBOR tag 1347571280).
WAR Result (.war):
A Verifier Attestation Result containing signed EAT claims and forensic assessments (CBOR tag 1463894560).
PoBST:
Proof of Biological Space-Time. A memory-hard sequential function with asymmetric verification, entangled with human jitter.
CDCE:
Cross-Domain Constraint Entanglement. The method of weaving jitter and thermodynamics into the cryptographic chain.

5. Attester State Machine

The Attesting Environment (AE) MUST implement the following formal state machine:

6. Evidence Content Tiers

PPP Evidence packets are classified by the depth of behavioral and forensic data collected:

CORE (Tier Value 1):
Checkpoint chain with PoBST proofs, SHA-256 content binding, and physical freshness anchors. Proves temporal ordering and content integrity.
ENHANCED (Tier Value 2):
All CORE components plus behavioral entropy capture (Jitter Seals) and intra-checkpoint correlation. Adds evidence of interactive authoring behavior.
MAXIMUM (Tier Value 3):
All ENHANCED components plus CDCE, error topology analysis, and forgery cost bounds. Provides the strongest available evidence.

7. Attestation Assurance Levels

The attestation tier system maps to established assurance frameworks including NIST SP 800-63B Authenticator Assurance Levels (AAL), ISO/IEC 29115 Levels of Assurance (LoA), and Entity Attestation Token (EAT) security levels as defined in [RFC9711].

7.1. Tier T1: Software-Only

Binding Strength:
none or hmac_local
NIST AAL Mapping:
AAL1
Security Properties:
  • VDF timing provides temporal ordering
  • Hash chains provide tamper evidence
  • Jitter entropy provides behavioral binding
  • No hardware root of trust; keys stored in software

7.2. Tier T2: Attested Software

T2 extends T1 with optional hardware attestation hooks. The AE attempts to use platform security features (Keychain, DeviceCheck) but degrades gracefully.

7.3. Tier T3: Hardware-Bound

Requires TPM 2.0 or platform Secure Enclave key binding. Evidence generation MUST fail if hardware is unavailable. AAL3 equivalent.

7.4. Tier T4: Hardware-Hardened

Discrete TPM + PUF binding + Enclave execution. Anti-tamper evidence required. AAL3+ equivalent.

8. Profile Architecture

The PPP specification defines three implementation profiles that establish Mandatory-to-Implement (MTI) requirements for interoperability.

Table 1
Feature ID Feature Name CORE ENHANCED MAXIMUM
1 vdf-iterated-sha256 M M M
2 content-binding M M M
4 checkpoint-chain M M M
50 behavioral-entropy O M M
105 hardware-attestation O O M

9. Evidence Format and CDDL

Evidence Packets are CBOR-encoded [RFC8949] and identified by semantic tag 1347571280. The CDDL notation [RFC8610] is used to define the wire format.

      evidence-packet = {
          1 => uint,                              ; version
          2 => tstr,                              ; profile-uri
          3 => uuid,                              ; packet-id
          4 => pop-timestamp,                     ; created
          5 => document-ref,                      ; document
          6 => [+ checkpoint],                    ; checkpoints
          ? 7 => attestation-tier,                ; T1-T4
          ? 8 => [* tstr],                        ; limitations
          ? 9 => profile-declaration,             ; profile
          ? 10 => [+ presence-challenge],         ; QR/OOB proofs
          ? 18 => physical-liveness-section,      ; CDCE markers
      }

      checkpoint = {
          1 => uint,                              ; sequence (strictly monotonic)
          2 => uuid,                              ; checkpoint-id
          3 => pop-timestamp,                     ; timestamp (local)
          4 => hash-value,                        ; content-hash
          5 => uint,                              ; char-count
          6 => edit-delta,                        ; delta
          7 => hash-value,                        ; prev-hash
          8 => hash-value,                        ; checkpoint-hash
          9 => process-proof,                     ; VDF (PoBST)
          10 => jitter-binding,                   ; behavioral-entropy
          11 => physical-state,                   ; CDCE Weave
          12 => bstr .size 32,                    ; entangled-mac
      }

      document-ref = {
          1 => hash-value,                        ; content-hash
          ? 2 => tstr,                            ; filename
          3 => uint,                              ; byte-length
          4 => uint,                              ; char-count
          ? 5 => hash-salt-mode,                  ; 0=unsalted, 1=author-salted
          ? 6 => bstr,                            ; salt-commitment
      }

      process-proof = {
          1 => proof-algorithm,                   ; 1=sha256, 20=PoBST
          2 => proof-params,                      ; VDF params
          3 => bstr,                              ; input (seed)
          4 => bstr,                              ; output (root)
          5 => [+ Merkle-Proof],                  ; sampled proofs
          6 => duration,                          ; claimed time
      }

      edit-delta = {
          1 => int,                               ; added
          2 => int,                               ; deleted
          3 => uint,                              ; op-count
          ? 4 => [* edit-position],               ; [offset, change]
      }

      physical-state = {
          1 => [+ float16],                       ; thermal
          2 => uint,                              ; entropy-delta
          ? 3 => bstr,                            ; kernel-state-commitment
      }

      uuid = bstr .size 16
      pop-timestamp = #6.1(number)
      duration = float32
      hash-value = { 1 => uint, 2 => bstr }

10. VDF Mechanisms and HAT

10.1. Memory-Hard Sequential Functions (Argon2id)

The protocol requires a memory-hard sequential function to establish economic forgery bounds. Implementations MUST support Argon2id [RFC9106] as the Mandatory-to-Implement (MTI) MHSF. The default parameters for CORE profile are: Time Cost (t)=1, Memory Cost (m)=2^16, Parallelism (p)=1.

10.2. Hardware-Anchored Time (HAT)

In T3/T4 tiers, the AE MUST anchor the VDF seed to the TPM Monotonic Counter. This prevents "VDF Speed-up" attacks by ensuring that the temporal proof is bound to the hardware's internal perception of time.

11. IANA Considerations

This document requests registration of CBOR tags 1347571280 ("PPP ") and 1463894560 ("WAR "), SMI PEN 65074, and the EAT profile urn:ietf:params:rats:eat:profile:pop:1.0.

11.1. Media Types

Requests registration of application/vnd.writerslogic-pop+cbor and application/vnd.writerslogic-war+cbor.

12. Security Considerations

This section describes security considerations for implementations of the PoP protocol. Detailed forensic security analysis is provided in the companion document [PoP-Appraisal].

12.1. Relay and Replay Attacks

Relay attacks involve an adversary forwarding Evidence from a legitimate Attester to a Verifier. Replay attacks attempt to reuse previously valid Evidence Packets. Both attacks are defeated through Physical Freshness anchors that bind Evidence to non-deterministic physical state (thermal trajectories, kernel entropy) sampled at checkpoint creation time. Verifiers MUST reject Evidence where physical freshness markers are stale or inconsistent with claimed timestamps.

12.2. VDF Speed-up Attacks

An adversary with access to specialized hardware (ASICs, FPGAs) may attempt to compress VDF computation time. The memory-hard requirement of Argon2id ensures that computation speed is bounded by memory bandwidth rather than raw compute cycles. In T3/T4 tiers, Hardware-Anchored Time (HAT) binding to TPM monotonic counters provides additional protection by ensuring temporal proofs cannot be generated faster than the hardware clock allows.

12.3. Attesting Environment Compromise

A compromised Attesting Environment could generate fraudulent Evidence. The tiered attestation model (T1-T4) provides graduated trust levels. T3/T4 implementations MUST use hardware Secure Elements (TPM, SE) to protect signing keys. Evidence generated at lower tiers SHOULD be evaluated with appropriate skepticism by Relying Parties.

12.4. Jitter Simulation

Sophisticated adversaries may attempt to simulate human motor-signal randomness. The protocol relies on the computational expense of generating high-fidelity biological noise that satisfies Signal-to-Noise Ratio (SNR), Cognitive Load Correlation (CLC), and Error Topology constraints simultaneously. Forgery cost bounds in the WAR quantify this economic barrier.

12.5. Denial of Service

VDF verification is asymmetric by design—verification is orders of magnitude faster than generation. This ensures that Verifiers cannot be overwhelmed by computationally expensive verification requests. Implementations SHOULD implement rate limiting on Evidence submission endpoints.

13. References

13.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[RFC9106]
Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, , <https://www.rfc-editor.org/info/rfc9106>.
[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/info/rfc9334>.
[RFC9711]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, , <https://www.rfc-editor.org/info/rfc9711>.

13.2. Informative References

[Pietrzak2019]
Pietrzak, K., "Simple Verifiable Delay Functions", , <https://eprint.iacr.org/2018/627>.
[PoP-Appraisal]
Condrey, D., "Proof of Process (PoP): Forensic Appraisal and Security Model", Work in Progress, Internet-Draft, draft-condrey-rats-pop-appraisal-02, , <https://datatracker.ietf.org/doc/html/draft-condrey-rats-pop-appraisal-02>.

Appendix: VDF Verification Test Vectors

The following test vectors can be used to validate VDF implementations:

Input (Seed): "witnessd-genesis-v1"
  Hex: 7769746e657373642d67656e657369732d7631

Argon2id Parameters (CORE profile):
  Time Cost (t): 1
  Memory Cost (m): 65536 (2^16 KiB)
  Parallelism (p): 1
  Output Length: 32 bytes

Iterations: 10,000

Expected Output (SHA-256 of Argon2id chain):
  7d3c9a4f8b2e1d6c5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f

Author's Address

David Condrey
WritersLogic Inc
San Diego, California,
United States