Technical reference documentation.

1. Identity

Alethea does not accept anonymous signers. Every signature engages a human identity verified by an internationally recognized trust standard. This is what sets Alethea apart from every other provenance protocol.

1.1 Accepted identity standards

The protocol does not maintain its own identity classification. It references three sovereign standards, maintained by neutral bodies and already adopted worldwide. A compliant Alethea signature requires identity verification meeting at least one of these standards, at the minimum level indicated.

eIDAS low, NIST IAL1, ISO level 1 or 2, anonymous identifiers, and plain OAuth are not accepted by the Alethea protocol.

1.2 No Alethea trust registry

Alethea does not maintain a whitelist or blacklist of identity providers. A provider's compliance with eIDAS, NIST 800-63, or ISO 29115 is attested by the provider itself and verifiable through the public lists published by the reference bodies.

This choice is deliberate and structural. Maintaining an internal classification would turn Alethea into an authority, and therefore a capture point. By relying on eIDAS, NIST, and ISO, the protocol delegates trust to pre-existing neutral bodies whose legitimacy does not depend on us.

Verifiers (browser extensions, platforms, organizations) implement their own trust policy on top of these standards. A platform may accept eIDAS substantial minimum; an institution may require eIDAS high; a court may accept only eIDAS high or NIST IAL3.

1.3 Representation in the signature

Three fields characterize identity in an Alethea signature:

• identityProvider: string identifying the provider (e.g. fr-franceconnect-plus, de-online-ausweis, us-login-gov-ial2, onfido-standard).
• identityHash: SHA-256(provider || providerUserId || salt). The actual identity remains private at the provider.
• signerPublicKey: the cryptographic public key bound to the verified identity, used to sign the on-chain transaction.

The signature contains no Alethea-proprietary level field. The level is derived from the identityProvider via lookup in the trusted lists of the reference standards.

1.4 Privacy

The actual identity (name, ID number, and so on) is never published. Only the identityHash is on-chain. The provider keeps the mapping between hash and identity, disclosable only on judicial request, per its own terms of service and the legal framework of its jurisdiction.

2. Content fingerprints

Every signed content produces multiple fingerprints computed client-side. The content itself is never transmitted to the protocol or to the registry.

• SHA-256: exact hash. Identifies bit-identical copies.
• pHash (perceptual): perceptual image hash. Resistant to recompression, resizing, and minor color shifts.
• Chromaprint: audio fingerprinting. Highly robust to alterations.
• Per-segment hash: for video, computed in blocks (one frame per second, 4 to 60 frames). Identifies fragments even after trims or edits.

async function computeContentHash(file) {
  const buffer = await file.arrayBuffer();
  const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
  return Array.from(new Uint8Array(hashBuffer))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

2.5 Off-chain segment index

The on-chain signature stores segmentsMerkleRoot, a Merkle root over per-second pHashes. Storing every individual segment hash on-chain would be cost-prohibitive (a 60-second video means 60 hashes × 32 bytes = 1920 bytes, multiplied across every signature).

For discovery matching (e.g. "given this 15-second clip, find the original signed video it was extracted from"), the verifier needs access to the individual segment hashes, not just the Merkle root. The protocol defines a normative pattern: segments are published off-chain by the signer or their builder, and referenced via a stable handle.

Three recommended hosting patterns

• IPFS with a stable CID. The CID is bound to the signature via contextHash (or a dedicated segmentsIndexHash field planned for v0.2). Pinned by the signer or any willing pinning service. Resilient by design.
• Signer site at a stable path, e.g. /alethea/segments/<contentSha256>.json. Single point of failure, but simplest to deploy.
• Shared builder registry maintained by an Alethea-compliant infrastructure provider — a read-only public API keyed by contentSha256. Builders can mirror each other for redundancy.

Canonical segment index format

Whatever the hosting pattern, the document format is normative:

{
  "@context": "https://aletheaprotocol.com/context/v1",
  "@type": "AletheaSegmentIndex",
  "version": "0.1",

  "contentSha256":        "0xe3b0c44298fc1c149afbf4c8996fb924...",
  "segmentsMerkleRoot":   "0x9a8b7c6d...",
  "segmentDurationSec":   1.0,
  "totalSegments":        60,

  "segments": [
    { "index": 0, "phash": "0xd4a8c7f2", "timestampSec": 0.5 },
    { "index": 1, "phash": "0xd4a8c7f3", "timestampSec": 1.5 },
    { "index": 2, "phash": "0xd5a8c7f3", "timestampSec": 2.5 }
  ]
}

The document is content-addressed: its SHA-256 is the segmentsIndexHash, which may optionally be published on-chain alongside segmentsMerkleRoot (planned for v0.2). The Merkle root is verifiable against the segments array, ensuring the off-chain document was not tampered with after signing.

Persistence and best effort

The protocol does not guarantee persistence of the segment index. Keeping it available is the signer's responsibility (or their chosen builder's). If the index disappears, the on-chain signature remains valid for exact match and global pHash match, but discovery matching (finding the original from a clip) degrades.

