# Universal Manifest -- Terms v0.3 Last updated: 2026-06-03 Spec version: v0.3 Total terms: 45 (43 active, 1 replaced, 1 removed) Permalink: https://universalmanifest.net/terms/v0.3/ --- ## The Document ### Universal Manifest JSON-LD document acting as a cross-platform signed data envelope. A JSON-LD document acting as a cross-platform data envelope. It blends semantic linkability with a processing lifecycle, carrying identity references, claims, consents, device registrations, and pointers within a cryptographically signed envelope. - **Spec:** Section 1 Universal Manifest (`/spec/v0.3/#universal-manifest`) - **Site:** Homepage (`/`) - **Aliases:** UM - **Change history:** v0.3 -- introduced ### Portable state capsule Formal genre description: a self-contained document conveying a snapshot of state. The spec's formal genre description of what a Universal Manifest is. A state capsule is a self-contained document that can be moved between systems to convey a snapshot of state. - **Spec:** Abstract (`/spec/v0.3/#abstract`) - **Site:** Homepage (`/`) - **Change history:** v0.3 -- introduced ### Envelope Outer JSON-LD wrapper containing context, subject, signature, and all arrays. The outer structure of the manifest document: the JSON-LD wrapper containing @context, @id, subject, timestamps, signature, and all structural arrays (facets, claims, consents, devices, pointers). The envelope is what arrives at an evaluator; its contents are what get evaluated. - **Spec:** Section 1.4 Structural State Members (`/spec/v0.3/#structural-state-members`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Facet Composable sub-document within a manifest packaging a specific capability. A composable sub-document within a manifest. A facet packages a specific verifiable capability, metadata subset, or configuration module. Facets are the primary unit of granularity for selective disclosure, consent, encryption, and receipt recording. - **Spec:** Section 2.1 um:Facet Module (`/spec/v0.3/#umfacet-module`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Entity Base classification for the payload inside a facet. The base classification for embedded configurations, representations, or states within a facet. An entity is the payload inside a facet -- the um:Entity base type. - **Spec:** Section 2.2 um:Entity Base (`/spec/v0.3/#umentity-base`) - **Change history:** v0.3 -- introduced ### Claims, Consents, Devices, Pointers The four structural arrays in every manifest envelope. The four structural arrays in a manifest. Claims carry assertions about the subject. Consents carry per-purpose authorization records. Devices carry hardware registrations. Pointers carry references to external resources, including agent delegation. - **Spec:** Section 1.4.2 Structural State Arrays (`/spec/v0.3/#arrays`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced --- ## Identity and Roles ### Evaluator Party that receives and processes a Universal Manifest. The party that receives and processes a Universal Manifest. An evaluator runs the evaluation sequence on a manifest, produces a structured receipt, and records what it did. In a bilateral exchange, both parties act as evaluators of each other's manifests. - **Spec:** Section 4.1 Evaluator Behavior (`/spec/v0.3/#required-behavior-consumer`) - **Site:** How It Works (`/how-it-works/`) - **Aliases:** consumer, receiver - **Peer review:** Yes - **Change history:** v0.3 -- introduced (Replaces W3C consumer/receiver) ### Issuer Party that signs a credential or claim, backing it with their reputation. The party that signs a credential or claim, putting their reputation behind it. The issuer's DID and signing key appear in the claim's proof chain. Standard W3C/VC terminology. In UM, the claims[].issuer field names this role. - **Spec:** Section 1.4.3 claims Array Schema (`/spec/v0.3/#claims-schema`) - **Change history:** v0.3 -- introduced ### Holder Party that assembles and signs the manifest envelope. The party that assembles and signs the manifest envelope. The holder chooses which facets, claims, and consents to include. In most cases the holder is the manifest subject. Standard W3C/VC terminology. - **Spec:** Section 4.2 Holder Behavior (`/spec/v0.3/#required-behavior-issuer`) - **Change history:** v0.3 -- introduced ### Subject The entity -- person, app, venue, agent -- that a manifest describes. The entity (person, app, venue, agent) that a manifest describes. The subject is identified by a stable URI, typically a DID. - **Spec:** Section 1.3.2 subject member (`/spec/v0.3/#subject-member`) - **Change history:** v0.3 -- introduced ### Attester Third party that vouches for a claim or cross-DID binding. A third party that vouches for a claim or a cross-DID binding. The attester's DID and method appear in identity.crossDidBinding claims. Synonym for "issuer" in the EAS and OmaTrust ecosystems. - **Spec:** Section 6.4.4 Cross-DID Binding (`/spec/v0.3/#cross-did-binding`) - **Aliases:** attestor - **Change history:** v0.3 -- introduced ### Relying party Evaluator that makes decisions based on a manifest's verified content. An evaluator that makes decisions based on the verified content of a manifest. Standard identity terminology used in the spec's security and trust-tier sections. - **Spec:** Section 6.4.2 Tiered Trust (`/spec/v0.3/#tiered-trust`), Section 6.4.5 requiredTrustTier (`/spec/v0.3/#required-trust-tier`) - **Change history:** v0.3 -- introduced --- ## Processing Sequence ### Evaluation sequence The normative six-stage processing sequence every evaluator executes. The normative six-stage processing sequence every conformant evaluator executes when a manifest arrives: Arrive, Verify, Project, Consent, Compose, Receipt. The stage names are unchanged from v0.3. - **Spec:** Section 3.1 Evaluation Sequence (`/spec/v0.3/#receiver-pipeline`) - **Site:** How It Works (`/how-it-works/`) - **Aliases:** receiver pipeline, evaluation pipeline - **Peer review:** Yes - **Change history:** v0.3 -- introduced (Replaces receiver pipeline) ### Stage 1: Arrive Manifest is received, parsed, and required properties confirmed. The manifest is received. The evaluator parses the JSON, confirms required properties, and discards unknown fields. If parsing fails, the sequence terminates with a rejected receipt. - **Spec:** Section 3.1.1 Stage 1: Arrive (`/spec/v0.3/#pipeline-arrive`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Stage 2: Verify Cryptographic signature and freshness (TTL) are verified. The evaluator verifies cryptographic integrity (signature) and freshness (TTL). Includes revocation check if applicable. If verification fails, the manifest is rejected. - **Spec:** Section 3.1.2 Stage 2: Verify (`/spec/v0.3/#pipeline-verify`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Stage 3: Project Evaluator extracts only the facets and claims relevant to its context. The evaluator extracts only the facets, claims, and pointers relevant to its processing context. Selective disclosure is holder-controlled: the holder decides which facets are included. Facets not included were not disclosed for this interaction. - **Spec:** Section 3.1.3 Stage 3: Project (`/spec/v0.3/#pipeline-project`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Stage 4: Consent Per-facet consent records are evaluated before acting on facet data. The evaluator evaluates per-facet consent records before acting on facet data. Checks scope, purpose, and expiry. Encrypted facets without a decryption key are treated as sealed entries. - **Spec:** Section 3.1.4 Stage 4: Consent (`/spec/v0.3/#pipeline-consent`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Stage 5: Compose Evaluator assembles the processing result into one of four outcomes. The evaluator assembles the processing result into one of four outcome categories: accepted, accepted-with-warnings, accepted-partial, or rejected. - **Spec:** Section 3.1.5 Stage 5: Compose (`/spec/v0.3/#pipeline-compose`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Stage 6: Receipt Evaluator produces a structured receipt recording what the sequence did. The evaluator produces a structured receipt that honestly records what the evaluation sequence did. This is the terminal output. It must not omit failed checks or suppress negative outcomes. - **Spec:** Section 3.1.6 Stage 6: Receipt (`/spec/v0.3/#pipeline-receipt`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Compose outcomes Four possible results: accepted, accepted-with-warnings, accepted-partial, rejected. The four possible results of running the evaluation sequence: accepted, accepted-with-warnings, accepted-partial, rejected. These are machine-readable enum values that double as readable labels. - **Spec:** Section 3.1.5 Stage 5: Compose (`/spec/v0.3/#pipeline-compose`) - **Site:** How It Works (`/how-it-works/`) - **Aliases:** four compose outcomes - **Change history:** v0.3 -- introduced --- ## Privacy and Data Control ### Selective disclosure Holder-controlled mechanism determining which facets appear in a manifest instance. The mechanism by which a holder controls which facets are included in a manifest instance for a given evaluator. In UM, selective disclosure is holder-controlled: the holder decides which facets appear, not the evaluator. Stage 3: Project implements this. - **Spec:** Section 3.1.3 Stage 3: Project (`/spec/v0.3/#pipeline-project`) - **Site:** How It Works (`/how-it-works/`) - **Aliases:** projection - **Peer review:** Yes - **Change history:** v0.3 -- introduced (Replaces 'projection' as user-facing heading) ### Sealed entry Encrypted facet that a given evaluator cannot decrypt. An encrypted facet in the manifest that a given evaluator cannot decrypt. Sealed entries travel with the manifest but remain unreadable to evaluators without the decryption key. The receipt records what happened with sealed entries. - **Spec:** Section 2.3 Encrypted Facets (`/spec/v0.3/#encrypted-facets`) - **Site:** How It Works (`/how-it-works/`) - **Peer review:** Yes - **Change history:** v0.3 -- introduced ### Encrypted facets (JWE inline profile) Facet whose payload is encrypted using JWE; only keyed recipients can read it. A facet whose entity payload is encrypted using JWE (JSON Web Encryption). Only designated recipients with the appropriate decryption key can read the contents. All other evaluators see the facet as a sealed entry. - **Spec:** Section 2.3 Encrypted Facets (`/spec/v0.3/#encrypted-facets`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Two-layer privacy model Combined effect of selective disclosure (visibility) and encryption (readability). The combined effect of selective disclosure (which facets are included) and encryption (which facets are readable). The spec describes this as: "projection controls visibility; encryption controls readability." The concept exists without needing its own label. - **Spec:** Section 7 Privacy Considerations (`/spec/v0.3/#privacy-considerations`) - **Change history:** v0.3 -- introduced --- ## Trust and Verification ### Authenticity Property that a manifest's signature and claims are genuine and traceable. The property that a manifest and its claims are genuine: the signature came from a known key, and specific claims can be traced back to their issuers. Authenticity is enforced in Stage 2 (Verify) and recorded in Stage 6 (Receipt). - **Spec:** Section 6.4 Identity Binding (`/spec/v0.3/#identity-binding-claim-authenticity`), Section 1.6 Signature Profile (`/spec/v0.3/#signature-profile-a`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Signature profile Combination of canonicalization method and signing algorithm for integrity. The specific combination of canonicalization method and signing algorithm used for manifest integrity. v0.3 defines the first normative profile: JCS (RFC 8785) + Ed25519. - **Spec:** Section 1.6 Signature Profile A (`/spec/v0.3/#signature-profile-a`) - **Change history:** v0.3 -- introduced ### Tiered trust model Four additive trust tiers for claim verification, from self-asserted to multi-party. Four trust tiers for claim verification, each strictly additive. Tier 0: signature-only. Tier 1: attested or claimProof-backed. Tier 2: cryptographic binding via zero-knowledge proof. Tier 3: multi-party ceremony (future). Relying parties choose based on their threat model. - **Spec:** Section 6.4.2 Tiered Trust Model (`/spec/v0.3/#tiered-trust`) - **Change history:** v0.3 -- introduced ### requiredTrustTier Declaration specifying the minimum trust tier before acting on data. A declaration at manifest, claim, or facet level specifying the minimum trust tier a relying party must satisfy before acting on the associated data. - **Spec:** Section 6.4.5 requiredTrustTier Declaration (`/spec/v0.3/#required-trust-tier`) - **Change history:** v0.3 -- introduced ### claimProof Optional field on a claim carrying a Verifiable Presentation or attestation. An optional field on any claim object carrying a Verifiable Presentation or attestation proof. Named deliberately to avoid collision with the W3C VCDM evidence property. - **Spec:** Section 6.4.3 claimProof Field (`/spec/v0.3/#claim-proof`) - **Change history:** v0.3 -- introduced ### Cross-DID binding Claim asserting that multiple DIDs are controlled by the same entity. A claim type (identity.crossDidBinding) asserting that multiple DIDs are controlled by the same entity. Requires an attester. Does not prove control by itself; relying parties must trust the attester. - **Spec:** Section 6.4.4 Cross-DID Binding Claim (`/spec/v0.3/#cross-did-binding`) - **Change history:** v0.3 -- introduced --- ## Receipt and Contract ### Structured receipt Machine-readable record of what the evaluator did with the manifest. The terminal output of the evaluation sequence. A machine-readable record of what the evaluator did with the manifest. Required fields include manifestId, outcome, signatureCheck, and freshnessCheck. - **Spec:** Section 3.3 Structured Receipts (`/spec/v0.3/#structured-receipts`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced ### Evaluation contract Normative obligations every conformant evaluator must meet. The normative obligations every conformant evaluator must meet: execute the six-stage evaluation sequence, produce a structured receipt, and record honestly what was checked, accepted, refused, or sealed. The contract governs how the evaluator processes, not what it accepts. - **Spec:** Section 4.1 Evaluator Behavior (`/spec/v0.3/#required-behavior-consumer`) - **Site:** How It Works (`/how-it-works/`) - **Aliases:** receiver-behavior promise, receiver-behavior contract - **Peer review:** Yes - **Change history:** v0.3 -- introduced (Replaces receiver-behavior promise/contract) ### Controls + assurances Two active controls and two recorded assurances the evaluation produces. The four verifiable properties the evaluation sequence produces. Two are active controls that govern data flow: selective disclosure and consent. Two are recorded assurances that the receipt proves: sealed entries and authenticity. - **Spec:** Section 7 Privacy Considerations (`/spec/v0.3/#privacy-considerations`) - **Site:** How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced (Replaces 'four pillars') ### Conformance boundary Line separating what the spec requires from what the evaluator decides. The line separating what the spec requires from what the evaluator decides on its own. Where the spec uses MUST, the evaluator has no discretion. Where it uses SHOULD or MAY, the evaluator sets its own policy and the receipt makes that policy auditable. - **Spec:** Section 4.4 Standalone Conformance Suite (`/spec/v0.3/#standalone-conformance-suite`) - **Site:** How It Works (`/how-it-works/`) - **Peer review:** Yes - **Change history:** v0.3 -- introduced --- ## Interaction Model ### Bilateral exchange Interaction where both parties present manifests and evaluate each other. An interaction where both parties present a Universal Manifest to each other and each independently runs the evaluation sequence on the other's manifest. Asymmetric outcomes are valid. This is the fundamental interaction model of UM. - **Spec:** Section 6.4.6 Bilateral Exchange (`/spec/v0.3/#bilateral-exchange`) - **Site:** Homepage (`/`) - **Change history:** v0.3 -- introduced ### Handshake Site metaphor for a UM bilateral interaction; not a spec term. The site's metaphor for a UM interaction. Not a spec term. Used in end-user contexts where bilateral exchange needs a concrete, recognizable word. Valid as prose but no longer used as a structural heading or concept name. - **Site:** Homepage (`/`), How It Works (`/how-it-works/`) - **Change history:** v0.3 -- introduced (Site-only metaphor) ### Exchange / Interaction Generic terms for what happens when parties present manifests to each other. The spec's generic terms for what happens when parties present manifests to each other. "Bilateral exchange" is the formal term; "interaction" is used in various contexts throughout the spec. - **Spec:** Section 6.4.6 Bilateral Exchange (`/spec/v0.3/#bilateral-exchange`) - **Change history:** v0.3 -- introduced --- ## Lifecycle and Infrastructure ### TTL (Time to Live) Validity window of a manifest, bounded by issuedAt and expiresAt. The validity window of a manifest, bounded by issuedAt and expiresAt. Evaluators MUST reject manifests where now > expiresAt. - **Spec:** Section 6.2 TTL Enforcement (`/spec/v0.3/#ttl-enforcement`), Section 1.3.3 Lifetime Members (`/spec/v0.3/#lifetime`) - **Change history:** v0.3 -- introduced ### Revocation Ability to invalidate a manifest or recipient's access before TTL expires. The ability to invalidate a manifest or a recipient's access before the TTL expires. Implemented through signature.statusRef and signature.revocationCursor. - **Spec:** Section 1.6.6 Revocation-Aware Verification (`/spec/v0.3/#sig-revocation`) - **Change history:** v0.3 -- introduced ### Conformance Conditions an implementation must satisfy to claim support for a spec version. The conditions an implementation must satisfy to claim support for a spec version. v0.3 defines evaluator, holder, and bilateral participant conformance targets, including the evaluation sequence and receipt production. - **Spec:** Section 4 Conformance (`/spec/v0.3/#conformance`) - **Change history:** v0.3 -- introduced ### Agent delegation Pointer declaring a subject has delegated authority to an AI agent or proxy. The um:agentDelegation pointer type declares that a manifest subject has delegated session authority to an AI agent, bot, or proxy. The delegation record names the agent, its scope, and constraints. - **Spec:** Section 6.5 Agent Delegation (`/spec/v0.3/#agent-delegation`) - **Change history:** v0.3 -- introduced ### Composition layer UM's architectural role: it carries and orchestrates, not replaces, existing standards. UM's self-description of its architectural role. UM does not replace existing identity, credential, or encryption standards. It carries or references material produced by those standards and defines what happens when an evaluator processes the result. - **Spec:** Section 1 Universal Manifest (`/spec/v0.3/#universal-manifest`) - **Site:** Standards (`/standards/`) - **Change history:** v0.3 -- introduced --- ## Site Framing ### Missing permission layer Homepage positioning frame: the web layer for permissions between things that meet. The homepage's positioning frame for UM. "The web has TCP/IP for packets, HTTPS for encrypted traffic, DNS for names. It never had a layer for permissions between things that meet. This is that layer." Positioning copy, not formal vocabulary. - **Site:** Homepage (`/`) - **Aliases:** the missing permission layer - **Change history:** v0.3 -- introduced (Site-level positioning) --- ## Retired Terms | Term | Status | Replacement | |------|--------|-------------| | Handshake mechanic | removed | Content merged into evaluation sequence and bilateral exchange | | Pillars | replaced | Controls + assurances | --- ## W3C Term Reference | W3C Term | UM Decision | Rationale | |----------|-------------|-----------| | consumer | Rejected. Replaced with evaluator. | "Consumer" implies passive, one-directional intake. UM's bilateral model requires a role-neutral term. | | selective disclosure | Adopted with qualifier: holder-controlled. | Standard W3C VC term. UM adds "holder-controlled" to clarify disclosure decisions are made by the manifest holder. | | conformance | Adopted as-is. | Standard W3C term, used in the same way. | | issuer | Adopted as-is (claim-level). | Standard W3C/VC term. The party that signs a credential or claim. | | holder | Adopted as-is (envelope-level). | Standard W3C/VC term. The party that assembles and signs the manifest envelope. | | subject | Adopted as-is. | Standard W3C/VC term. The entity the manifest is about. | | relying party | Adopted as-is. | Used in spec trust-tier sections. The party that relies on the evaluator's receipt. | | verifiable presentation | Referenced, not adopted as term. | Used within claimProof as a proof mechanism, but not surfaced as a UM vocabulary term. | --- ## Peer Review Appendix The terms below are provisional. They were chosen because something had to be named, but they are explicitly open for working-group input. - **Evaluator** -- Replaced W3C "consumer." Open to alternatives that preserve the bilateral, role-neutral semantics. - **Evaluation sequence** -- Replaced "receiver pipeline." Must name the six-stage processing order without implying a data pipeline. - **Selective disclosure** -- Adopted from W3C VC with "holder-controlled" qualifier. The qualifier is the only novel element. - **Sealed entry** -- New term, no W3C equivalent. Names the state of encrypted data in the manifest. - **Evaluation contract** -- Replaced "receiver-behavior contract." Must name the evaluator's normative obligations without implying a legal contract. - **Conformance boundary** -- New term. Defines the line between spec requirements and evaluator discretion. --- Note: PDF generation is planned as a follow-up. This Markdown file contains all tiers flattened for print/review use.