Spec Evolution and Contributors

How the Universal Manifest specification grew, version by version, and who shaped it.

Scope: v0.1 (15 Feb 2026) through the v0.4 working draft (June 2026).  |  Last updated: 2026-06-11.  |  Companion to the specification.

The Universal Manifest is a portable state capsule: one verifiable, cache-friendly envelope that carries who-you-are references, what-you've-permitted, the devices in play, and pointers to canonical data, designed to work even when the network is partial or absent. It did not arrive whole. It grew in four releases, each closing a concrete gap that real use surfaced, following one repeating pattern: someone describes a real need, the team finds the matching web-standards pattern, and that pattern becomes a normative mechanism in the next version.

The arc at a glance

The story, version by version

1. v0.1

   The Envelope

   Published 15 February 2026

   Establish the shape. Make it cache-safe and offline-tolerant. Defer trust on purpose.

   The initial draft defined the Universal Manifest as a JSON-LD envelope: core members, the structural state arrays (facets, claims, consents, devices, pointers) that still anchor the manifest today, a lifecycle and caching model, conformance targets for Consumer and Issuer, and time-to-live enforcement as the first line of replay defense.

   • Core members: @context, @id, @type, subject, issuedAt / expiresAt.
   • Structural state members: facets, plus the claims / consents / devices / pointers arrays that still anchor the manifest today.
   • A lifecycle and caching model: opaque identifiers, cache only while needed, log only the identifier plus an optional content hash.
   • Conformance targets (Consumer and Issuer) with a language-neutral fixture suite.
   • Time-to-live enforcement as the first line of replay defense.
   Turning point The deliberate deferred-trust decision. v0.1's signature member was intentionally permissive, with no canonicalization scheme, algorithm, or verification profile, and the draft said so plainly. This was a design decision, not an oversight: it let early adopters work with the structure while a real signature profile was developed. By shipping the envelope first and naming the signature gap explicitly, v0.1 set up the next three versions as a trust build-out.

   Attribution: Project-led (foundational draft). The top-level facets / claims / consents / pointers / devices structure laid down here is the same architecture an external reviewer later validated at a working-group meeting on 28 May 2026.

