CPP - Capture Provenance Profile | Your Moments, Verifiably Sealed

What CPP Makes Verifiable — and What It Does NOT

Clear distinction between objective capture data and subjective interpretation

CPP MAKES VERIFIABLE

A capture event occurred at timestamp T
The media file has not been modified since sealing
The capture device reported location L
Removal of an event from the chain after anchoring is detectable (not covered: events removed before anchoring, and captures never recorded)
An authentication attempt occurred (optional)

CPP DOES NOT ESTABLISH

The content is "true" or "authentic"
The scene depicted actually happened
The photographer's identity
The content is free of staging or manipulation
The authenticated person is who they claim to be

Design Philosophy: "We make capture events verifiable. We do not claim they depict truth."

Target Use Cases

CPP application scope by priority

Priority A Critical

Legal Evidence

Evidence-oriented capture records (admissibility is for courts to decide)

Key: RFC 3161 TSA, chain of custody

News / Journalism

Source verification for media

Key: Deletion detection, timestamping

Priority B High

Personal Archives

Family memories with provenance

Key: Long-term verification, ease of use

Insurance Claims

Damage documentation

Key: Location evidence, timestamp evidence

Priority C Medium

Academic Research

Field data collection

Key: Integrity, reproducibility

Real Estate

Property documentation

Key: Date evidence, completeness

Threat Model

What CPP addresses and what it doesn't

Threats CPP Addresses

Backdating

Claiming capture occurred at an earlier time

Detectable via: RFC 3161 TSA external timestamp

Tampering

Modifying media after capture

Detectable via: SHA-256 hash chain, digital signature

Cherry-Picking

Deleting unfavorable captures

Detectable after anchoring via: PrevHash event chain and TSA-anchored Merkle batches (events removed before anchoring, or never recorded, are not detectable)

Fabrication

Claiming AI-generated content was captured

Not established by CPP: a capture record shows that a device recorded a capture event; it does not show that the content is not AI-generated (CPP v1.4 depth analysis indicates screen likelihood only)

Threats CPP Does NOT Address

Scene Staging

Content truth outside scope

Alternative: Human judgment, investigation

Device Compromise

Hardware security out of scope

Alternative: TEE/Secure Enclave (future)

Identity Fraud

Identity verification not claimed

Alternative: External KYC services

Network Interception

Transport security out of scope

Alternative: TLS, certificate pinning

CPP Event Model

CPP v1.0 event model (superseded). Since CPP v1.1 the specification's event types are INGEST, EXPORT and TOMBSTONE; CPP_SEAL was removed and replaced by batch anchoring.

CPP Event Lifecycle

┌─────────────────────────────────────────────────────────────────────────┐ │ CPP Event Lifecycle │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ [User Action] │ │ │ │ │ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ CAPTURE │───▶│ SEAL │───▶│ SHARE │───▶│ VERIFY │ │ │ │ │ │ │ │(optional)│ │(optional)│ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ Local Hash External Anchor │ │ Computed (RFC 3161 TSA) │ │ │ │ [Optional: Attested Capture Extension] │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ CAPTURE_ATT │ (Biometric attestation attempt recorded) │ │ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘

CAPTURE

Media Capture Initiated

Records the capture event with device ID, media hash, and timestamp.

Required Fields:

• DeviceID, MediaHash, Timestamp
• MediaType, MediaFormat
• Location (OPTIONAL)

SEAL

Cryptographic Seal Applied

Applies cryptographic seal with external timestamp anchor.

Required Fields:

• EventHash, Signature, AnchorProof
• MerkleRoot, MerkleProof
• TSA Response (RFC 3161)

SHARE

Media Shared (Optional)

Records sharing with verification link for recipients.

Required Fields:

• RecipientHash (optional)
• ShareMethod: LINK, EXPORT, AIRDROP, MESSAGE
• VerificationURL

VERIFY

Third-Party Verification (Optional)

Records when third parties verify the capture.

Required Fields:

• VerifierID
• VerificationResult
• VerificationTimestamp

Three-Layer Integrity Architecture

Cryptographic foundation for verifiable capture records

┌─────────────────────────────────────────────────────────────────┐ │ Layer 3: External Verifiability │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ RFC 3161 TSA / Blockchain / SCITT │ │ │ │ • Independent third-party timestamp │ │ │ │ • Cryptographic proof of existence at time T │ │ │ │ • Decentralized verification capability │ │ │ └───────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 2: Collection Integrity │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ RFC 6962 Merkle Tree │ │ │ │ • Batch-level completeness check │ │ │ │ • Efficient verification O(log n) │ │ │ │ • Deletion detection │ │ │ └───────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 1: Event Integrity │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ SHA-256 Hash + Ed25519 Signature │ │ │ │ • Per-event content integrity │ │ │ │ • Authenticity verification │ │ │ │ • PrevHash linking (OPTIONAL) │ │ │ └───────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘

