DEV Community

Cover image for VeraSnap and the IETF: One Developer's Quest to Make Digital Evidence Trustworthy in the Age of AI
VeritasChain Standards Organization (VSO)
VeritasChain Standards Organization (VSO)

Posted on

VeraSnap and the IETF: One Developer's Quest to Make Digital Evidence Trustworthy in the Age of AI

#verasnap #veritaschain #ietf #audit

TL;DR: I built VeraSnap, an iOS app that creates court-admissible photo/video evidence using RFC 3161 timestamps and Merkle trees. Along the way, I developed an open specification called CPP (Content Provenance Profile) and just published it as an IETF Internet-Draft. This is the story of why existing solutions like C2PA aren't enough for evidentiary use cases, the technical journey from idea to standard, and what I learned shipping both a consumer app and an internet standard.

Table of Contents

  1. The Problem: Why "Verified" Doesn't Mean What You Think
  2. The Landscape: C2PA, Truepic, and the Metadata Stripping Problem
  3. Introducing CPP: A Different Approach to Provenance
  4. Deep Dive: The Cryptographic Architecture
  5. VeraSnap: From Specification to App Store
  6. The IETF Journey: Publishing draft-vso-cpp-core-00
  7. Lessons Learned: Building Standards and Products Simultaneously
  8. What's Next: EU AI Act, Enterprise, and You
  9. Get Involved

1. The Problem: Why "Verified" Doesn't Mean What You Think

In January 2025, the NSA and CISA published guidance recommending "Content Credentials" for authenticating media. Google shipped C2PA support in the Pixel 10. Adobe's Firefly has generated over 6.5 billion AI images with embedded provenance metadata. The content authenticity movement has officially gone mainstream.

But here's the uncomfortable truth that security researchers like Dr. Neal Krawetz have been pointing out: strong cryptography around unverified data doesn't make the data trustworthy.

Consider this scenario: You're an insurance adjuster reviewing a claim. The claimant submits a photo with valid C2PA credentials proving it came from a Pixel 10 camera. Great! But what does that actually prove?

  1. ✅ The photo was signed by a device claiming to be a Pixel 10
  2. ✅ The metadata hasn't been tampered with since signing
  3. ❌ The scene actually looks like what's depicted
  4. ❌ The photo wasn't taken 6 months ago and submitted now
  5. ❌ The claimant didn't delete 47 other photos that contradict the claim

The last two points are critical for evidentiary use cases, and they're exactly what current solutions don't address well.

The Self-Attestation Problem

C2PA fundamentally relies on self-attestation. The device says "I captured this at 3:47 PM on January 15th." But who verifies the device's clock was accurate? Who ensures the device wasn't compromised? The answer is: you're trusting the device manufacturer's certificate chain, which ultimately means trusting that:

  • The manufacturer properly secured their signing keys
  • The device firmware wasn't tampered with
  • The device clock was synchronized correctly
  • No malicious apps had kernel-level access

For social media provenance—knowing a photo came from a real camera rather than Midjourney—this trust model is probably sufficient. For evidence that might end up in court? It's a different story.

The Omission Problem

Here's an attack that no current mainstream solution prevents:

  1. Alice takes 50 photos at a car accident scene
  2. 47 photos show Alice was clearly at fault
  3. Alice deletes those 47 photos
  4. Alice submits 3 photos with valid provenance credentials showing damage to her car
  5. Insurance adjuster has no way to know 47 photos were deleted

This is called an omission attack, and it's trivially easy to execute with any current provenance system. C2PA tracks edit history but explicitly doesn't track what was not included.

2. The Landscape: C2PA, Truepic, and the Metadata Stripping Problem

C2PA: The Industry Standard

The Coalition for Content Provenance and Authenticity (C2PA) has achieved remarkable adoption. Version 2.2 (May 2025) represents years of work by Adobe, Microsoft, Intel, and others. The specification is thorough, covering everything from JUMBF container formats to trust list management.

