PROTOCOL DOCS / 0.1 Technical design preview

Rights that
systems can verify.

NOT PRODUCTION

This document describes the intended architecture of Proof by AVATARZ. It is a product and security design — not a claim of deployed certification, legal enforceability or standards conformance.

UPDATED28 JUL 2026

01 / OVERVIEW

A licence token is evidence,
not currency.

Proof turns a specific permission to use a person or protected identity into a signed, machine-readable credential. The credential can be checked without calling the original production tool and can change status without rewriting history.

IT ISA signed rights credential

Identity, parties, scope, dates, duties, prohibitions and status.

IT IS NOTA bearer access token

Possession never grants rights. Every use is evaluated against actor and context.

IT IS NOTAn NFT or cryptocurrency

No speculative ownership, transferability or public-chain dependency.

IT COMPLEMENTSThe legal agreement

The contract remains authoritative; the token is its operational projection and evidence link.

02 / ARCHITECTURE

Six layers. One decision.

Proof separates concerns so a compromised media file, production provider or distribution platform cannot silently rewrite the underlying authority.

01Identity root

Verified subject, representative and organisation identifiers.

02Consent receipt

Signed evidence of informed approval; sensitive evidence remains private.

03Licence credential

Portable scope expressed as permissions, prohibitions, duties and constraints.

04Asset binding

Exact SHA-256 binding plus optional perceptual fingerprint or watermark recovery.

05Content Credential

C2PA 2.4 manifest records media provenance, ingredients and transformations.

06Status + transparency

Current revocation state and append-only issuance/event receipts.

VERIFYIdentity × signature × status × policy × asset × contextALLOW / DENY / REVIEW

03 / TOKEN LIFECYCLE

From human approval
to machine enforcement.

  1. 1

    Request

    A brand or producer submits a structured use request: purpose, script, model, territories, channels, duration and volume.

  2. 2

    Resolve authority

    Proof verifies the identity root and that the approving person or agency is authorised to act.

  3. 3

    Collect consent

    The human-readable summary and legal terms are approved. Proof hashes the signed evidence and records the consent ceremony.

  4. 4

    Compile policy

    Contract clauses are normalized into an AVATARZ ODRL profile. Ambiguity or unsupported constraints block issuance.

  5. 5

    Issue + sign

    A canonical credential is assigned an immutable ID, signed by an isolated issuer key and time-stamped.

  6. 6

    Authorize job

    Before generation, the requester, reference asset, provider, model and intended context are evaluated against the current credential.

  7. 7

    Bind outputs

    Each final asset references the licence token; its exact and optional soft bindings are recorded with C2PA provenance.

  8. 8

    Monitor + close

    Verification events, counters, expiry, suspension and revocation are appended without mutating past evidence.

04 / CREDENTIAL MODEL

Small public envelope.
Precise private evidence.

Public / portable

  • Stable token ID and schema version
  • Issuer and verification key reference
  • Pseudonymous subject and licensee IDs
  • Permissions, prohibitions and duties
  • Territory, channel, language, time and volume constraints
  • Status-list entry and evidence digests

Private / access-controlled

  • Identity documents and liveness evidence
  • Contracts, signatures and approval recordings
  • Contact details, remuneration and commercial terms
  • Internal review notes and incident evidence
  • Key ceremony and privileged audit records
ILLUSTRATIVE VC 2.0 PAYLOADJSON-LD
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "https://proof.avatarz.com/licences/AAP-LIC-2026-C91F",
  "type": ["VerifiableCredential", "AvatarzLikenessLicence"],
  "issuer": "did:web:proof.avatarz.com",
  "validFrom": "2026-07-27T14:08:19Z",
  "validUntil": "2026-09-30T23:59:59Z",
  "credentialSubject": {
    "id": "urn:avatarz:identity:marcus-vale",
    "licensee": "urn:avatarz:org:northstar-sports",
    "policy": {
      "profile": "https://proof.avatarz.com/ns/odrl/likeness/v1",
      "permissions": ["generate", "translate", "distribute"],
      "prohibitions": ["paid-media", "political-use", "model-training"],
      "territories": ["FR", "GB"],
      "channels": ["owned-social", "crm", "stadium"],
      "languages": ["fr", "en"],
      "maxAssets": 50
    },
    "consentReceipt": "sha256:0c38…c7a1"
  },
  "credentialStatus": {
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "4192",
    "statusListCredential": "https://proof.avatarz.com/status/2026-07"
  }
}

05 / GENERATION

Deterministic before
cryptographic.

The issuing service never signs raw form input. It validates, resolves, normalizes and canonicalizes the policy first, producing the same digest for semantically identical approved data.

Schema gate

Strict Zod/JSON Schema validation; unknown policy fields fail closed.

Authority gate

Representative mandate and identity status checked at issuance time.

Policy compiler

Human clauses mapped to atomic ODRL-style rules; conflicts default to invalid.