1

Event Integrity

SHA-256 hash chain
Ed25519 signature
NO exclusion lists

2

Collection Integrity

RFC 6962 Merkle tree
Completeness Invariant (XOR)
Deletion detection

3

External Verifiability

RFC 3161 TSA (REQUIRED)
Verification URL
50+ year retention

Completeness Invariant (CI)

CPP v1.0 mechanism, removed in CPP v1.1 and shown here for reference only. Since v1.1, removal of an event is detectable through the PrevHash event chain and, after anchoring, against the TSA-anchored Merkle batch. The most recent events, if removed before they are anchored, and captures that were never recorded are not detectable.

// Completeness Invariant Structure
CI = {
  expected_count: n,                           // Number of events
  hash_sum: H(E1) ⊕ H(E2) ⊕ ... ⊕ H(En),      // XOR of all event hashes
  first_timestamp: T1,                         // Earliest event
  last_timestamp: Tn                           // Latest event
}

// Verification Algorithm
if len(events) != expected_count:
    return VIOLATION
if XOR(H(events)) != hash_sum:
    return VIOLATION
return VALID

Why XOR?

• Order-independent: A ⊕ B = B ⊕ A
• Cannot fake removal without original hash
• Constant-size regardless of event count

Detection Capability

• Single event deletion: Detected
• Multiple event deletion: Detected
• Event modification: Detected

Verification URL Architecture

CPP v1.0–v1.1 design (v1.1 §3.2 uses the path /p/{proof_id}); the later change documents up to v1.4 do not restate it. No verification service is currently operated at this address; the SLA and retention figures below are CPP v1.0 design targets, not a service commitment.

https://verify.veritaschain.org/cpp/{verification_code}

SLA

99.95% availability

Retention

50+ years

Recovery

pHash matching

CPP Extension

ACE - Attested Capture Extension

Biometric Attestation at Capture Time

"Who was holding the device when the capture occurred?"

Critical Distinction

ACE records verifiable evidence that an authentication attempt occurred.
ACE does NOT verify identity.

ACE MAKES VERIFIABLE

Biometric auth was attempted at capture time
Auth result (success/failure/score)
Potential duress (unusual patterns)

ACE DOES NOT ESTABLISH

The person is who they claim to be
Legal identity
Absence of coercion

Attestation Results

SUCCESS

Biometric matched enrolled profile

FAILURE

Biometric did not match

TIMEOUT

Auth timed out

CANCELLED

User cancelled auth

NOT_ENROLLED

No biometric enrolled on device

Key Design: Capture proceeds regardless of auth result. Auth failure is recorded, not blocking.

Zero-Knowledge Privacy Approach

"We record verifiable evidence that authentication was attempted. We store no biometric data."

What ACE Stores

Auth method used
Auth result (success/failure)
Attempt duration
Device attestation chain

What ACE Does NOT Store

Facial geometry
Fingerprint data
Biometric templates
Any biometric raw data

Conformance Levels

The Bronze / Silver / Gold levels shown below are from CPP v1.0–v1.1 and are superseded. CPP v1.4 (§8) defines five levels — CPP-BASIC, CPP-TIMESTAMPED, CPP-STANDARD, CPP-ENHANCED and CPP-FULL — and the XOR Completeness Invariant was removed in CPP v1.1. Since v1.1 the required signature algorithm is ES256 (ECDSA P-256); Ed25519 is optional.

Bronze

Hobbyists, Early Adopters

Completeness Invariant (REQUIRED)
SHA-256 + Ed25519 (MUST)
TSA: Optional
ACE: Optional

Use: Personal archives

Self-verifiable only

Silver

Families, Prosumers

Completeness Invariant (REQUIRED)
Daily RFC 3161 TSA (MUST)
Verification URL (MUST)
ACE: Optional

Use: Long-term memories

Third-party verifiable

Gold

Legal, Journalism, Enterprise

Completeness Invariant (REQUIRED)
Per-capture RFC 3161 TSA (MUST)
ACE support (REQUIRED)
Verification URL (MUST)

Use: Court evidence

Evidence-grade verifiable

Key Principle: External third-party verification (RFC 3161 TSA) is what distinguishes "Provenance Available" from mere self-attestation.

Implementation Profiles

B2B vs B2C positioning

VeraSnap

B2B Evidence Tool

"Verifiable evidence generation"