What C2PA does well:

  • Comprehensive edit history tracking
  • Flexible manifest chains for derived works
  • Broad industry support and tooling
  • Hardware implementations (Leica M11-P, Sony Alpha series)

What C2PA doesn't address:

  • External timestamp verification (relies on device clocks)
  • Omission detection (no way to prove completeness)
  • Metadata stripping resilience (social platforms strip JUMBF)

Truepic: The Enterprise Solution

Truepic takes a hardware-first approach, using Qualcomm's Trusted Execution Environment to sign content at the firmware level. Their "Truepic Lens" SDK runs in TEE on Snapdragon 8 Gen 3/5 platforms.

Truepic's strengths:

  • Hardware-backed signing (keys never exposed to software)
  • Built-in PKI and certificate authority
  • Strong enterprise adoption (insurance, lending)

Truepic's limitations:

  • Proprietary ecosystem
  • Requires specific hardware partnerships
  • No deletion detection

The Metadata Stripping Reality

Here's the practical problem everyone faces: social media platforms strip metadata.

Upload a photo with beautiful C2PA credentials to Twitter, Facebook, Instagram, or WhatsApp. The credentials are gone. The elaborate trust chain, the manufacturer signatures, the timestamps—all stripped in the transcoding process.

Adobe's response in 2025 is "Durable Content Credentials" combining cryptographic signatures with invisible watermarking. But watermarks are detectable and removable. It's an arms race, not a solution.

What Nobody Was Building

When I surveyed the landscape in early 2025, I noticed a gap: nobody was building for the evidentiary use case.

  • Human rights organizations like eyeWitness to Atrocities had specialized tools (85,000+ pieces of evidence collected since 2015), but they were closed ecosystems
  • ProofMode by Guardian Project was open source but lacked external timestamping
  • Enterprise solutions were proprietary and expensive
  • Consumer apps focused on social sharing, not court admissibility

I wanted something different:

  1. Open standard - Not locked to any vendor
  2. External timestamps - Provable to third parties
  3. Deletion detection - Mathematical proof of completeness
  4. Consumer accessible - Regular people, not just enterprises

This is why I created CPP.

3. Introducing CPP: A Different Approach to Provenance

The Content Provenance Profile (CPP) is an open specification I developed for cryptographically verifiable media capture provenance. It's now published as draft-vso-cpp-core-00 on the IETF datatracker.

Core Design Principles

Principle 1: Provenance ≠ Truth

CPP is explicit about what it proves and what it doesn't:

CPP Proves CPP Does NOT Prove
When media was captured (TSA timestamp) Content truthfulness
Which device captured it Scene authenticity
Cryptographic chain integrity That it wasn't staged
No events were deleted Photographer's intent

This distinction is crucial. I use the term "Provenance Available" in the UI, never "Verified" or "Authenticated." The last thing I want is users thinking CPP proves something it doesn't.

Principle 2: External Timestamp Verification

Instead of trusting the device clock, CPP requires timestamps from independent RFC 3161 Time-Stamp Authorities (TSAs). Here's why this matters:

Self-Attestation Model (C2PA):
  Device: "I captured this at 3:47 PM"
  Verifier: "Okay, I trust you"

External Verification Model (CPP):
  Device: "Here's a hash of my capture"
  TSA: "I certify this hash existed at 3:47:23.456 PM UTC"
  Verifier: "I can verify the TSA's signature independently"
Enter fullscreen mode Exit fullscreen mode

RFC 3161 timestamps have legal standing. Under the EU's eIDAS regulation, qualified timestamps enjoy a legal presumption of accuracy across all 27 member states. This isn't theoretical—timestamps from qualified TSAs are routinely accepted in court proceedings.

Principle 3: Mathematical Deletion Detection

This is CPP's signature feature: the Completeness Invariant.