Canonical form

Stable JSON representation hashed with SHA-256 before signing.

Key operation

Ed25519/EdDSA or approved enterprise profile; private key isolated in KMS/HSM.

Trusted time

RFC 3161 time-stamp over the credential digest for long-term evidence.

Status allocation

A privacy-preserving status-list index allocated independently of identity.

Transparency receipt

Digest appended to a Merkle-based log; inclusion receipt returned.

06 / VERIFICATION

Verification returns
a reasoned decision.

01 / INTEGRITYAre these the registered bytes?

Exact cryptographic binding and optional durable recovery signal.

02 / PROVENANCEWhat happened to the media?

C2PA signer, manifest, ingredients, actions and trusted timestamp.

03 / AUTHORITYCould the issuer grant these rights?

Accreditation, representation mandate, consent and key status.

04 / USAGEIs this use permitted now?

Actor, action, territory, channel, purpose, dates and current status.

1Resolve issuer key
2Verify signature
3Check validity + status
4Evaluate policy
5Match asset
6Write receipt
Fail closed, explain clearly.

A missing key, stale status list, unknown policy term or mismatched context does not become “probably valid”. The engine returns deny or review with stable reason codes.

One decision engine, two moments.

Proof Authorize runs before generation and can return a short-lived, job-bound grant. Proof Verify inspects a credential or media use later. Both evaluate the same signed policy and current status; neither treats possession of a token as permission by itself.

CONTEXTUAL VERIFICATIONHTTP
POST /v1/verify
{
  "token_id": "AAP-LIC-2026-C91F",
  "action": "distribute",
  "context": {
    "territory": "FR",
    "channel": "owned-social",
    "language": "fr",
    "asset_sha256": "89d2c6…a01f"
  }
}

200 OK
{
  "integrity": "valid",
  "provenance": "verified",
  "authority": "verified",
  "usage": "allow",
  "reason_codes": [],
  "checked_at": "2026-07-27T18:42:11Z",
  "receipt": "pvr_01JZCC2Y…"
}

07 / C2PA BRIDGE

C2PA proves the media chain.
Proof adds the rights chain.

C2PA 2.4

What happened to the asset?

Claim generator, ingredients, edits, content bindings, claim signature and trusted time-stamp.

PROOF

Was this use authorised?

Identity authority, consent, licensee, purpose, channels, territories, dates, duties and revocation.

For each final media asset, the intended design places the Proof token URI and credential digest in a namespaced custom C2PA assertion. The C2PA manifest remains the source of media provenance. Proof evaluates the linked commercial and consent scope.

HARD BINDINGExact bytes

Cryptographic hash detects any byte-level change.

SOFT BINDINGDerived media

Fingerprint or watermark helps recover provenance after transcoding or metadata stripping.

DURABLE LOOKUPManifest recovery

Soft binding locates the repository record; signatures and hard bindings still determine integrity.

Proof C2PA Bridge Profile v0.1 — draft.

The planned assertion label is com.avatarz.proof.binding.v1. It is an AVATARZ interoperability profile, not a registered C2PA standard assertion and not a claim of C2PA conformance. It carries references and digests—not contracts, identity documents or private commercial terms.

01C2PA validates independently

Signature, timestamp, ingredients, actions and content binding are checked according to C2PA.

02Resolve the Proof reference

The verifier retrieves the signed licence by URI and confirms its digest and current status.

03Resolve issuer authority

The Trust Registry connects signing key, accreditation, mandate and protected subject.

04Evaluate declared use

Proof returns allow, deny or review with stable reason codes and a verification receipt.

CUSTOM ASSERTION BODY / ILLUSTRATIVEJSON-LD
{
  "@context": "https://proof.avatarz.com/ns/c2pa/v1",
  "profile": "https://proof.avatarz.com/profiles/c2pa-bridge/v0.1",
  "licence": {
    "id": "https://proof.avatarz.com/licences/AAP-LIC-2026-C91F",
    "credentialDigest": "sha256:55f1…a80c",
    "status": "https://proof.avatarz.com/status/2026-07"
  },
  "authorization": {
    "grantDigest": "sha256:103e…9f11",
    "providerJob": "heygen:job:demo_1042"
  },
  "binding": {
    "receipt": "https://proof.avatarz.com/receipts/pbr_01JZDB1P"
  }
}

Non-equivalence rule. A trusted C2PA manifest never means that a commercial use is authorised. A valid Proof licence never guarantees that a file has an intact Content Credential. Verification reports both layers separately.

08 / OPTIONAL CHAIN ANCHORING

Blockchain-capable.
Never blockchain-dependent.

Proof works end to end without a blockchain. Credentials are signed, status is independently resolvable, trusted time can be provided through RFC 3161, and transparency receipts can be verified against the AVATARZ append-only log. A chain adapter is an optional publication destination for selected digests — not the source of truth and never a condition for issuing or verifying a token.

