The Journey (60 minutes)

• Part 1: Vision — Beyond the PDF/XML traps
• Part 2: Core Architecture — 4-Layer Model & HMP
• Part 3: L2 Security Deep Dive — Encryption, PRF, and WASM
• Part 4: Data Sovereignty — Web/A Folio & LoA
• Part 5: Trust & Governance — Lightweight Trust & DID-lite
• Part 6: Engineering Details — Typography & Bimodal UX
• Part 7: Status & Roadmap — Red Teaming & Standardization

What Is Sorane?

• An open-source reference implementation for verifiable web documents
• Focused on long-term readability and cryptographic trust
• Designed for public-sector workflows where PDFs fall short

Web/A vs PDF/A vs XML/XTX

4-Layer Trust Model

Human-Machine Parity (HMP)

• Human-readable HTML + machine-readable JSON-LD are bound
• Signatures guarantee both views describe the same artifact
• Verification is built into every generated document

Web/A Conformance Levels

Web/A Form Security Highlights

• Layer 1 template is signed and hash-bound
• Layer 2 payload uses Ed25519 signature
• Encryption binds AAD to layer1_ref (Anti-splicing)

Architecture Overview

flowchart TD
    User["User Input"] --> Plain["L2 Plaintext"]
    
    subgraph browser ["Browser Client"]
        Plain --> Sign["Signer (Ed25519)"]
        Sign --> Signed["L2 Signed Payload"]
        Signed --> Encrypt["Encrypter (HPKE / WASM)"]
    end
    
    Encrypt --> Envelope["L2 Encrypted Envelope"]
    
    Envelope --> Storage["Transport (Local / WebA Post)"]
    
    subgraph aggregator ["Aggregator Issuer"]
        Storage --> Decrypt["Decrypter (Strict Replay Check)"]
        Decrypt --> Verify["Signature Verifier"]
        Verify --> Data["Validated Data"]
    end

The Web/A Five Components

graph TD
    Maker[Web/A Maker] -->|1. Foundry| Form[Web/A Form]
    Maker -->|1. Foundry| Doc[Web/A Doc]
    
    Form -->|2. Input & Sign| Doc
    Doc -->|3. Ownership| Folio[Web/A Folio]
    
    Folio <-->|4. Transport| Post[Web/A Post]
    Post -->|5. Analytics| Aggregator[Aggregator]

• Foundry (Maker/Aggregator): Forging trust and aggregating results
• Interface (Form/Doc): Bimodal containers for humans and machines
• Infrastructure (Folio/Post): Sovereign ownership and routing

Hierarchical Key Derivation

flowchart TD
    Instance["SRN Master Key"] -->|HKDF org-root| Root["Org Root Key"]
    Root -->|HKDF campaign+layer1| Campaign["Campaign/Form Key"]
    
    subgraph per_form ["Per Form"]
    Campaign --> Pub["Public Key (embedded in Form)"]
    Campaign --> Priv["Private Key (used by Aggregator)"]
    end

• Zero-touch key rotation
• Isolation between campaigns and forms
• Aggregator escrow without master key exposure

WebAuthn PRF Unlock

sequenceDiagram
    participant User
    participant Browser
    participant Auth as WebAuthn/Authenticator
    
    User->>Browser: Click "Unlock with Passkey"
    Browser->>Auth: get() with PRF extension
    Auth-->>Browser: PRF Output (Seed)
    Browser->>Browser: HKDF(Seed) -> Wrap Key
    Browser->>Browser: AES-Decrypt(Wrapped Private Key)
    Browser->>Browser: Decrypt L2 Envelope
    Browser->>User: Show Plaintext Data

L2 Envelope Lifecycle

sequenceDiagram
  participant User
  participant Browser
  participant Issuer
  User->>Browser: Fill form
  Browser->>Browser: Sign payload (Ed25519)
  Browser->>Browser: Encrypt (HPKE-like)
  Browser->>Issuer: Send envelope
  Issuer->>Issuer: Decrypt + verify