When you seal a collection of evidence, CPP computes:

  • ExpectedCount: Number of events in the collection
  • HashSum: XOR of all EventHash values
  • FirstTimestamp / LastTimestamp: Time bounds

If anyone deletes an event later, recomputing the XOR won't match the sealed HashSum. The math is simple but the security property is powerful: you can prove that no events were removed from a collection.

Principle 4: Privacy by Design

  • Biometric verification happens locally; only boolean results are stored
  • Location data is optional and can be excluded from proofs
  • No central server sees your content or metadata
  • Evidence Packs are self-contained for offline verification

4. Deep Dive: The Cryptographic Architecture

Let's get technical. Here's how CPP actually works under the hood.

4.1 The Event Model

CPP organizes provenance as a chain of Events. Each event is a signed record:

{
  "EventID": "550e8400-e29b-41d4-a716-446655440001",
  "ChainID": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
  "PrevHash": "sha256:0000...0000",
  "Timestamp": "2026-01-27T10:30:00.000Z",
  "EventType": "INGEST",
  "HashAlgo": "SHA256",
  "SignAlgo": "ES256",
  "Asset": {
    "AssetHash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "AssetType": "IMAGE",
    "MimeType": "image/heic"
  },
  "EventHash": "sha256:7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730",
  "Signature": "MEUCIQDKsRwMv..."
}
Enter fullscreen mode Exit fullscreen mode

Events form a hash chain through PrevHash:

Event 1: PrevHash = sha256:0000...0000 (genesis)
Event 2: PrevHash = EventHash(Event 1)
Event 3: PrevHash = EventHash(Event 2)
Enter fullscreen mode Exit fullscreen mode

This chain provides ordering guarantees—you can't reorder events without breaking the hash chain.

4.2 Event Types

Type Purpose
INGEST Media captured from device sensor
SEAL Collection finalized with Completeness Invariant
EXPORT Proof shared externally
TOMBSTONE Legitimate deletion record

The SEAL event is particularly important—it commits the Completeness Invariant to an external timestamp, proving the collection's state at that moment.

4.3 Merkle Tree Construction with Domain Separation

This is where the IETF draft gets technical. CPP uses a binary Merkle tree to efficiently bind multiple events to a single TSA timestamp.

The Problem with Naive Merkle Trees:

If you just concatenate hashes without prefixes, an attacker might be able to construct internal node values that look like leaf values (or vice versa). This is called a second preimage attack on the tree structure.

CPP's Solution: Domain Separation

LeafHash = SHA256(0x00 || EventHash_bytes)
InternalHash = SHA256(0x01 || Left || Right)
Enter fullscreen mode Exit fullscreen mode

The single-byte prefixes (0x00 for leaves, 0x01 for internal nodes) ensure these domains can never collide.

Complete Tree Construction Algorithm:

def build_merkle_tree(event_hashes: list[str]) -> str:
    """Build Merkle tree per CPP specification."""

    # Step 1: Compute leaf hashes with domain separation
    leaves = []
    for eh in event_hashes:
        eh_bytes = bytes.fromhex(eh.replace("sha256:", ""))
        leaf = sha256(b'\x00' + eh_bytes)
        leaves.append(leaf)

    # Step 2: Pad to power of 2
    n = len(leaves)
    target = 1
    while target < n:
        target *= 2
    while len(leaves) < target:
        leaves.append(leaves[-1])  # Duplicate last leaf

    # Step 3: Build tree bottom-up
    current_level = leaves
    while len(current_level) > 1:
        next_level = []
        for i in range(0, len(current_level), 2):
            left = current_level[i]
            right = current_level[i + 1]
            parent = sha256(b'\x01' + left + right)
            next_level.append(parent)
        current_level = next_level

    return "sha256:" + current_level[0].hex()
Enter fullscreen mode Exit fullscreen mode

Why This Matters:

The draft specifically states: "CPP Merkle trees are NOT compatible with RFC 6962 (Certificate Transparency)." This was a deliberate decision. While inspired by CT's approach, CPP optimizes for the media provenance use case with different padding rules and proof structures.

