DIAP spec
The protocol surface: consent, tokens, receipts, revocation, verification.
Digital identity needs a consent layer.
DIAP makes consent a machine check, not a manual review.
Identity use has no runtime gate
Contracts and policies do not stop an app, editor, model, or platform at execution time.
Discovery is exposure
Listing a person, voice, likeness, or style inside a product can require consent before any output exists.
Proof is fragmented
A platform needs one answer: was this use authorized, under what scope, and is that grant still valid?
Protocol Components
A modular, build-ready architecture designed for security, interoperability, and enterprise-grade deployment.
Identity Vault
Stores identity modules (voice, face, expression, motion) with KMS/HSM integration and secure enclave support. Assets never leave the vault without authorization.
Platform Visibility Service
Evaluates PVA policies in real-time. Returns allow/deny decisions with listing constraints (discoverable, invite-only, hidden).
Policy / Consent Engine
Evaluates LicenseRequests against compliance profiles. Manages approval workflows including per-render, per-project, and quota-based modes.
License Authority (Issuer)
Issues signed, PoP-bound license tokens. Manages quotas, audit logs, and delegation from the DIAP Central Authority.
Revocation Registry
Low-latency revocation checks with push-based updates and webhooks. Supports license, app, and campaign-level revocation with emergency kill switches.
Execution Gateway
The enforcement point. Verifies tokens, enforces policy, routes generation through adapters, and emits events for provenance tracking.
Provenance Service
Watermarking and receipt generation. Verification endpoints enable downstream platforms to confirm authorization of any synthetic output.
Trust Registry Service
Central directory of certified issuers, apps, keys, and revocation endpoints. The root of trust for DIAP.
Developer Portal & SDKs
Registration, key management, conformance tests, and integration examples. Integrate once, be compliant everywhere.
App Compliance Suite
Approvals dashboard, audit exports, role-based controls, and campaign management for enterprise app workflows.
Identity Modules
Identity is represented as independent modules with explicit purpose limitation and sensitivity metadata. Each module can be licensed independently.
VoiceModuleVoice embeddings and synthesis parameters
VOICE_RENDERFaceModuleFacial geometry, texture, and appearance
FACE_RENDERExpressionModuleFacial expression mapping and control
EXPRESSION_RENDERMotionModuleBody motion capture and kinematics
MOTION_RENDERFootprintModuleOptional persona metadata (not required for core auth)
Rights Taxonomy & Scope
Rights
TRAINING_USE is explicitly separate from render/inference rights.
Scope Dimensions
Approval Modes
Protocol Mechanics
Certificates, tokens, receipts, and verification endpoints — the building blocks of machine-enforceable consent.
Proof-of-Consent Certificate
VERIFIEDEvery protected output carrying a human likeness can embed a DIAP Proof-of-Consent certificate in its metadata. This proves consent existed before use.
Verification Semantics
Token Verification
Signature chain to certified issuer in Trust Registry + PoP binding + scope checks + revocation status
Receipt Verification
Signature chain + output hash match + watermark payload validation for downstream proof
Platform Verification
Distribution platforms can require valid receipts for any monetized synthetic human content
Revocation & Threat Model
Short-lived tokens reduce blast radius by limiting exposure window
Revocation Registry: revoke by license_jti, app_id, or campaign
Push-based revocation for emergency kill-switch behavior
Gateway enforcement: registry check required at render time
Threat Model
Trust Registry (Root of Trust)
The DIAP Central Authority anchors global verification through the Trust Registry. It maintains certification status and root trust keys that allow any participant to validate whether a token/receipt is authentic and whether an issuer/app is compliant.
Root Keyset
Signs Trust Registry snapshots and updates
Issuer Registry
Approved License Authorities with public keys
App Registry
DIAP-Certified apps, versions, and status
Revocation Endpoints
Per-issuer revocation check endpoints
Policy Profiles
Canonical IDs for compliance conformance tests
Key Rotation
Documented procedures for compromise response
Watermark & Modification Tracking
Every authorized output rendered under DIAP authorization carries an invisible cryptographic watermark. A separate per-pixel modification mask records exactly what AI changed — and what it didn't.
Layer 1: Authorization Watermark
Embedded in the pixels — travels with the file
A steganographic watermark encoded into the least-significant bits of the pixel data. Invisible to the human eye but machine-readable. Survives compression, re-encoding, and social media upload.
Encodes
Purpose: Public proof of authorization. Any platform, moderator, or verification tool can read this to confirm content was produced under a valid DIAP license.
Layer 2: Modification Mask
Stored in DIAP's audit trail — never in the file
A per-pixel binary map that records exactly which pixels are original and which were synthetic or modified. Stored securely in the DIAP vault, linked to the render receipt by Token ID.
Records
Purpose: Forensic audit. Proves exactly what AI did, where, and with which model. Only visible to the identity owner, their delegates, and authorized auditors.
Why Two Separate Layers?
File Size
A per-pixel modification mask for a 4K frame is ~8MB uncompressed. For a 120-minute film at 24fps, that's ~1.3TB of mask data. This cannot live in the pixels.
Quality Preservation
The more data you hide in pixels, the more artifacts you introduce. The authorization watermark is small enough to be invisible. A full modification map would degrade image quality.
Security
If the modification mask were in the file, anyone with the file could see exactly which pixels are synthetic — giving attackers a roadmap. Keeping it in the vault protects this intelligence.
Three Levels of Verification
Different participants see different depths of information. Public verification is open to everyone. Detailed modification data is restricted to the people it belongs to.
Public Verification
Anyone — platforms, moderators, audiences
Free API call, no authentication required
Returns
Does Not Return
Watermark Survival: Downloads & Distribution
The authorization watermark is embedded in the pixel data itself — not in file metadata. It travels with the content regardless of how the file is transferred, compressed, or shared.
How Verification Works in Practice
Platform verifies content
Public verificationA streaming platform receives content containing a identity owner's likeness.
Their content pipeline scans the file with DIAP's public Verification API.
The watermark is extracted → Token ID found → DIAP returns:
Deepfake detected
No watermark foundSomeone creates a deepfake of Marcus Rivera without going through DIAP.
The same platform scans the content. No DIAP watermark found.
Identity owner reviews what AI actually did
Owner verificationMarcus logs into his Identity Vault on diap.my.id.
He opens the Meridian render receipt and views the modification mask:
Modification Report — Meridian, Episode 3
Frames 4200–4847: 23% of pixels AI-modified
Model used: Nuke AI Face Enhance v3.2
Rights verified: FACE_RENDER authorized
Heatmap available: View pixel-level modification map →
Summary: What Lives Where
| Data | Stored In | Visible To | Survives Download |
|---|---|---|---|
| Authorization watermark | In the pixels (steganographic) | Anyone (public API) | Yes — travels with the file |
| Modification mask (pixel-level) | DIAP audit trail | Identity owner + delegates + auditors | N/A — not in the file |
| Render receipts | DIAP audit trail | Identity owner + delegates + auditors | N/A — not in the file |
| License status | DIAP registry (live) | Anyone (public API) | N/A — live check per request |
The watermark is the public proof that travels with every file. The modification mask is the private forensic detail secured in DIAP's vault. Together, they cover both distribution verification and detailed audit.
ScriptModule
Writer & authorship protection. A first-class protected asset type for authored writing and project literary materials — extending DIAP with consent-first script governance.
Non-goal: ScriptModule is not a replacement for copyright registration, chain-of-title, or legal guild processes. It is a technical enforcement and audit layer that ensures scripts are handled according to their owner's authorized policies inside connected systems.
Protected Writing Assets
DIAP is primarily an identity authorization protocol (voice / face / expression / motion). However, serious compliance requires protecting writing assets and their authorized downstream use — especially when scripts are used to generate derivative outputs or as training material.
Any authored writing used in development/production — screenplay drafts, outlines, treatments, bibles, pitch decks, scene text, dialogue, alt-lines, script notes, revisions.
The natural person(s) who authored the Script Asset, or an authorized rights holder/representative (estate, production company) acting on their behalf.
Any AI-assisted generation using Script Assets as input/context — new scenes, dialogue, scene variants, summaries, character breakdowns.
Using Script Assets to train/fine-tune a model, build embeddings for general reuse, or incorporate content into persistent model weights beyond the specific job.
Rights Taxonomy (Writing)
Policy Presets
Standardized policy templates that define approval modes, category blocks, provenance requirements, and audit exports. Stored as first-class policy objects.
Owner-Strict
Maximum control for public figures
Brand-Safe
Commercial use with reputational safety
Union-Ready
Union-style approvals and dispute workflows
Indie Creator
Low friction licensing with provenance
Enterprise-Verified
High assurance for products and enterprises
Education / Non-Commercial
Learning/research with strict constraints