Identify the composition boundary
Name what the standard does and what UM carries, references, or sits beside.
Registry
Every standard Universal Manifest composes with is listed here: registration criteria, conformance targets, and the full integration catalog.
Registration process
How a standard enters the registry.
Each integration follows the same four steps. The composition boundary is explicit, the profile is documented, and conformance is verified before the entry is listed.
Write the integration profile
Document what a manifest facet contains, what the receiver does with it, and what UM leaves alone.
Pass conformance
Run the conformance fixtures for the new profile. At minimum: one issuer fixture, one evaluator fixture, one projection-aware fixture.
Register
The integration is listed in the registry with its conformance target and composition boundary.
Implementer pathways
Three roles exist in a UM deployment. Each has a concrete starting point.
Whether you issue credentials, verify them, or run a wallet for a person, the path through UM has the same four stops. The conformance fixture set and the spec are the reference when you need the full detail.
Lane 01
Issuer.
Read the spec
Envelope, signature, projection rules.
Implement profile
Adopt one signature suite to start.
Run conformance
baseline-issuer fixtures pass.
Ship
Sign, publish, list yourself in the registry.
Lane 02
Evaluator / verifier.
Read the spec
The evaluation contract.
Implement pipeline
Arrive, verify, project, consent, receipt.
Run conformance
baseline-evaluator + projection-aware.
Ship
Write receipts; expose them to the subject.
Lane 03
Subject runtime / wallet.
Read the spec
Storage, projection, consent records.
Implement runtime
Hold the manifest; project on request.
Run conformance
projection-aware + revocation-aware.
Ship
Hand the user the receipts the verifier wrote.
Integration catalog
Registered integrations.
Registered
-
Trust attestation and verification for the open ecosystem. OMA3.
-
DID (Decentralized Identifiers)
Stable, decentralized identifiers that resolve to a DID Document. W3C Recommendation.
-
Verifiable Credentials (W3C VC)
Signed claims issued by one party about another, verifiable by any third party. W3C Recommendation.
-
OID4VP (OpenID for Verifiable Presentations)
Verifier-to-wallet credential presentation using OAuth 2.0 mechanics. OpenID Foundation.
-
HPKE (Hybrid Public Key Encryption)
Encrypts a payload to a recipient's public key using a hybrid scheme. IETF RFC 9180.
-
ISO mDL (Mobile Driver's Licence)
Mobile driver's licence structure, signing, and device presentation. ISO/IEC 18013-5.
-
Cryptographic proofs attached to structured data at the RDF graph level. W3C specification.
-
Browser-level signal refusing sale or sharing of personal data, with legal force in some jurisdictions.
Under evaluation
-
eIDAS 2.0 / EU Digital Identity Wallet
EU regulatory framework for digital identity wallets and qualified electronic attestations.
-
SD-JWT (Selective Disclosure JWT)
IETF draft for selectively disclosable JSON Web Tokens.
-
AnonCreds
Privacy-preserving credential format with zero-knowledge proofs. Hyperledger.
-
SCITT
Supply-chain integrity, transparency, and trust. IETF working group.
-
CBOR / COSE
Compact binary serialization and signing for constrained-device deployment profiles.
-
ActivityPub
W3C protocol for federated social networking.
-
DIDComm
Decentralized communication protocol for DID-based messaging.
-
ISO 23220 (mID)
Broader mobile identity framework beyond driver's licences. ISO.
-
glTF / VRM
3D asset and avatar interchange for portaling and avatar portability. Khronos Group / VRM Consortium.
-
OpenXR
XR runtime interfaces for cross-device manifest presentation. Khronos Group.
-
IEEE P2874 (Spatial Web)
Spatial web architecture for location-anchored manifest exchanges. IEEE.
-
RP1 / Spatial Fabric
Spatial computing protocols for place anchoring, cross-world portability, and proximity-based discovery.