4.4 TSA Anchoring

Here's the flow for getting an external timestamp:

1. Build Merkle tree from events
2. AnchorDigest = MerkleRoot (without sha256: prefix)
3. Create RFC 3161 TimeStampReq:
   - hashAlgorithm: SHA-256 (OID 2.16.840.1.101.3.4.2.1)
   - hashedMessage: AnchorDigest (32 bytes)
   - certReq: TRUE (for offline verification)
4. Submit to TSA, receive TimeStampToken
5. Store token in Evidence Pack
Enter fullscreen mode Exit fullscreen mode

The certReq: TRUE is important—it asks the TSA to include their signing certificate in the response. This enables offline verification: you can verify the timestamp without network access, using only the data in the Evidence Pack.

4.5 Verification Procedure

CPP defines five verification result codes:

Code Meaning
VALID All checks passed, including TSA signature
VALID_WARNING Crypto passed, but TSA cert chain unverifiable
INVALID Cryptographic failure
CHAIN_INTEGRITY_VIOLATION Hash chain broken
COMPLETENESS_VIOLATION Events missing from sealed collection

The verification algorithm:

def verify_cpp_proof(evidence_pack):
    # 1. Verify event signature
    if not verify_signature(event, public_key):
        return INVALID

    # 2. Recompute EventHash
    computed_hash = compute_event_hash(event)
    if computed_hash != event.EventHash:
        return INVALID

    # 3. Verify Merkle proof
    computed_root = replay_merkle_proof(
        event_hash=event.EventHash,
        leaf_index=proof.LeafIndex,
        siblings=proof.Proof,
        tree_size=proof.TreeSize
    )
    if computed_root != proof.Root:
        return INVALID

    # 4. Verify TSA token
    tsa_imprint = extract_message_imprint(tsa_token)
    if tsa_imprint != anchor_digest:
        return INVALID

    if not verify_cms_signature(tsa_token):
        return INVALID

    if not verify_cert_chain(tsa_token):
        return VALID_WARNING

    return VALID
Enter fullscreen mode Exit fullscreen mode

5. VeraSnap: From Specification to App Store

Theory is nice, but shipping is everything. I built VeraSnap to prove CPP works in practice.

Technical Stack

  • Platform: iOS 16.0+ (SwiftUI)
  • Key Storage: Apple Secure Enclave (ES256 signatures)
  • Biometrics: Face ID / Touch ID integration
  • Depth Sensing: LiDAR (iPhone Pro models)
  • TSA Providers: rfc3161.ai.moda (primary), DigiCert, Sectigo (Pro redundancy)
  • Localization: 10 languages (EN, JA, DE, ES, FR, IT, PT, KO, ZH-CN, ZH-TW)

Key Features

1. RFC 3161 Timestamping

Every capture gets an external timestamp. Free tier uses a single TSA; Pro subscribers get redundant timestamps from multiple providers for additional reliability.

// Simplified TSA request flow
func anchorToTSA(merkleRoot: Data) async throws -> TSAResponse {
    let request = TimeStampRequest(
        version: 1,
        messageImprint: MessageImprint(
            hashAlgorithm: .sha256,
            hashedMessage: merkleRoot
        ),
        certReq: true
    )

    let response = try await tsaClient.submit(request)
    guard response.status == .granted else {
        throw TSAError.requestDenied(response.status)
    }

    return response
}
Enter fullscreen mode Exit fullscreen mode

2. Biometric Binding

Optional Face ID/Touch ID verification at capture time. This proves a human was present when the photo was taken—useful for insurance claims, legal depositions, or any situation where "the camera was just sitting there" might be a concern.

The biometric result is stored as a boolean flag, not biometric data:

{
  "HumanPresence": {
    "Verified": true,
    "Method": "FaceID",
    "VerifiedAt": "2026-01-27T10:30:00.000Z"
  }
}
Enter fullscreen mode Exit fullscreen mode

