Standards Landscape
Universal Manifest exists in a landscape of established standards for identity, credentials, and data portability. This page explains where UM fits, what it builds on, and how it complements — rather than competes with — adjacent specifications.
The short version: UM is the portable state envelope. It carries identity, claims, consent, device registrations, and data pointers in one document. Other standards provide the building blocks that UM assembles and the protocols that UM documents travel over.
Standards UM builds on
Section titled “Standards UM builds on”Universal Manifest is built on established foundations, not invented from scratch.
| Standard | Role in UM |
|---|---|
| JSON-LD | Document structure. Every manifest is valid JSON. Systems that understand JSON-LD get richer semantics via the @context. |
| DIDs (Decentralized Identifiers) | Recommended format for subject identifiers (did:key:..., did:web:...). But any stable URI works — DIDs are not required. |
| JSON Schema | Structural validation. Published schemas for v0.1 and v0.2 let any validator check document conformance. |
| JCS (RFC 8785) | Deterministic JSON serialization for the v0.2 signature profile. Ensures the same logical document always produces the same bytes for signing. |
| Ed25519 | Cryptographic algorithm for v0.2 signatures. Fast, compact, and widely implemented across languages and platforms. |
How UM compares to adjacent standards
Section titled “How UM compares to adjacent standards”Comparison table
Section titled “Comparison table”| Dimension | Universal Manifest | W3C Verifiable Credentials | DIDComm | Solid Pods | OpenID Connect |
|---|---|---|---|---|---|
| What it is | Portable state document | Credential issuance and verification format | Encrypted messaging protocol between DID agents | Decentralized data storage with access control | Authentication and identity federation protocol |
| Primary purpose | Carry complete portable context (identity + claims + consent + devices + pointers) in one document | Issue and verify individual verifiable claims | Exchange messages securely between DID-based parties | Store and manage personal data with fine-grained permissions | Authenticate users and share identity tokens |
| Offline support | Built-in. TTL-based validity window enables caching and offline use. | Credential itself is portable; verification may need network. | Requires asynchronous message delivery. | Requires network access to the Pod. | Token-based; offline verification possible with JWTs. |
| Scope of data | Broad: identity, claims, consent, device registrations, data pointers, composable shards. | Narrow: individual claims with proof. | Transport-layer; carries arbitrary payloads. | Broad: any structured data, but stored rather than portable. | Narrow: authentication state and basic profile attributes. |
| Consent model | First-class, default-deny consent section travels with the document. | Not built-in; consent is handled externally. | Not built-in; application-layer concern. | Access control rules on the Pod, not in the document. | Scoped consent during auth flow only. |
| Extension model | Composable shards — add any domain-specific section without changing the core spec. | VC types and claim schemas. | Protocol extensions. | Vocabularies and shapes. | Scopes and claims in tokens. |
| Relationship to UM | — | UM can carry VCs as claims within shards. | DIDComm messages can carry UM manifests as payloads. | UM pointers reference data stored in Solid Pods. | UM can include OIDC-derived claims. |
W3C Verifiable Credentials (VCs)
Section titled “W3C Verifiable Credentials (VCs)”VCs are the established standard for issuing and verifying individual claims — a diploma, a license, a proof of age. UM is not a replacement for VCs. It is a container that can carry VCs as claims within shards.
Think of a VC as a single stamp in a passport. UM is the passport itself — it holds the stamps alongside the holder’s identity, consent preferences, device registrations, and data pointers. A system that needs the full picture reads the manifest. A system that only needs to verify a single claim can extract the VC from the relevant shard.
DIDComm
Section titled “DIDComm”DIDComm is an encrypted messaging protocol for exchanging data between DID-based agents. UM is a document format, not a messaging protocol.
The two are complementary layers: a DIDComm message could carry a UM manifest as its payload. DIDComm handles secure delivery; UM provides the structured, verifiable state document being delivered.
Solid Pods
Section titled “Solid Pods”Solid provides decentralized personal data storage with fine-grained access control. Data lives in a Pod that the user controls.
UM manifests use pointers to reference data stored in Solid Pods rather than copying it. The manifest acts as a portable summary layer — a business card with a link to the full portfolio — while Solid provides the canonical, authoritative storage. A manifest’s pointers section might include solidPod.creatorCanonical pointing to the user’s Pod, and any consumer that understands Solid can follow that pointer to get the full data.
OpenID Connect (OIDC)
Section titled “OpenID Connect (OIDC)”OIDC handles authentication and identity federation — proving that a user authenticated with a given provider and sharing basic profile attributes.
UM serves a different architectural purpose. Where OIDC tokens carry authentication state for a session, UM manifests carry a broader set of portable state: identity, credentials, preferences, consent, and device registrations. A UM manifest might include an OIDC-derived claim (for example, “this user authenticated via Google”), but the manifest is not an auth token — it is the persistent, portable context that outlasts any single authentication session.
UM is complementary, not competitive
Section titled “UM is complementary, not competitive”The key differentiator is that UM is a portable state document. It is not just a credential (like VCs), not just an auth token (like OIDC), not just a data store (like Solid), and not just a transport (like DIDComm).
UM is the one document that holds enough verified context for a receiving system to act — even offline, even without prior integration with the issuing system. It assembles building blocks from adjacent standards into a single, cacheable, consent-aware envelope.
In practice, a mature UM deployment might:
- Store canonical data in a Solid Pod.
- Reference that data via UM pointers.
- Carry W3C VCs as claims within UM shards.
- Deliver the manifest over DIDComm.
- Include OIDC-derived identity claims.
- Sign the manifest with Ed25519 (using the same key infrastructure as DIDs).
Each standard does what it does best. UM provides the envelope that ties them together.
- Why Universal Manifest? — The fragmentation problem UM solves.
- Concepts — The five core ideas behind Universal Manifest.
- Specification (v0.1) — The full technical contract.