Copyright © 2026 the Contributors to the Universal Manifest Specification.
This specification defines a JSON-LD-based file format known as the Universal Manifest, a portable state capsule. Formulated as a hybrid synthesis of web publication metadata and web application parameters, this format provides developers and issuers with a standardized envelope to convey linked-data identity references, role permissions, device registrations, and pointers to canonical data sources.
The Universal Manifest is specifically designed for local-first environments (e.g., venue edges, public displays) where consumers must tolerate partial connectivity and rely on cached, verifiable state. Using this standard, user agents, smart displays, and network edges can securely interoperate without requiring a continuous cloud connection, facilitating seamless cross-context experiences.
This section describes the status of this document at the time of its publication.
Universal Manifest v0.1 is the initial published version of the Universal Manifest specification. It defines the core JSON-LD envelope, lifecycle semantics, and caching model. The v0.1 format establishes the manifest structure with intentionally permissive signature semantics, allowing early adoption while a normative signature profile is developed.
Because Universal Manifest is in the v0.x line, minor-version bumps may include breaking changes when reflected by a new version folder. This version is superseded by v0.2, which introduces a normative signature profile (JCS + Ed25519), identity binding framework, and tiered trust model.
This document uses layout formats established by major web standard groups to present normative requirements cleanly.
For implementers: v0.1 adoption is discouraged for new projects. Please use the latest specification. If upgrading from v0.1, see the Migration Guide.
A Universal Manifest is a JSON-LD document acting as a cross-platform data envelope. It blends the semantic linkability of a Web Publication Manifest with the applied processing lifecycle of a Web App Manifest.
The following is an example of a minimal Universal Manifest:
{
"@context": [
"https://universalmanifest.net/ns/v0.1"
],
"@id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
"@type": ["um:Manifest"],
"manifestVersion": "0.1",
"subject": "did:example:123",
"issuedAt": "2026-03-01T00:00:00Z",
"expiresAt": "2026-03-02T00:00:00Z"
}@context memberThe @context member establishes the semantic definitions of terms used within the manifest. It MUST include the Universal Manifest namespace for the specification version being implemented (e.g., https://universalmanifest.net/ns/v0.1 for this version).
@id memberThe @id member provides a primary identifier. Issuers SHOULD generate @id as an opaque, offline-safe identifier (e.g., urn:uuid:<uuidv4>).
@type memberThe @type member indicates the document type classifying the resource. It MUST include the value um:Manifest.
subject memberThe subject member specifies the primary entity (user, app, venue) the manifest describes. It MUST contain a stable identifier URI (e.g., a Decentralized Identifier / DID).
issuedAt and expiresAt membersThe issuedAt and expiresAt members formulate the bounding constraints (TTL) for the manifest's validity. Both parameters are formatted as ISO 8601 / RFC 3339 date-time strings.
The manifest structure relies on domain-specific members akin to Web Publication linkages.
facets memberThe facets member organizes extended functional blocks (um:Facet), packaging specific verifiable capabilities, metadata subsets, or configuration modules.
claims, consents, devices, and pointersThese arrays group specific operational contexts representing permissions, deployed hardware targets, and external data reference pointers connected to the subject.
signature memberThe signature member encapsulates cryptographic proofs of the manifest payload. In v0.1, its format is intentionally permissive. No canonicalization scheme, signature algorithm, or verification profile is defined.
Note: A normative signature profile is introduced in v0.2. Implementers requiring tamper protection MUST migrate to v0.2 or later.
Reusable composable sub-documents that can be attached to a manifest. Common fields:
@type — MUST include um:Facet.name — human-readable label (optional).ref — URI to canonical source (optional).entity — embedded or referenced entity (um:Entity or JSON-LD node; optional).Base class for embedded entities. Common fields:
@id — URI.@type — entity type(s).v0.1 recommendation: Issuers generate @id as urn:uuid:<uuidv4> (opaque, globally unique, offline-safe).
Consumers cache the full manifest only while it is actively needed for rendering/interaction. Logs should store only the manifest @id (and optionally a content hash) to keep telemetry small and enable future recovery workflows.
There are two primary implementation targets: Consumer (receives and processes manifests) and Issuer (produces manifests for a subject).
A consumer MUST treat a value as a v0.1 Universal Manifest when it is a JSON object containing all required fields and @type includes um:Manifest.
A consumer MUST ignore unknown fields safely (unknown top-level properties, unknown facet entity shapes, unknown array item shapes).
Consumers MUST enforce TTL: if now > expiresAt, the manifest MUST NOT be used to grant permissions or render state.
Issuers MUST set @id to a globally unique URI. Issuers MUST set subject to a stable identifier URI. Issuers SHOULD use short TTLs for safety.
To claim conformance, an implementation MUST accept all valid fixtures and reject all invalid fixtures. The suite is language-neutral and packages fixtures plus expected outcomes.
v0.1 is a draft specification with intentionally permissive signature semantics. It MUST NOT be used in production security-critical contexts.
The v0.1 signature field is intentionally permissive and not interoperable across implementations. There is no defined canonicalization scheme, signature algorithm, or verification profile. This means:
For production use cases requiring tamper protection, implementers MUST migrate to v0.2.
All manifest consumers MUST enforce time-to-live (TTL) validity:
now > expiresAt.issuedAt <= expiresAt to detect malformed manifests.TTL enforcement provides a basic defense against replay attacks (presenting expired manifests).
To prevent denial-of-service attacks, consumers SHOULD enforce limits on manifest size and structure:
urn:uuid:<uuidv4> for @id to prevent correlation across contexts. Rotate @id per issuance.subject field to prevent tracking.