Skip to content
Universal Manifest

Universal Manifest

Universal Manifest (UM) is a portable document format for sharing identity, credentials, and preferences between systems.

In practical terms, it is a versioned JSON document that lets one system hand another system enough verified information to continue work — without building a custom data format for every pair of systems that need to talk.

The core model is simple:

  • subject identifies who or what the manifest is about (a person, device, app, or organization).
  • @id is the UMID (Universal Manifest Identifier) — a unique, stable ID you can use to fetch, log, and trace a specific manifest.
  • issuedAt and expiresAt define the manifest’s validity window. Systems must reject expired manifests.
  • Shards are optional, named sections within a manifest that group related data (for example, a publicProfile shard and a deviceRegistration shard). You include only the ones you need.
  • Pointers are URL references to data stored at its authoritative source, so you link to data instead of copying it.
  • Claims and consents are optional sections for verified assertions and user permissions.

Systems that read a manifest must safely ignore any fields they do not recognize. This means older consumers will not break when new fields are added in future versions (forward compatibility).

This repo and site are the standards host (universalmanifest.net). The spec site and the resolver service are separate by design: you look up any manifest by its UMID at the resolver (myum.net/{UMID}). A resolver is a web service that fetches a manifest by its ID.

Consuming Universal Manifests

Section titled “Consuming Universal Manifests”

The required 3-step pipeline to safely process, validate, and use a state capsule — a self-contained, time-bounded manifest snapshot.

Universal Manifest core flow pilot animation

What this helps you do

Section titled “What this helps you do”
  • Define a single, shared document format that multiple apps, devices, and services can all consume.
  • Work offline using cached data, with automatic expiration (the issuedAt/expiresAt window controls how long cached data is trusted).
  • Evolve safely across versions: consumers safely ignore fields they do not recognize, so you can add new features without breaking existing implementations.
  • Add cryptographic integrity verification (v0.2 adds a signature profile using JCS + Ed25519) without breaking v0.1 adoption paths.

Specification and implementation

Section titled “Specification and implementation”

The reference implementation is a primary design driver, but the project goal is broader:

  • A reference implementation uses the manifest as a local-first (offline-capable, no server required) capsule (edge, display, admin).
  • Future “social profile” surfaces should treat the manifest as an envelope — a wrapper document that drives projections (web profile pages, ActivityPub actor pointers — URL references to external profiles, etc.).

This is why reference implementation specifics live in integrations/ and research/, not in spec/. The specification itself is language-neutral and platform-neutral.

Choose a starting path

Section titled “Choose a starting path”

If you are new to Universal Manifest:

If you are implementing:

If you are evaluating adoption:

If you are deploying:

Next

Section titled “Next”