3. LiDAR Screen Detection

iPhone Pro models have LiDAR sensors. I use depth analysis to detect if someone is photographing a screen (potential evidence fabrication):

func analyzeDepthForScreenCapture(depthMap: CVPixelBuffer) -> ScreenDetectionResult {
    // Compute depth variance in the scene
    let variance = computeDepthVariance(depthMap)

    // Screens have unnaturally flat depth profiles
    let flatness = computeFlatnessScore(depthMap)

    // Check for characteristic screen patterns
    let screenIndicators = detectScreenPatterns(depthMap)

    return ScreenDetectionResult(
        isLikelyScreen: flatness > threshold && variance < minVariance,
        confidence: computeConfidence(variance, flatness, screenIndicators),
        depthStatistics: computeStatistics(depthMap)
    )
}
Enter fullscreen mode Exit fullscreen mode

This isn't foolproof—it's metadata, not a guarantee. But it raises the bar for simple screen-photo attacks.

4. Completeness Invariant

When you export evidence, VeraSnap computes the Completeness Invariant:

func computeCompletenessInvariant(events: [CPPEvent]) -> CompletenessInvariant {
    var hashSum = Data(count: 32)  // All zeros

    for event in events {
        let eventHashBytes = event.eventHash.hexDecodedData()
        hashSum = xor(hashSum, eventHashBytes)
    }

    return CompletenessInvariant(
        expectedCount: events.count,
        hashSum: "sha256:" + hashSum.hexString,
        firstTimestamp: events.first!.timestamp,
        lastTimestamp: events.last!.timestamp
    )
}
Enter fullscreen mode Exit fullscreen mode

App Store Journey

Getting through Apple's review process for a cryptographic evidence app was... interesting.

Challenges faced:

  • Explaining why the app needs camera access (obvious) plus network access (TSA requests)
  • Export compliance for cryptography (France requires ANSSI notification)
  • Demonstrating the verification flow to reviewers
  • Handling TestFlight data migration between builds

Current status: Live on the App Store in 175 countries.

What Users Are Doing With It

Based on feedback and analytics, here are the main use cases:

  1. Insurance documentation: Rental car returns, move-in/move-out inspections
  2. Construction progress: Contractor accountability, milestone documentation
  3. Legal evidence: Personal injury, property disputes
  4. Personal records: Valuables inventory, condition documentation
  5. Journalism: Source material verification (pilot users from news organizations)

6. The IETF Journey: Publishing draft-vso-cpp-core-00

Building the app wasn't enough. I wanted CPP to be an open standard that anyone could implement. That meant going through the IETF.

Why IETF?

