How It Works
Universal Manifest is an open specification for a portable, signed envelope of context that any compatible system can read, verify, and act on. This page explains the mechanics: how an evaluator processes a manifest, what the structured receipt records, and where the evaluation contract begins and ends. For the full picture, start with the homepage. For scenario walkthroughs, see the Use Cases page.
What is a manifest?
A signed JSON-LD envelope of state.
A Universal Manifest is a portable, signed document that carries everything needed for one entity to introduce itself to another. The issuer decides what goes in. The evaluator on the other side decides what to do with it. The structure is the same every time.
Subject. Who or what the manifest is about: a person, device, organization, or agent, identified by a DID or URI.
Facets. The claims, credentials, and context the subject carries. Each facet is a composable unit of data. The issuer controls which facets appear in each manifest instance (selective disclosure), so each evaluator sees only what was intended for that interaction.
Consent records. Per-facet rules governing scope, purpose, and expiry. Consent travels with the data and is checked at the point of use.
Sealed entries. Encrypted facets that travel with the manifest but remain unreadable to evaluators without the decryption key. They are recorded as present, never silently dropped.
Proof. A cryptographic signature (Ed25519 over JCS-canonicalized JSON, RFC 8785) binding the envelope together. An evaluator can verify that the manifest is authentic, current, and unrevoked before acting on any of its contents.
When an evaluator encounters a manifest, it runs the envelope through a defined evaluation sequence. That sequence is described next.
envelope structure
um:Manifest
@context, @id, @type
manifestVersion "0.3"
subject DID or URI
issuedAt, expiresAt ISO 8601
claims, consents, devices, pointers
facets composable (may be encrypted)
signature Ed25519 + JCS-RFC8785Evaluation sequence
The evaluator runs six stages, in order, on every manifest.
The evaluation sequence is normative. An evaluator claiming v0.3 conformance must execute all six stages in order and may short-circuit only by emitting a rejection receipt.
the evaluation sequence, end to end
Manifest received
Envelope parsed, required fields confirmed.
Signature + freshness checked
Forged or expired manifests stop here.
Selective disclosure applied
Issuer-controlled. Only projected facets present.
Consent + revocation checked
Scope, purpose, expiry enforced per facet.
Outcome assembled
Accepted, warnings, partial, or rejected.
Receipt written
Structured record of what the sequence did.
01 / Arrive
The evaluator parses the JSON document and confirms the required envelope fields are present: @context, @id, subject, issuedAt, expiresAt. Unknown fields are ignored to preserve forward compatibility. If parsing or structural validation fails, the sequence terminates with a rejected receipt.
02 / Verify
The evaluator verifies the signature against the JCS-canonicalized payload using the issuer's public key, enforces TTL (now <= expiresAt and issuedAt <= expiresAt), and resolves revocation status if signature.statusRef is present. If signature verification fails, the manifest is rejected.
03 / Project
The evaluator extracts only the facets, claims, and pointers relevant to its processing context. Selective disclosure is issuer-controlled: the issuer decides which facets appear in this manifest instance. Facets not included were never sent for this interaction.
04 / Consent
For each projected facet, the evaluator checks any governing consent record for scope, purpose, and expiry. Facet data is not processed when required consent is absent or expired. Encrypted facets the evaluator cannot decrypt are acknowledged as present but recorded as sealed entries.
05 / Compose
The evaluator assembles the result into one of four outcomes: accepted (all projected facets processed, all consent satisfied, signature valid), accepted-with-warnings (accepted but non-critical conditions noted), accepted-partial (some facets processed, others rejected or sealed), or rejected (a mandatory check failed).
06 / Receipt
The evaluator produces a structured receipt that records what the sequence actually did. Failed checks are not omitted. Negative outcomes are not suppressed. See the next section.
Receipt
The receipt is the evaluation sequence's audit trail.
Every manifest the sequence processes produces a structured receipt. The receipt records the outcome of each stage so a relying party can audit what the evaluator did without rerunning the sequence. The receipt schema is normative in v0.3.
Required fields
- manifestId
- the
@idof the processed manifest - outcome
- accepted, accepted-with-warnings, accepted-partial, or rejected
- signatureCheck
- valid, invalid, or unsupported-profile
- freshnessCheck
- fresh or expired
Recommended fields
- revocationStatus
- active, revoked, or unchecked
- facetStatuses
- per-facet status (processed, opaque, consent-denied, consent-missing, not-projected)
- consentStatuses
- per-consent results
- processedAt
- ISO 8601 timestamp
- warnings
- array of warning strings
Controls + assurances
The evaluation sequence produces four verifiable properties. The receipt records all four.
Two are active controls (selective disclosure, consent). Two are recorded assurances (sealed entries, authenticity). Together they define what a v0.3 evaluation contract requires. See all terms.
Control
Selective disclosure
Only the facets the issuer projected for this evaluator are present.
Selective disclosure is issuer-controlled and happens at issuance. The evaluator does not receive a redacted version of the full manifest. It receives a manifest constructed for this interaction. Fields not projected were never sent.
Recorded in the receipt: per-facet status, including not-projected for absent facets the evaluator was expecting.
Assurance
Sealed entries
Encrypted facets the evaluator cannot read are recorded as present but unreadable, not as absent.
A facet may carry an encrypted entity payload using the JWE inline profile. An evaluator without the decryption key cannot read the payload. It acknowledges the facet, records it as opaque, and continues processing the rest of the manifest.
Recorded in the receipt: facet status opaque with an optional reason.
Assurance
Authenticity
Every claim that drives behavior is traceable to a verifiable signature.
Manifest authenticity is verified in stage 02 against the JCS-canonicalized payload. Individual claims may declare a requiredTrustTier from 0 to 2. An evaluator that cannot satisfy a claim's required tier treats that claim as unverified.
Recorded in the receipt: signatureCheck, per-claim trust tier outcomes where applicable.
Bilateral exchange
Both parties present manifests. Each runs the evaluation sequence on the other's manifest.
Universal Manifest is bilateral. In any interaction, both parties exchange manifests and each party independently runs the evaluation sequence on the other party's manifest. There is no central evaluator.
Each party sets its own requiredTrustTier for the interaction. The effective trust tier is the maximum of what either party demands. Asymmetric outcomes are valid: the same exchange can be accepted in one direction and rejected in the other when one party's claims do not satisfy the other party's required tier.
Two devices may exchange manifests over a local transport (NFC, BLE, QR) and each verify the other's claims without a server. For high-risk actions, parties fail closed when required-tier checks are not satisfied. For lower-risk actions, parties may degrade to a restricted mode.
Worked example
Six stages, applied. A portal transition between spatial fabrics.
You are attending a live concert in a spatial computing environment hosted by a venue running its own spatial fabric. As you move toward the venue perimeter, you approach a boundary. On the other side is a marketplace running a different spatial fabric. Your client detects the boundary and begins the evaluation sequence on the marketplace's manifest.
01 / Arrive
Your client parses the marketplace's manifest envelope. Required fields are confirmed: @context, @id, subject, issuedAt, expiresAt. The marketplace identifies itself by a DID, declares manifest version 0.3, and lists the facet types it will request. Unknown fields are passed over. The envelope is structurally valid.
02 / Verify
Your client checks the marketplace's Ed25519 signature against the JCS-canonicalized payload. The signature is valid. TTL is current: now <= expiresAt holds. The manifest carries a statusRef; your client resolves it and finds the publisher DID active, not revoked.
03 / Project
The marketplace has projected three facet types for this context: location coordinates, avatar parameters, and retail preferences. Your retail consent preferences govern which of these appear. Eye tracking data and microphone access were not included by your client at issuance because retail projection rules exclude sensor data.
04 / Consent
Location, avatar parameters, delivery address, and sizing preferences each have current consent records with scope, purpose, and expiry aligned to the crossing. Eye tracking, microphone, and purchase history are not projected, so the receipt records them as not-projected.
05 / Compose
All projected facets were processed. All consent checks passed. The signature is valid. The outcome is accepted. Your avatar parameters, location coordinates, and retail-scoped consents are assembled into the evaluation result in the format the marketplace's spatial fabric expects.
06 / Receipt
A transition receipt is generated. Both parties hold a signed record of the manifest IDs exchanged, outcome, signature check, freshness check, facet statuses, consent statuses, and processing timestamp. Neither party can later assert that different consents were active at the moment of crossing.
This pattern applies wherever two spatial fabrics meet. See the full spatial computing use case for the RP1 portal transition scenario, multi-party fabric negotiation, and enterprise deployment context.
See the spatial computing use caseConformance boundary
The evaluation contract governs how the evaluator processes, not what it accepts.
Universal Manifest does not require every evaluator to understand every field, support every profile, or accept every claim. It requires evaluators to evaluate honestly and record honestly. Unsupported fields can be unsupported. Sealed entries remain opaque. Denied consent can stop an exchange. The evaluation contract is that the evaluator cannot silently pretend otherwise.
Where the spec uses MUST, the evaluator has no discretion. Where the spec uses SHOULD or MAY, the evaluator sets its own policy and the receipt makes that policy auditable. For precise definitions of these terms, see the terms.
See scenario walkthroughsWhere to next