Standards Positioning
Universal Manifest is built on established standards and designed to complement — not replace — existing identity, credential, and data portability efforts. This page explains what UM builds on, how it relates to adjacent standards, and what its relationship is with relevant standards bodies.
Standards UM Builds On
Section titled “Standards UM Builds On”Every foundational dependency was chosen for broad adoption, proven interoperability, and availability across programming languages and platforms.
| Standard | Source | UM Usage |
|---|---|---|
| JSON-LD 1.1 | W3C Recommendation | Document structure, vocabulary definition, semantic interoperability |
| Decentralized Identifiers (DIDs) v1.0 | W3C Recommendation | Subject identifier format (recommended, not required) |
| Verifiable Credentials Data Model v2.0 | W3C Recommendation | Claims within shards can be structured as VCs |
| JSON Canonicalization Scheme (RFC 8785) | IETF | Canonicalization in v0.2 signing/verification |
| Ed25519 (RFC 8032) | IETF | Signature algorithm in v0.2 signature profile |
| Well-Known URIs (RFC 8615) | IETF | Service discovery in the reference runtime lane |
| JSON Schema Draft 2020-12 | IETF / OpenJS Foundation | Structural validation of manifest documents |
How UM Relates to Adjacent Standards
Section titled “How UM Relates to Adjacent Standards”UM is a portable state document format. It is not a credential format, not a messaging protocol, not a storage system, and not an authentication mechanism.
W3C Verifiable Credentials
Section titled “W3C Verifiable Credentials”VCs are individual claims issued by an authority. UM is a container that can carry VCs as claims within shards. VCs are stamps in a passport; UM is the passport itself.
DIDComm
Section titled “DIDComm”DIDComm is a messaging protocol for DID-based systems. UM is a document format. A DIDComm message could carry a UM manifest as its payload. They operate at different layers.
Solid Pods
Section titled “Solid Pods”Solid provides decentralized data storage. UM manifests use pointers to reference data stored in Solid Pods. Solid provides the authoritative store; UM provides the portable, time-bounded projection.
OpenID Connect (OIDC)
Section titled “OpenID Connect (OIDC)”OIDC carries authentication state. UM carries a broader set of portable state: identity, credentials, preferences, consent, and device registrations. A UM manifest might include a claim derived from an OIDC flow, but it serves a different architectural purpose.
ActivityPub / AT Protocol
Section titled “ActivityPub / AT Protocol”Federation protocols for social networking. UM can carry pointers to ActivityPub actors and AT Protocol identities. The social integration lane demonstrates how a single manifest drives profile projections across federated social surfaces.
W3C Data Integrity
Section titled “W3C Data Integrity”W3C Data Integrity provides RDF-level signing. UM v0.2 uses JCS + Ed25519 (JSON-level) as the pragmatic first profile. A Data Integrity profile is a planned future additive option.
Relationship to Standards Bodies
Section titled “Relationship to Standards Bodies”Metaverse Standards Forum (MSF)
Section titled “Metaverse Standards Forum (MSF)”Relationship: Historical lineage. UM is descended from the Metaverse Universal Manifest (MUM) concept, created in an MSF working group. The MUM scope was metaverse cross-world identity; UM broadens this to a cross-domain standard. There is no active formal organizational relationship. The metaverse remains a first-class integration lane.
OMA3 / OMATrust
Section titled “OMA3 / OMATrust”Relationship: Active integration lane. OMATrust is the most extensively developed standards-adjacent integration in the project, with a formal assessment, dedicated fixtures, and published integration documentation. OMA3 is the consortium context; OMATrust is the product/lane context.
Relationship: Standards consumer. UM builds on JSON-LD, DIDs, and VCs. There is no formal W3C engagement. Future W3C working group participation is a possibility after broader adoption.
Relationship: Standards consumer. UM builds on RFC 8785 (JCS), RFC 8032 (Ed25519), and RFC 8615 (.well-known). There are no plans for IETF submission.
Linux Foundation
Section titled “Linux Foundation”Relationship: Documentation quality benchmark and organizational model influence. The domain architecture (separating spec governance from runtime resolution) follows the Linux Foundation model. If UM pursues foundation-hosted governance, the Linux Foundation ecosystem is a natural fit.
Standardization Intent
Section titled “Standardization Intent”Universal Manifest is currently an independent open-source specification under the Apache-2.0 license. It is not submitted to, hosted by, or governed by any formal standards body.
The decision on whether to pursue formal standardization has not been made. Prerequisites include multiple independent implementations, a stable v0.2 signature profile, a standalone conformance test suite, and external adoption evidence.
Adopters do not need to wait for formal standardization. The specification is public, schemas are published at stable URLs, conformance requirements are documented, and the license permits unrestricted use.
Summary
Section titled “Summary”| Body | Relationship | Status | Future |
|---|---|---|---|
| MSF | Historical lineage | No active relationship; MUM origin acknowledged | Open to contributing back |
| OMA3 / OMATrust | Active integration lane | Assessed, documented, fixtures complete | Deepen as OMATrust matures |
| W3C | Standards consumer | Building on JSON-LD, DIDs, VCs | Possible future engagement |
| IETF | Standards consumer | Building on RFC 8785, 8032, 8615 | No plans for submission |
| Linux Foundation | Model influence | Documentation benchmark | Natural fit if hosted governance pursued |