Recommended practice: store the segment index on IPFS with pinning by at least two independent providers, and mirror to Archive.org for institutional persistence. Cost is marginal — a 1-hour video produces ~3600 segments × 32 bytes ≈ 115 KB.

3. Cryptographic signature

This is the object of the protocol. Everything else — identity, content, registry — is infrastructure. The signature is what Alethea defines normatively.

3.1 Canonical JSON-LD format

The Alethea signature is a JSON-LD object (JSON for Linking Data), for interoperability with C2PA, schema.org (ClaimReview, MediaObject), and the broader Semantic Web ecosystem. The format below is version 0.1, subject to RFC.

{
  "@context": "https://aletheaprotocol.com/context/v1",
  "@type": "AletheaSignature",
  "version": "0.1",

  "identityHash":      "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b...",
  "identityProvider":  "fr-franceconnect-plus",
  "signerPublicKey":   "0x04a1b2c3d4e5f6...",

  "contentHashes": {
    "sha256":              "0xe3b0c44298fc1c149afbf4c8996fb924...",
    "phash":               "0xd4a8c7f2",
    "chromaprint":         "0x1a2b3c4d5e6f...",
    "segmentsMerkleRoot":  "0x..."
  },

  "role":      "author",
  "timestamp": "2026-05-25T20:53:14Z",

  "contextHash":         "0x...",
  "signature":           "0x...",
  "signatureAlgorithm":  "ECDSA-secp256k1"
}

3.2 Design principles

• No URL on-chain. URLs are perishable, leak metadata, and create a dependency on builders who may disappear. The signature contains only the hash, which characterizes the content independently of its location. Same pattern as Git, IPFS, and Magnet links.
• Self-contained fingerprints. Every fingerprint needed for verification lives in the signature. No call to a builder database is required. This is the condition to stay chain-agnostic and capture-resistant.
• Hashed identity, never in clear. The identityHash field is a SHA-256(provider || providerUserId || salt). The provider keeps the mapping, disclosable only on judicial request.
• Mandatory graduated role. The role field specifies author, actor, witness, broadcaster, or reclaim. This is Alethea's distinctive conceptual contribution over C2PA and Numbers.
• Forward compatibility. The JSON-LD format allows new fields without breaking existing implementations. Any new field goes through a public RFC.

3.3 Supported cryptographic schemes

Two schemes in v0.1: ECDSA secp256k1 (Ethereum-family) and Ed25519 (Solana, superior performance). Other schemes (notably post-quantum) may be added by RFC.

3.4 On-chain projection

The JSON-LD signature is projected onto the target chain per the chain profile. Example Solidity struct (EVM profile, same for Polygon, Base, Ethereum L1):

struct AletheaSignature {
    bytes32 identityHash;
    address signerAddress;
    bytes32 identityProviderId; // e.g. keccak256("fr-franceconnect-plus")
    bytes32 contentSha256;
    bytes32 contentPhash;
    bytes32 chromaprintHash;
    bytes32 segmentsMerkleRoot;
    uint8   role;              // 1..5 (author..reclaim)
    uint64  timestamp;
    bytes32 contextHash;
    bytes   signature;         // ECDSA secp256k1
}

Target cost: less than 1 cent per signature on Polygon/Base. The signature is self-contained, no off-chain lookup required to verify.

3.5 Signing flow on the builder side

A builder (wallet, plugin, integration) implementing Alethea follows this flow. The protocol does not prescribe UX, only the normative steps.

4. Signing roles

Alethea introduces the notion of graduated signature by role. Each role engages a different responsibility. This is our main conceptual contribution above existing provenance protocols.

4.1 Normative table of the 5 roles

4.2 Detailed semantics

