The complete terminology for Universal Manifest v0.3. Forty-five terms across nine categories, each with a definition, spec citations, and site usage references. Terms marked for peer review are provisional.
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.
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.
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.
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.
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.
JSON-LD document acting as a cross-platform signed data envelope.
Also known as: UM
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.
Third party that vouches for a claim or cross-DID binding.
Also known as: attestor
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.
Party that receives and processes a Universal Manifest.
Also known as: consumer, receiver
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.
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.
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.
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.
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.
Four possible results: accepted, accepted-with-warnings, accepted-partial, rejected.
Also known as: four compose outcomes
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.
The normative six-stage processing sequence every evaluator executes.
Also known as: receiver pipeline, evaluation pipeline
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.
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.
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.
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.
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.
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.
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.
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.
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.
Holder-controlled mechanism determining which facets appear in a manifest instance.
Also known as: projection
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
Normative obligations every conformant evaluator must meet.
Also known as: receiver-behavior promise, receiver-behavior contract
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Every W3C term considered during the vocabulary audit, with the decision and rationale.
| 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. Both parties evaluate. |
| selective disclosure | Adopted with qualifier: holder-controlled. | Standard W3C VC term. UM adds "holder-controlled" to clarify that disclosure decisions are made by the manifest holder, not negotiated. |
| conformance | Adopted as-is. | Standard W3C term, used in the same way. Applied in conformance boundary and conformance suite. |
| 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. |
The terms below are provisional. They were chosen because something had to be named, but they are explicitly open for working-group input.
This terms page is a companion to the specification. For normative definitions, conformance requirements, and the full evaluation contract, read the spec.