Replay Protection

• Nonce is stored and strictly checked per envelope
• Security Audit v3 Requirement: Mandatory replay guard for all L2 decryptions
• CLI: JsonFileReplayStore / Browser: LocalStorageReplayStore

flowchart TB
  S[Envelope] --> N{Nonce seen?}
  N -- No --> A[Accept + Store]
  N -- Yes --> R[Reject]

Pilot Safety & Support Framework

• Pilot Safety Guide: Published boundaries for risk and responsibility
• Human Support Layer: Countermeasures for technical edge cases (backups, etc.)
• Experimental Status: Incremental trust via verified HMP evidence

Pre-Key Infrastructure Draft

• One-time recipient keys via prekey_url
• Offline submission preserved
• Fallback to static keys with warnings

Layer 3: Web/A Folio

Trust Levels & LoA

• LoA 1 (Self-Asserted): Canonical = Human-Readable. JSON is derived.
• LoA 2+ (Verified): Canonical = Machine-Readable. Human view is derived.
• Validation: Editing LoA 2+ data invalidates verified status.

The Submission Bundle

graph TD
    B[Submission Bundle] --> M[Manifest.json]
    B --> D[Docs/ HTML]
    B --> A[Attachments/ PDF]
    B --> V[VP/ Scoped Claims]
    B --> R[Verification Report]
    
    M -->|Signed| S[Manifest.sig]
    R -->|Covers| B

Toolkit Architecture

graph TD
    MD[Form.markdown] -->|parse| Schema[Schema.json]
    Data[Data.json] -->|fill| Filled[Filled.html]
    MD -->|validate| Result[Validation Result]
    Key[Passkey] -->|sign| Signed[Signed.html]

Policy DSL (Draft)

profile: onboarding
requires:
  - manifest.bundle_id
  - subject.id
rules:
  - id: vp_required_for_l3
    when: claims.level == 3
    assert: vp.exists == true

Bring Your Own AI Agent (BYOA)

• MCP (Model Context Protocol): Agents access Folio records directly
• Verified Context: AI reasons and interacts based on "Hard Evidence"
• Agency & Liberty: Use your preferred AI without platform lock-in

The "Lightweight Trust" Model

• Lower entry cost with strong verification
• Designed for gradual migration from legacy PKI
• Supports PQC transition without new infrastructure

Client Safety: Draft State

• Draft HTML embeds recovery state
• Restore across devices without data loss
• Draft files treated as sensitive artifacts

Advanced Typography Requirements

• Administrative glyph coverage (IVS/SVS)
• Faithful reproduction of official layouts (Grid fidelity)
• Zero layout shift as a security constraint

Web/A Evolution (Summary)

Engineering Progress

flowchart LR
  A[L2 Feasibility] --> B[Encrypted Form]
  B --> C[ReplayGuard Hardening]
  C --> D[WASM Migration Complete]
  D --> E[Red Team Evaluation v8]
  E --> F[Safety Guide Release]
  F --> G[Infrastructure Scale-up]

Iterative Feedback Loop

sequenceDiagram
  participant Dev as Web/A Team
  participant RT as Red Team
  participant Spec as Spec + Docs
  RT->>Dev: Findings (v2)
  Dev->>Spec: Remediation Plan
  Dev->>RT: Implementation Report
  RT->>Dev: Re-Assessment (v3)
  Dev->>Spec: Hardening Notes

Phased Adoption Strategy

Document Typology

Standardization Challenges

• Cross-device and in-person transfer protocols
• Practical holder binding in browser sandboxes
• Native browser verification support
• Long-term validation (LTV)

Key Papers

• Web/A Whitepaper
• Web/A L2 Encryption
• Web/A Folio Concept
• Re-Assessment v3

Why This Matters

• Web/A turns documents into verifiable artifacts, not just files
• Trust is portable across time, devices, and institutions
• The goal is interoperability with transparent security, not lock-in