• ROLE 01 · author

  Author. The signer claims authorship of the content (text, photo, video, audio). The standard signature at creation. Compatible with C2PA author assertion. The most common role, base of the ecosystem.

• ROLE 02 · actor

  Actor. The signer is visibly or audibly present in the content and confirms its authenticity. Lets a visible subject (a person filmed, photographed, or interviewed) co-sign after the fact, alongside the author. A direct anti-deepfake tool: the real subject co-signs their actual appearance.

• ROLE 03 · witness

  Witness. The signer is neither the author nor the subject, but attests to what was filmed or photographed. Used in journalism, OSINT, and third-party attestation for public events. Adds a distributed trust layer: multiple independent witnesses can co-sign the same content.

• ROLE 04 · broadcaster

  Broadcaster. The signer is a relay: media outlet, platform, high-audience account, or institutional communications team. Engages editorial responsibility for the relay, not authorship. Typically signed by a legal entity (KYB) rather than a natural person.

• ROLE 05 · reclaim

  Reclaim. The signer is depicted in a piece of content (typically falsified or repurposed) and contests it. This is Alethea's distinctive conceptual contribution. The reclaim role requires the highest level among accepted standards because it carries legal force: an Alethea rebuttal can invoke article 226-8 of the French Penal Code or its international equivalents. The contextHash is mandatory for this role, so the signer can attach the detailed rebuttal (see section 5).

4.3 Co-signatures

Multiple signatures from different roles can apply to the same content, on the same chain or across chains. A verifier aggregates every signature for a given contentSha256 and presents the full picture: "Photo signed by Jean Dupont as author, co-signed by Marie Martin as actor, broadcast by Le Monde as broadcaster." Co-signing is a stronger trust signal than solo signing.

5. Context (contextHash)

The contextHash field attaches additional context to a signature without polluting the on-chain payload. It is the normative mechanism for rebuttals on the reclaim role.

5.1 Principle

The signer publishes a contextual JSON document off-chain, hosted on their own infrastructure. The contextHash on-chain is the binary SHA-256 of that document. Any verifier with the document can confirm it matches the on-chain hash.

Document persistence is the signer's responsibility. If it disappears, the signature stays valid but the context becomes unrecoverable. The on-chain hash is an integrity guarantee, not an availability guarantee.

5.2 Format of the contextual document

The document is a JSON-LD object under the same @context as the signature. Its structure is free, but the protocol publishes a canonical schema for common usages. Example for a Reclaim:

{
  "@context": "https://aletheaprotocol.com/context/v1",
  "@type": "AletheaContext",
  "purpose": "reclaim",

  "rebuttalText": "This video is an AI-generated deepfake. I never said these words. See the genuine public statement of March 12, 2026.",
  "rebuttalLanguage": "en",
  "rebuttalEvidence": [
    {
      "type": "video",
      "url": "https://maire-mulhouse.fr/declarations/intervention-2026-03-12.mp4",
      "description": "Authentic statement on March 12, 2026, Alethea-signed"
    },
    {
      "type": "document",
      "url": "https://maire-mulhouse.fr/communiques/refutation-2026-03-15.pdf",
      "description": "Official press release of rebuttal"
    }
  ],
  "rebuttalDate": "2026-03-15T14:30:00Z",
  "legalNotice": "Article 226-8 of the French Penal Code"
}

5.3 For non-Reclaim roles

The contextHash is optional but recommended for all roles. It allows the signer to attach:

• For author: description, location, editorial intent, content license.
• For witness: circumstances, exact time, other available shots, field notes.
• For actor: explicit confirmation, capture conditions, image rights.
• For broadcaster: editorial policy applied, moderation performed, content source.

5.4 Hosting best practices

The protocol does not prescribe where to host. Three recommended patterns:

• Signer's site under a stable path like /alethea/context/<hash>.json.
• IPFS with stable CID, for long-term resilience.
• Archive.org as a mirror, for institutional persistence.

Wallets and platforms may maintain a known hash → URL index to facilitate resolution, but this is never on-chain.

6. Registry (chain-agnostic)

The protocol does not prescribe a single blockchain. It defines the structure of a signature and the shape of a registry. Any infrastructure meeting these criteria may host an Alethea registry.

Registry eligibility criteria:

• Public and consultable without authorization.
• Immutable (write-once, append-only).
• Verifiable timestamp (timestamp set by the registry).
• Censorship-resistant (no single actor can erase).
• Reasonable transaction cost (target: less than €0.01 per signature).