The Internet Engineering Task Force publishes RFCs (Request for Comments), the foundational standards of the internet. RFC 3161 (the timestamp protocol CPP uses) is an IETF standard. RFC 6962 (Certificate Transparency, which inspired CPP's Merkle approach) is an IETF standard.

Publishing CPP as an Internet-Draft gives it:

  • Credibility: IETF review process ensures technical rigor
  • Permanence: Datatracker archives are forever
  • Discoverability: Other standards can reference it
  • Legitimacy: Regulators and enterprises take IETF seriously

The Independent Submission Stream

IETF has multiple "streams" for publishing documents. I used the Independent Submission Stream, which:

  • Doesn't require IETF working group consensus
  • Allows Experimental/Informational category
  • Has lighter review requirements
  • Still gets IESG conflict review

The process:

  1. Write Internet-Draft in xml2rfc format
  2. Submit to datatracker (creates the draft-xxx-yyy-00 entry)
  3. Request ISE review (Independent Submissions Editor)
  4. External technical review
  5. IESG conflict review (ensure no overlap with IETF work)
  6. RFC Editor processing (if approved)

I'm currently at step 2—the draft is published and awaiting review.

Technical Decisions in the Draft

Writing for IETF reviewers is different from writing for app developers. Here are some decisions I made:

1. Explicit Domain Separation

Early versions of CPP didn't have the 0x00/0x01 prefixes. An IETF reviewer would immediately flag this as a potential second preimage vulnerability. I added domain separation before submitting.

2. TreeSize >= 1 Constraint

The original spec didn't explicitly prohibit empty trees. Edge cases like TreeSize = 0 needed to be explicitly forbidden.

3. RFC 4648 Base64 Specification

"Base64" is ambiguous—there's standard base64, base64url, with or without padding, with or without line breaks. The draft now specifies: "RFC 4648 Section 4, no whitespace, padding MUST be included."

4. VALID_WARNING Result Code

What happens when the TSA signature verifies but the certificate chain doesn't? You can't say INVALID (the crypto worked) but you can't say VALID (the trust chain is broken). I added VALID_WARNING to handle this case.

5. Completeness Invariant Security Properties

XOR is simple but has known weaknesses. The draft explicitly states: "XOR is for omission detection, NOT cryptographic commitment." This preempts the inevitable "but XOR is weak" criticism.

The Draft Document

You can read the full draft here: draft-vso-cpp-core-00

Key sections:

  • Section 4: Data model (Events, SEAL, TOMBSTONE)
  • Section 5: Merkle tree construction with domain separation
  • Section 6: TSA anchoring protocol
  • Section 7: Verification procedures
  • Appendix A: JSON examples
  • Appendix B: Test vectors with computed values

7. Lessons Learned: Building Standards and Products Simultaneously

Lesson 1: Specification-First Development

Writing the CPP specification before building VeraSnap was the best decision I made. It forced me to:

  • Think through edge cases before coding
  • Document assumptions explicitly
  • Design for interoperability from day one
  • Have a reference for testing

When I later built the Android prototype (Kotlin/Jetpack Compose), having the specification meant I could verify compatibility without reverse-engineering the iOS implementation.

Lesson 2: "Provenance ≠ Truth" Isn't Obvious

I've had to explain this principle dozens of times:

"So if I take a photo with VeraSnap, you can tell if it's real?"

No. I can tell when it was captured and by what device. I cannot tell if the scene was staged, if the subject was photoshopped before being re-photographed, or if the content is true.

This distinction is legally important. Making stronger claims invites liability. The documentation now leads with this principle.

Lesson 3: RFC 3161 TSAs Are Robust

I was worried about TSA reliability for a consumer app. What if the TSA is down? What if latency is terrible?

In practice, TSA requests complete in 200-500ms typically. I've seen 99.7%+ uptime from major providers. The network overhead is minimal—a timestamp request is ~100 bytes, the response ~2KB.

For Pro users, I added multi-TSA support. If TSA #1 fails, try TSA #2. This provides redundancy without complicating the free tier.

Lesson 4: Test Vectors Are Non-Negotiable

The IETF draft includes three test vectors with computed SHA-256 values:

Test Vector 1 (Single-Leaf):
  EventHash = sha256:7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730
  LeafHash = SHA256(0x00 || EventHash_bytes)
           = sha256:719f871f1018a17ebe199d4f0db27e3a4929f8ab3e46f5c0d30054f4b331e929
  Root = LeafHash (TreeSize=1)
Enter fullscreen mode Exit fullscreen mode

These vectors caught three implementation bugs during development. Without them, VeraSnap and any future implementation might compute different trees for the same input.

Lesson 5: Localization From Day One

VeraSnap ships in 10 languages. Adding localization later would have been painful—string extraction, context loss, layout breaks. Building it in from the start meant every new feature got translated simultaneously.

For a standard aiming at global adoption (EU AI Act, insurance companies in Japan, news organizations worldwide), this matters.

8. What's Next: EU AI Act, Enterprise, and You

EU AI Act Compliance

Article 50 of the EU AI Act requires AI-generated content to be "marked in a machine-readable format" by August 2026. The draft Code of Practice explicitly mentions:

"watermarks, metadata identifications, cryptographic methods for proving provenance and authenticity of content"

CPP is positioned as a complementary technology. While C2PA focuses on edit history and AI labeling, CPP focuses on proving capture provenance. A photo could carry both:

  • C2PA manifest: "This was captured by a Pixel 10, then edited in Lightroom"
  • CPP anchor: "The original capture existed at 3:47 PM UTC per this TSA token"

Enterprise Expansion

I'm actively exploring enterprise applications:

  • Insurance: Virtual inspections, claims documentation
  • Legal: Chain of custody, deposition exhibits
  • Construction: Progress documentation, dispute resolution
  • Healthcare: Wound documentation, telemedicine records

Enterprise requirements differ from consumer—audit logs, admin controls, API access, integration with document management systems. The CPP specification supports these use cases; VeraSnap's current implementation is consumer-focused.

The VAP Framework

CPP is actually part of a larger ecosystem I'm developing called the Verifiable AI Provenance (VAP) Framework:

  • CPP (Content Provenance Profile): Media capture provenance (this draft)
  • VCP (VeritasChain Protocol): Financial audit provenance (separate spec)
  • VAP Core: Shared cryptographic foundations

The goal is a family of specifications for different domains, all sharing common primitives.

Investment and Growth

I'm currently preparing for venture capital discussions, including with Z Venture Capital (LINE Yahoo ecosystem). The pitch:

  • Short-term: VeraSnap revenue through Pro subscriptions
  • Medium-term: Enterprise licensing and API access
  • Long-term: CPP as infrastructure for authentic content

The market opportunity is substantial—insurance ($7T+ globally), legal tech, construction, journalism, and any domain where "did this actually happen?" matters.

9. Get Involved

Try VeraSnap

📱 Download VeraSnap: App Store

Free tier includes:

  • RFC 3161 timestamped captures
  • Offline verification
  • Evidence export

Pro tier adds:

  • Multi-TSA redundancy
  • LiDAR depth analysis
  • Priority support

Read the Specification

📄 IETF Draft: draft-vso-cpp-core-00

This is the normative specification. If you're implementing CPP, this is your reference.

Contribute on GitHub

🔧 CPP Specification: github.com/veritaschain/cpp-spec
🔧 VAP Framework: github.com/veritaschain/vap-spec
🔧 VCP Protocol: github.com/veritaschain/vcp-spec

Contributions welcome:

  • Implementation feedback
  • Security analysis
  • Test vector validation
  • Localization improvements

Reach Out

  • Technical questions: File a GitHub issue
  • Partnership inquiries: Contact through VeritasChain
  • Press/Investment: Email available on request

Conclusion

Building an open standard while shipping a consumer product is a unique experience. The specification forced rigor; the app forced practicality. Each improved the other.

CPP isn't trying to replace C2PA—they solve different problems. C2PA tracks edit history for content authenticity. CPP proves capture provenance for evidentiary purposes. The world needs both.

The IETF draft is just the beginning. Getting from Internet-Draft to RFC is a long road, but having real deployment experience (VeraSnap) strengthens the case that CPP is implementable and useful.

If you're building in the content authenticity space, I'd love to hear from you. If you're an enterprise dealing with evidence documentation challenges, let's talk. If you're a developer interested in cryptographic provenance, the specs are open—go build something.

The age of AI-generated content demands new infrastructure for proving what's real. CPP is my contribution to that infrastructure. Now it's public, and I'm excited to see what others build on it.

About the Author: I'm Tokachi Kamimura, founder of VeritasChain Co., Ltd. and author of the CPP specification. I've been building cryptographic systems for [X] years and believe open standards are the foundation for trustworthy digital infrastructure. Follow the project on GitHub or try VeraSnap on the App Store.

Tags: #cryptography #ios #swift #security #ietf #standards #blockchain #timestamp #opensource #authentication

Top comments (0)