Use cases Use case A
Portaling Between Virtual Worlds
You cross from one immersive experience into another. The version of you that travels arrives first. Your persona, your avatar, your behavioral mappings, your hardware embodiment, your language, your currency, your accessibility preferences, your consent positions, and your proof of personhood, projected for the destination world before your avatar materializes.
What changes
Crossing into a new immersive experience stops being a cold start.
Today a portal between virtual worlds is a cold start. Re-create the avatar. Re-enter the language and accessibility settings. Re-grant permissions for eye tracking, hand tracking, location, microphone. Re-claim a persona that maps to nothing the destination can verify. Friction at every threshold.
With a manifest, the manifest arrives before you do. The destination reads your signed envelope, verifies your identity, applies your consent rules for this context, reads the parametric definition of your avatar and the hardware signals that drive it, and renders the version of you that travels. Your height, your behavioral mappings, your language, your currency, your permissions, your proof of personhood, and the selective-disclosure rules that say which subset of all of that this particular receiver gets: all of it crosses with you.
The manifest is the through-line. Identity is no longer trapped per-provider. Avatar fidelity travels with the hardware that produces it, not with the world that hosted it last. Language, currency, consent positions, and accessibility preferences become structural properties of the credential format rather than per-world re-implementations.
Scene
A friend invites you into a world your account does not exist in.
You are inside an immersive virtual experience. A friend invites you into a different one operated by a different provider on different infrastructure. No shared backend, no shared account system, no shared avatar pipeline.
You approach the boundary between the experience you are in and the one your friend invited you into. The boundary is a portal: visually, a luminous threshold marking the edge of the world you are leaving and the edge of the world you are entering. Your client emits your manifest ahead of you. The destination world publishes its own manifest in return: its identity (the world operator's DID), the content rating it enforces, the credentials it requires for entry, the services running inside it, the consent positions it asks visitors to set. Both sides have declared their terms before the crossing begins.
A virtual experience that respects the manifest can welcome a visitor without onboarding them. One that cannot read the manifest can still pass a presence check without learning anything beyond what the manifest authorizes.
What travels in the manifest
The version of you that travels, brought together in one envelope.
Every facet below is carried as a discrete unit of the manifest. The destination receives only the projection authorized for this context. The full enumeration mirrors the identity-travel scope the project has been designing toward, covered comprehensively here, in UM vocabulary.
| Travels in the manifest | UM facet | Default visibility |
|---|---|---|
| Persistent identifier and signing key | subject (DID) + signature profile (Ed25519) | public |
| Persona: display name, entity type (human / ai_agent / npc), content rating | persona facet | public |
| Avatar: parametric body data, H-Anim skeleton reference, blendshape mapping, content rating | avatarDefinition facet (with avatarRef pointer for high-res override) | public |
| Avatar disclosure authorization: who is allowed to fetch the avatar source, under what conditions | avatarAccessAuthorization facet | public |
| Height and physical-form settings | persona facet (extended) | public |
| Behavioral mappings: how input device motion drives avatar motion | behavioralMapping facet | public |
| Embodiment hardware reference: the device producing the user's tracking signal, and the resolution at which it produces it | deviceCapability facet | public |
| High-resolution performance-data references: signed pointers to facial and body motion streams driving the avatar at fidelity | performanceData facet (pointer-only; the stream lives at the hardware service provider) | private |
| Language preference | persona facet (extended) | public |
| Currency preference | persona facet (extended) | public |
| Accessibility preferences: input modality, audio descriptions, sensory load, captions | accessibilityPreferences facet | public |
| Permissions / consent positions: sensor gating, data retention, marketing (derived-variant vocabulary) | consents array | public |
| Proof of personhood | verifiableCredentials facet (issuer-signed VC) | public |
| Government ID and full birth date | encrypted facets (present but opaque to receivers below the relevant threshold) | encrypted |
| Selective disclosure rules: what subset of all of the above each receiver gets | projection rules + receiver-role table | rule, not data |
| Receipt expectations: typed events the destination is expected to emit and the visitor expects to receive | receipt taxonomy reference | private |
| Receipts of every prior portal crossing | receipt chain | private |
Every row above is a facet UM already models or extends through one of the integration surfaces the project has designed. The use case is not new architecture. It is the architecture brought together in one scene.
Walkthrough
Six stages, applied. One portal crossing.
The crossing follows UM's six-stage evaluation sequence: arrive, verify, project, consent, compose, receipt. Each stage is normative. A conformant destination must execute all six and may short-circuit only by emitting a rejection receipt.
- 01 Arrive
The manifest meets the boundary.
You approach the boundary between the experience you are in and the one your friend invited you into. The boundary is a portal: visually, a luminous threshold marking the edge of the world you are leaving and the edge of the world you are entering. Your client emits your manifest ahead of you.
The destination world publishes its own manifest in return: its identity (the world operator's DID), the content rating it enforces, the credentials it requires for entry, the services running inside it, the consent positions it asks visitors to set. Both sides have declared their terms before the crossing begins.
Exchanged: subject + signature profile + persona + entity type + content rating + avatar parametric data + avatar disclosure authorization + behavioral mapping + device capability + language + currency + accessibility preferences + consent array + age-verification ZKP + proof of personhood. Destination publishes: world identity + content rating policy + required credentials + available services + entry requirements.
- 02 Verify
Signatures, entity type, proof of personhood.
The destination resolves your DID from the subject field and retrieves your public key from the DID registry. It verifies the Ed25519 signature over the JCS-canonicalized manifest. The signature checks out. The manifest has not been tampered with. The TTL has not expired.
It reads your entity type: human, signed by a trusted identity service provider that performs proof-of-personhood verification. The signature on that claim is verified end-to-end. The destination now knows it is greeting a real person, not an agent, not a scripted character.
Your age-verification ZKP is verified against the credential issuer's public key. The proof confirms you are above the world's age threshold without disclosing your birth date. Your root identity, your government ID, and your full birth date remain encrypted. The destination records them as present but opaque. It cannot read them. It does not need to.
- 03 Project
The receiver-role rule decides what gets seen.
The destination identifies itself as a virtual-world host: a fabric-level service in the receiver-role taxonomy. The projection contract for that role admits your persona, your entity type, the avatar facets the destination needs to render you, your behavioral mapping, the consents the destination's services depend on, your accessibility preferences, and the host-relevant subset of your verifiable credentials. The receiver-role contract excludes your root identity, your full birth date, your unrelated credentials, and any encrypted fields the destination is not authorized to read.
A different visitor crossing the same threshold gets a different projection. Their manifest defines their own rules. The destination receives what each visitor's manifest authorizes; no more, no less.
- 04 Consent
Sensor gating and behavioral mapping rules apply.
The destination reads your consent array. Eye tracking is denied: no service in this world will receive gaze data from your headset, regardless of what any service asks for. Hand tracking is granted: gesture-based interactions work. Room geometry is granted at the occluder-only tier (the world can avoid placing you inside a wall but cannot reconstruct your real room). Microphone is granted at the post-server-mix tier (your voice is in the spatial audio mix, but the world's services do not receive raw audio).
Your behavioral mapping authorizes the destination to drive your avatar's motion from the signal stream produced by your device's facial-tracking and body-tracking sensors, at the resolution the device declares. The destination calls the performance-data pointer; the stream begins. Your avatar moves as you move. Your facial expressions render at the fidelity the hardware supports. The world does not get the raw sensor data; it gets the parameter stream that drives the rendered motion, scoped to the avatar's surface.
- 05 Compose
The avatar renders; presence is granted.
The destination has everything it needs to render you. It reads your H-Anim skeleton reference and the parametric body data and generates your mesh locally. Your accessories and apparel attach. Your height settings apply. Your behavioral mapping drives the motion. Your language preference activates the world's localization layer. Your accessibility preferences activate audio descriptions, captions, or any sensory-load adjustments you have set.
Other visitors see your avatar. They also see your entity-type indicator: human, verified by a trusted identity service provider, cryptographically signed. The avatar standing beside you may show human, the assistant ahead may show ai_agent, the scripted greeter at the entrance may show npc. Each claim is signed; each is verifiable. You always know what you are talking to.
The world's services activate in the scope your consents allow. You are present.
- 06 Receipt
What happened, signed and recorded.
The destination's receipt records: identity verified, entity type human (issuer trusted), content rating accepted, age ZKP verified, avatar rendered from parametric data, behavioral mapping active at hardware-declared resolution, language and accessibility preferences applied. Consents: eye tracking denied, hand tracking granted, room geometry occluder-only, microphone post-mix. Root identity, government ID, and full birth date opaque, not accessed.
Your client's receipt records the world identity, the content rating policy, the services that activated, the projection sent, the consents enforced, the credentials presented, the credentials withheld. Both receipts are signed. Both are auditable. The next time you portal, whether into another virtual experience or back to the one you started in, the receipt chain extends.
Connection to standards
Three external standards address parts of this scene. UM is the envelope that makes them work together.
Portaling between virtual worlds is being designed at several standards bodies simultaneously, each addressing a different layer.
-
IWPS (Inter-World Portaling Standard, OMA3)
Defines the transport protocol that routes a user from one virtual world to another. Two APIs (Query and Teleport), four communication pathways. IWPS is the pipe. UM does not replace it. When IWPS opens the route, UM is the credential that travels through the route.
-
WoW (Web of Worlds, Web3D Consortium)
Avatar metadata and translation frameworks for moving avatar representations between world engines. Parametric definitions, blendshapes, skeletons. UM is the signed container the WoW-defined avatar data sits inside. Tracey Swales's public framing of this layer, the question of how identity-bearing data is transported between entities, informs UM's envelope role here.
-
H-Anim (ISO/IEC 19774, Web3D)
Articulated humanoid skeleton standard. UM carries the H-Anim reference and the parametric body data; the destination world generates the mesh.
-
UM (the credential envelope)
UM occupies the layer none of the others standardize: the signed, consent-gated, selectively-disclosable credential envelope that travels through IWPS's protocol carrying the WoW-defined avatar with the H-Anim-defined skeleton, plus everything else the destination needs to render the visitor.
Receipt
A signed record of the crossing.
Both the visitor and the destination world hold a signed receipt of the crossing. The receipt records what was verified, what was projected, what consent applied, and which fields remained opaque. It is the audit trail no centralized arbiter has to keep.
Deeper reading
How portaling between virtual worlds connects to the rest of UM.
Closing
The same handshake runs at every portal boundary.
The destination changes. The world changes. Your manifest stays consistent. The version of you that travels is the version you set, projected appropriately for whoever you are talking to.