Alethea profiles are published per supported registry, modeled on C2PA profiles. Profiles being drafted:

• · Alethea on Polygon (v0.1 reference, most favorable cost/perf ratio)
• · Alethea on Base (Ethereum L2 alternative)
• · Alethea on Ethereum L1 (high legal value case, high cost)
• · Alethea on Solana (high frequency case, native Ed25519)

Other profiles may be proposed by open RFC, including on non-blockchain registries meeting the criteria (Sigstore / transparency log pattern à la Certificate Transparency).

7. Verification

A signature has no value if it is not verified. The protocol defines normatively how a verifier must behave, what it must implement, and what thresholds it should use.

7.1 Multi-level matching algorithm

Verification proceeds in cascade. Each level is more tolerant but more expensive computationally and more permissive in matches.

• Level 1 — Exact (SHA-256). Matches a strictly identical file at the bit level. Instant lookup via on-chain index by contentSha256.
• Level 2 — Perceptual (pHash global). Computes pHash of the submitted content, looks up signatures within Hamming distance ≤ threshold. Catches recompressions, light edits, format conversions.
• Level 3 — Segmented (sliding window). For video and audio submissions, computes per-second pHashes and aligns against off-chain segment indices via sliding window. Catches trims, recuts, extracts ("this 15s short matches segments T+12s to T+27s of signed video X").
• Level 4 — Audio (Chromaprint). Specifically for audio fingerprinting on videos with significantly altered visuals but preserved audio.

def sliding_min_avg_distance(short, longer):
    """Find the best alignment of the short sequence
    in the long one. Tolerates trims, recompressions, re-encodes."""
    if len(short) > len(longer):
        short, longer = longer, short
    n, m = len(short), len(longer)
    best_avg, best_offset = None, 0
    for i in range(m - n + 1):
        total = sum(short[j] - longer[i + j] for j in range(n))
        avg = total / n
        if best_avg is None or avg < best_avg:
            best_avg, best_offset = avg, i
    return float(best_avg), best_offset

7.2 Recommended thresholds per use case

Hamming distance threshold is the trade-off knob between false positives (matching unrelated similar-looking content) and false negatives (missing genuinely derivative content). The protocol does not impose a single threshold, it recommends per use case.

Verifiers MAY adopt different thresholds, but MUST display the threshold used alongside any positive match (transparency requirement). MUST NOT silently mask matches at higher thresholds (the consumer should know the match is loose).

7.3 Verifier conformity requirements

For an implementation to declare itself "Alethea-compliant verifier", it MUST satisfy the following minimum conformity. Implementations that meet only a subset may declare "partial conformity" with the missing levels listed.

Legend: MUST = required for conformity. SHOULD = strongly recommended, partial conformity must disclose its absence.

7.4 Self-declared conformity

Builders self-declare conformity. The Alethea project does not audit verifier implementations (consistent with section 1.2 — no central authority). Builders SHOULD publish a public conformity statement at a known path, for example:

{
  "@context": "https://aletheaprotocol.com/context/v1",
  "@type": "AletheaVerifierConformity",
  "verifier": "Acme Browser Extension",
  "version": "1.4.2",
  "specVersion": "0.1",
  "conformity": {
    "exactMatch":         "MUST",
    "perceptualMatch":    "MUST",
    "segmentedMatch":     "SHOULD",
    "identityLookup":     "MUST",
    "contextResolution":  "SHOULD",
    "coSignatureAggregation": "MUST",
    "reclaimPrecedence":  "MUST",
    "thresholdTransparency": "MUST",
    "chainAgnosticQueries": "MUST (Polygon, Base, Ethereum)",
    "privacyByDesign":    "MUST"
  },
  "supportedChains":  ["polygon", "base", "ethereum-l1"],
  "supportedStandards": ["eidas", "nist-800-63", "iso-29115"],
  "publishedAt": "2026-05-25T20:53:14Z"
}

The community is encouraged to audit and challenge conformity statements publicly. Any verifier displaying an Alethea badge or claiming compatibility without meeting MUST requirements is in violation of the trademark policy (cf. governance).

8. Interoperability

Alethea fits into the existing provenance ecosystem. Position: an identity and reclaim layer on top of provenance standards, not a competitor.