Target: Legal professionals, journalists, insurers
Conformance: Gold (mandatory)
Location: ON by default
ACE: Mandatory
TSA: Per-capture
Export: Evidence Pack (PDF + JSON + Proofs)
Pricing: Enterprise license

VeraSnap Moments

B2C Consumer Application

"Your moments, verifiably sealed"

Target: Families, travelers, memory keepers
Conformance: Silver (default), Gold (optional)
Location: OFF by default (privacy-first)
ACE: Optional with clear explanation
TSA: Daily batch (upgradable)
Export: Share link + QR
Pricing: Freemium / Perpetual verification

Pricing intent (design only; not a service commitment): verification links are meant not to expire when a subscription ends. No verification service is operated today.

C2PA Integration

Complementary positioning with Content Credentials

Aspect	C2PA	CPP
Question Answered	"How was this edited?"	"Was this media captured?"
Focus	Content provenance	Capture event provenance
Scope	Individual assets	Sequential capture records
Deletion Detection	Per-asset only	Sequence-level
Metaphor	Content passport	Capture flight recorder

Integration: CPP can embed C2PA manifests while providing additional sequence-level verifiability.

CPP IMPLEMENTATION

VeraSnap

Evidence Generation Tool — first-party implementation of CPP v1.4 by VeritasChain Co., Ltd. (iOS and Android; conformance self-declared)

VeraSnap

Evidence Generation Tool

VeraSnap is NOT a camera app. It's a professional evidence generation tool that cryptographically records capture events and data provenance in a tamper-evident manner.

RFC 3161 Timestamp Authority support

ACE biometric authentication attestation

Third-party independent verification

Verification Pack export for audit

Legal Evidence Journalism Insurance Construction

Learn More

iOS 17.0+ • Utilities

"Verify, Don't Trust."

Important: VeraSnap records capture events — it does NOT verify content truth or legitimacy.

Position within VAP Framework

CPP's position in the framework hierarchy

┌────────────────────────────────────────────────────────────────────────────┐ │ │ │ VAP (Verifiable AI Provenance Framework) │ │ Cross-domain meta-framework for AI audit trails │ │ │ └────────────────────────────────────────────┬───────────────────────────────┘ │ │ defines & maintains │ ┌────────────────────────────────────────────▼───────────────────────────────┐ │ │ │ VSO (VeritasChain Standards Organization) │ │ Independent standards organization (Tokyo, Japan) │ │ │ └────────────────────────────────────────────┬───────────────────────────────┘ │ │ publishes domain profiles │ ┌──────────┬───────────────────────┼───────────────────┬──────────┐ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ VCP │ │ CAP │ │ CPP │ │ DVP │ │ ... │ │Finance │ │Content/ │ │Capture │ │Automotive│ │ │ │Profile │ │Creative │ │Provenance│ │ Profile │ │ │ │ v1.2 │ │ v1.0 │ │ v1.4 │ │(planned)│ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ Domain-specific profile implementations

Profile Comparison

Aspect	VCP (Finance)	CAP (Content)	CPP (Capture)
Subject	Trading decisions	AI generation decisions	Media capture events
Actor	Algorithm/Trader	AI Model/Creator	Device/Photographer
Industries	Finance, Trading	Games, Film, AI Platforms	Personal, Legal, News
Core Events	SIG/ORD/EXE/CXL	INGEST/TRAIN/GEN/EXPORT	INGEST/EXPORT/TOMBSTONE
Time Precision	Nanosecond–Millisecond	Second–Minute	Millisecond–Second

Get Involved

Join the development of CPP and shape the future of capture provenance

CPP - Capture Provenance Profile

What CPP Makes Verifiable — and What It Does NOT

CPP MAKES VERIFIABLE

CPP DOES NOT ESTABLISH

Target Use Cases

Threat Model

Threats CPP Addresses

Threats CPP Does NOT Address

CPP Event Model

CPP Event Lifecycle

CAPTURE

SEAL

SHARE

VERIFY

Three-Layer Integrity Architecture

Event Integrity

Collection Integrity

External Verifiability

Completeness Invariant (CI)

Why XOR?

Detection Capability

Verification URL Architecture

ACE - Attested Capture Extension

Critical Distinction

ACE MAKES VERIFIABLE

ACE DOES NOT ESTABLISH

Attestation Results

Zero-Knowledge Privacy Approach

What ACE Stores

What ACE Does NOT Store

Conformance Levels

Bronze

Silver

Gold

Implementation Profiles

VeraSnap

VeraSnap Moments

C2PA Integration

VeraSnap

VeraSnap

Position within VAP Framework

Profile Comparison

Get Involved

CPP Specification

VAP Framework

CAP Profile

Join Development