CORE PROTOCOLAlways available

Identity, consent, policy, signature, asset binding, revocation and audit remain chain-agnostic.

OPTIONAL ADAPTERExternal anchor

A batch Merkle root or selected receipt digest may be published to a public, consortium or private ledger.

ADDITIONAL EVIDENCENot additional rights

The anchor corroborates existence and ordering; it cannot create consent, validate a licence or override revocation.

WHY USE IT

Neutrality across organisations

A shared external anchor can reduce reliance on AVATARZ alone when agencies, rightsholders, platforms and auditors need common evidence.

WHAT GOES ON-CHAIN

Digests, never sensitive evidence

Only batched roots, timestamps and protocol identifiers by default. No identity documents, contracts, personal data, media or commercial terms.

PORTABILITY

Replaceable by design

The adapter interface supports several networks or none. Verification continues if a partner chain is unavailable, expensive or discontinued.

PREMIUM PROFILE

Enterprise anchoring policy

Customers could choose anchor frequency, network, redundancy, retention receipts and independent audit exports as paid assurance options.

PARTNERSHIP POSITION
A credible blockchain partner may fund the adapter and become a reference deployment.

Proof would retain protocol governance, multi-chain portability and a fully functional off-chain profile. Partnership language must never imply exclusivity, token speculation, legal validity “created” by the chain or mandatory use of the partner network.

09 / SECURITY ARCHITECTURE

Keys sign facts.
Controls protect meaning.

Signing keys

Non-exportable KMS/HSM keys, least-privilege signing role, dual control for root and rotation operations.

Key discovery

Versioned public JWK set / controlled identifier; every token pins a key ID and algorithm.

Rotation

Short operational key periods, overlapping verification window, emergency revocation and historical key retention.

Data protection

TLS in transit; envelope encryption at rest; evidence separated by tenant and purpose.

Service identity

Workload identity and mutually authenticated service calls for privileged issuance paths.

Authorisation

Fine-grained policy checks; no UI role alone can sign, revoke or export sensitive evidence.

Auditability

Every privileged read, decision and key operation produces an immutable, correlated audit event.

Privacy

Pseudonymous public identifiers, minimum disclosure, status-list caching and no identity in list indexes.

10 / STATUS & REVOCATION

History is immutable.
Authority is not.

Proof never deletes or rewrites an issued credential. It publishes a signed status transition and preserves the previous state, reason, actor and effective time.

ACTIVE

Credential can be evaluated.

SUSPENDED

Temporarily blocked during review.

REVOKED

Permanently invalid for new use.

ARCHIVED

Retained as evidence only.

Distribution cannot be magically recalled. Revocation changes future verification results, triggers notices and takedown workflows, and creates evidence of non-compliant reuse.

11 / THREAT MODEL

Designed around
how proof fails.

Token tampering

Signature and canonical digest fail.

Reject
Replay in a new context

Audience, action, territory, channel and asset are re-evaluated.

Deny
Metadata stripped

Soft binding searches for the registered manifest and token.

Recover / review
Signing key compromised

Revoke key, publish incident time, re-issue unaffected credentials.

Contain
Representative loses mandate

Suspend identity authority and dependent credentials.

Suspend
Provider creates extra outputs

Asset counter and unregistered hash reveal out-of-scope media.

Flag
Status service unavailable

Use bounded cache; stale beyond policy threshold never returns allow.

Review
Malicious insider

Separation of duties, dual control and independent audit stream.

Escalate

12 / PRODUCT SURFACES

One protocol.
Several trust surfaces.

PROOF ISSUEPOST /v1/licence-requests

Request issuance; sign only after authority, consent and policy validation.

PROOF AUTHORIZEPOST /v1/authorizations

Evaluate one generation job and return a short-lived grant or reasoned refusal.

PROOF BINDPOST /v1/assets

Bind the final output, provider evidence and C2PA manifest to the authorised job.

PROOF VERIFYPOST /v1/verify

Return a contextual allow, deny or review decision with reasons.

STATUS APIGET /v1/status/:list

Cacheable signed status lists with privacy-preserving indexes.

EVENTSproof.licence.revoked

Signed webhooks for expiry, suspension, revocation and misuse.

Product names describe operational surfaces, not separate trust systems. See how Issue, Authorize, Bind and Verify form one control loop ↗

13 / GOVERNANCE

Cryptography cannot decide
who deserves trust.

Production readiness requires governance around issuer admission, identity assurance levels, representative mandates, schema changes, dispute resolution, retention, law-enforcement requests and transparent incident reporting.

External cryptographic reviewLegal review by territoryC2PA conformance testingIndependent penetration testKey compromise drillPrivacy impact assessmentRecovery and continuity testsPublished issuer policy

14 / STANDARDS & REFERENCES

Built on standards.
Explicit about extensions.