• C2PA: native compatibility planned. An Alethea signature can be embedded in a C2PA manifest via a custom assertion org.aletheaprotocol.signature.
• eIDAS: direct mapping from the Alethea identity level to eIDAS levels (substantial, high). A level-4 signature satisfies strong identification requirements.
• JSON-LD: canonical export format of a signature. Context https://aletheaprotocol.com/context/v1, Schema.org-compliant schemas for ClaimReview and MediaObject.

9. Robustness to modifications

Table of common scenarios and the expected resilience of verification.

Legend: ✓ reliable detection. ~ partial detection, threshold-dependent. ✗ not detectable.

10. Security considerations

The protocol binds a verified human identity to a digital content. It does not eliminate every attack vector. This section documents the threat model and what Alethea explicitly does not protect against.

10.1 Threat model

Adversaries considered in scope:

• An attacker forging content that imitates a public figure (deepfake, voice clone, fabricated photo).
• An attacker republishing a signed content out of context to mislead viewers.
• An attacker attempting to register a signature with a stolen or coerced identity.
• A platform tampering with content fingerprints during transit or storage.
• A registry operator attempting to censor or rewrite signature history.

10.2 What Alethea protects against

• Anonymous forgery — no signature exists for the falsified content under the claimed identity, so verification returns unsigned. The absence is the proof.
• Tampering with signed content — fingerprints (SHA-256, pHash, Chromaprint) diverge beyond thresholds, verification returns no_match.
• Registry censorship — the registry is on a public blockchain. Tampering with history would require rewriting the chain, which is economically and cryptographically prohibitive on the supported profiles (Polygon, Base, Ethereum, Solana).
• Post-hoc denial — a signer cannot credibly deny a signature they emitted, because the on-chain record is timestamped and bound to their identity key.

10.3 What Alethea does NOT protect against

The protocol is not a universal truth oracle. Explicit limits:

• Identity provider compromise. Alethea trusts the upstream KYC / eIDAS / NIST provider. If the provider is breached, identity claims can be forged at the source. Verifiers SHOULD treat signatures from providers with revoked or compromised status as suspect. The protocol does not re-verify the provider's chain of trust.
• Signing under coercion. The protocol cannot detect whether a signature was emitted freely or under duress. Legal frameworks, not the protocol, address coerced consent. Some jurisdictions provide formal duress codes; Alethea does not standardize them at v0.1.
• Key theft. If a signing key is stolen, the attacker can emit signatures under the victim's identity until the key is revoked. Identity providers MUST support key revocation; verifiers MUST check revocation status at verification time. See §1.4.
• Content interpretation. A signed content is not a true content. A speaker can sign a statement that is misleading, biased, or false. The protocol attests who said it, not whether what was said is correct. Reclaim (role 05) addresses post-hoc refutation but is not arbitration.
• Offline propagation. Once a content circulates offline (print, broadcast TV stripping metadata, projected video), the link to its signature can be lost. Verifiers operating on offline-captured material SHOULD re-fingerprint and query the registry; full robustness depends on fingerprint quality and modification severity (see §9).
• Sybil attacks at the identity layer. Alethea defers to the identity provider for human uniqueness. If a provider accepts the same human under multiple distinct identities, Alethea will record them as distinct signers. Mitigated by requiring eIDAS substantial+ / NIST IAL2+ for signing roles.
• Cryptographic obsolescence. Current signature schemes (Ed25519, ECDSA P-256) are pre-quantum. Long-lived signatures MAY become forgeable in a post-quantum era. v0.2 will define a migration path to post-quantum schemes (Falcon, ML-DSA / Dilithium).

10.4 Recommendations for verifiers

1. Always check identity provider revocation status, not just signature validity.
2. Display the identity level (eIDAS substantial / high, NIST IAL2 / IAL3) to end users, not just a binary "signed / unsigned".
3. Surface the signing role explicitly. An author signature is a stronger claim than a broadcaster signature.
4. For high-stakes use cases (legal, financial, government), require multiple roles (author + witness) and reject single-role attestations.
5. Treat the absence of any Alethea signature as a meaningful signal, not a neutral state. The protocol's deterrent value depends on this asymmetry.

10.5 Naming convention

In code, JSON payloads, and registry records, role codes are lowercase: author, actor, witness, broadcaster, reclaim. In documentation, marketing copy, and user-facing UI, the same concepts are capitalized: Author, Actor, Witness, Broadcaster, Reclaim. Implementations MUST emit lowercase in machine-readable payloads.