2. v0.2

   Making It Trustworthy

   Published 1 April 2026

   Turn the permissive envelope into something you can actually verify.

   v0.2 kept the v0.1 base intact and added the trust layer: a normative signature profile, an identity-binding framework with a tiered trust model, a field for claim-authenticity proofs, and conventions for cross-DID binding and agent delegation introduced as non-normative conventions.

   • A normative signature profile: JSON Canonicalization Scheme for deterministic bytes, plus Ed25519 for the signature. The 'we'll define this later' promise from v0.1 is now kept.
   • An identity-binding framework with a tiered trust model: the beginnings of the trust tiers that later versions would make normative and then extend.
   • claims[].claimProof: a field for claim-authenticity proofs, so a claim can carry its own evidence.
   • Conventions for cross-DID binding and agent delegation, introduced as non-normative conventions (which is exactly why v0.3's promotion of them is a clean, attributable step).
   Turning point The move from envelope to verifiable, credential-like object. With a real signature and claim proofs, a Universal Manifest stops being a convenient data shape and becomes something a relying party can check. This is the version where trust becomes mechanical rather than assumed.

   Attribution: Project-led (spec build-out).

3. v0.3

   Making It a Contract

   Published 19 May 2026

   Specify not just the data, but exactly what a conforming evaluator must do with it, and make it prove it did so.

   v0.3 added a normative six-stage evaluation sequence, structured receipts as the auditable output of evaluation, encrypted inline facets, and promoted several v0.2 conventions to firm requirements. It is the baseline against which v0.4 is measured.

   • A normative six-stage evaluation sequence: Arrive, Verify, Project, Consent, Compose, Receipt. Same manifest, same steps, same outcome, regardless of implementation.
   • Structured receipts: a normative receipt schema as the output of evaluation, with four outcome categories. A receipt is the auditable record of what an evaluator checked, projected, and granted.
   • Encrypted inline facets: a facet-level encryption profile with key rotation and recipient revocation, so sensitive blocks can travel inside an otherwise-readable manifest.
   • Promotions from convention to requirement: cross-DID binding, requiredTrustTier, and agent delegation all moved from v0.2's non-normative conventions to normative requirements.
   • An expanded privacy model: sealed-entry and selective-disclosure considerations for encrypted facets; v0.1's heavy 'do not trust the signature' caveat was softened now that a real signature profile existed.
   Turning point Interoperability becomes testable. Once the evaluation sequence and receipts are normative, two independent implementations can be checked against each other and against fixtures. This is the version that makes 'conformance' a meaningful claim, and the foundation the v0.4 receipt-disposition vocabulary builds directly on top of.

   Attribution: Project-led (spec build-out). The structure was independently validated by the working group shortly after.

4. v0.4

   Format Independence and Edge Interoperability

   Working draft Working draft, June 2026

   Stop being tied to one wire format, and make the multi-party and privacy-preserving flows that real use cases demand into normative mechanisms.

   v0.4 is the largest delta in the project's history. It splits into two stories: the format-independence turn (the headline change) and a use-case-driven mechanism build-out.

   • The format-independence turn: the manifest is now defined in two layers, an abstract data model (types, properties, semantics) and production rules that serialize that model into a concrete wire format. JSON-LD is reframed as the reference encoding; a second, compact binary encoding (CBOR-LD) is defined specifically to demonstrate that the abstract model is genuinely format-independent. Conformance is now defined against the abstract data model rather than the JSON-LD shape, and supporting the JSON-LD reference encoding remains sufficient for full conformance, so nothing breaks.
   • Receipts gained a real disposition vocabulary: a receipt can now record, per claim, exactly what happened, and enumerate structural entries that were present but deliberately not acted on. This is the anti-over-claim mechanism: an evaluator can prove it did not secretly read something.
   • Multi-party flows became normative: manifest forwarding and a bilateral session model. The motivating example is a healthcare handoff, where an EMT receives a manifest and must forward it to the receiving hospital with the consent chain preserved and mandatory re-verification at each hop.
   • Presentations became bound and replay-resistant: an interactive proof-of-possession binds a presentation to a specific verifier and moment, so a verified manifest cannot simply be replayed.
   • Selective disclosure and agent-scope interoperability arrived: two parties can agree on what a delegation-scope token means (a shared registry, not an ad-hoc field), and a holder can disclose a single claim, such as an issuer-asserted 'over 18' threshold, without revealing the underlying value.
   Turning point The spec stops being 'a JSON-LD format' and becomes 'an abstract standard with a reference encoding.' This is a structural reframe of the whole document: the project identified a future-proofing need, traced it to an established architecture (the DID-Core abstract-data-model pattern), and that architecture became two new sections of v0.4.

   Attribution: The zero-knowledge and selective-disclosure family was named on the record by Alfred Tom (see contributors). Format independence and the remaining mechanism build-out (receipt disposition, forwarding, bilateral sessions, presentation binding) realize requirements the use-case document had already derived, and are project-led.

   How v0.4 was hardened: two independent review rounds

   v0.4 went through an external, iterative review designed to catch the kind of internal contradiction that creeps into a large draft. Each round ran in a fresh context (less carry-over bias), wrote a new versioned file (never overwriting the prior round), and adversarially re-checked the previous round's own edits. Round one cleared the blocker class and reconciled a set of contradictions across the new v0.4 surface. Round two closed the residue and corrected three of round one's own edits, requiring HTTPS on the one unauthenticated network exchange the spec defines and surfacing the last unflagged built-in default as a visible working-group decision. The review stopped when findings became genuinely the working group's calls, not when some arbitrary count hit zero.

Contributors

Person, contribution, and where it landed. Each named contribution is backed by a dated, quoted entry in the project's internal change record; the project does not paraphrase who-asked-for-what. A named person means a specific, traceable request, recorded with its date and channel in the project's internal change record. Project-led means the project lead's own design call or an internal cleanup, with no single external requester. It is an honest label, not a stand-in for an unknown name. Where a single detail can only be confirmed by the project lead, it is marked pending confirmation rather than asserted as fact.

Project-led work

These shaped the spec but were the project lead's own design calls or internal, review-driven cleanups, with no single external requester. They are credited as project-led rather than attributed to a guessed name.

• The v0.1 envelope: the JSON-LD envelope, lifecycle and caching model, time-to-live enforcement, and the deliberate 'permissive signature, defined later' decision.
• The v0.2 trust layer: the signature profile, identity-binding framework, tiered trust model, and claim-authenticity proofs.
• The v0.3 contract layer: the six-stage evaluation sequence, structured receipts, encrypted inline facets, and the promotion of cross-DID binding, required-trust-tier, and agent delegation to normative status.
• The v0.4 format-independence turn: the abstract data model and production rules, with JSON-LD as the reference encoding and CBOR-LD added as a second encoding to prove the model is genuinely format-independent.
• The v0.4 mechanism build-out: the receipt-disposition vocabulary, manifest forwarding, the bilateral session model, and bound presentations. These realize requirements the use-case document had already derived.
• The v0.4 two-round independent review: the fresh-context, versioned, severity-converging method that hardened v0.4 into a working-group-ready working draft.

This page is the public companion to the specification. For normative definitions and the full conformance contract, read the latest specification, browse all versions, or see the terms. Attribution is quoted from the project's internal change record and is never paraphrased; details that can only be confirmed by the project lead are marked pending confirmation.