RP1 Integration
How Universal Manifest gives RP1 a portable envelope for identity, assets, and permissions.
RP1 publishes the browser engine, the spatial fabric, the service protocol, and the scene object model. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt taxonomy the audit layer produces, and the projection contracts the receiver roles enforce.
Load-bearing thesis
Universal Manifest is the portable signed credential and state envelope that RP1's open-metaverse-browser architecture describes but does not standardize. Every time RP1's documentation says "the browser caches credentials and presents them to services," it describes a Universal Manifest.
UM is the crucial missing piece of the RP1 stack. Not a competitor, not a fork, not an identity wrapper bolted on, but the layer the architecture assumes exists. RP1 publishes the browser engine, the spatial fabric, the service protocol, the scene object model, and the developer roadmap. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt structure the audit layer produces, and the projection contracts the receiver roles enforce. They fit together without either side bending.
The browser holds the envelope. The fabric reads it. The services receive only what their receiver-role contract authorizes. The receipt records what happened.
This thesis is not aspirational. It is the result of three rounds of integration analysis covering 14 primary surfaces, 8 secondary surfaces, a typed receipt taxonomy, a normative performance-engineering profile, a category-trust security refactor, two enterprise worked examples, and three convergent external reviews. The thesis is what falls out of doing the work.
Watch the series
Six short explainers that walk the RP1 integration from the top down. Start with the overview, then follow each piece of the fabric in order.
How Universal Manifest gives RP1 a portable envelope for identity, assets, and permissions.
How an RP1 place address becomes a consent-gated bookmark.
How visitors prove RP1 service access locally.
How RP1 checks permission before anything is built into a sub-world or overlay.
How RP1 worlds verify imported assets before loading.
How layered RP1 worlds stay permissioned as you move.
Scene
A spatial fabric is running. Inside the fabric, multiple services execute in sandboxed WASM instances: a map service, a navigation service, a safety service, an inventory service, a wayfinding service, a commerce service. They share no memory. They do not trust each other by default. The browser mediates everything that crosses a service boundary.
A user arrives. Their identity service provider issued a UM manifest this morning. The browser holds the manifest in cache. As each fabric service comes into proximity, the browser presents the projection that service's receiver role authorizes. The safety service reads safety credentials. The map service reads location consent. The commerce service reads payment attestation. None of them see fields outside their contract. Inter-service messages cross the browser-mediated channel only when the inter-service authorization manifest names the source, the target category, and the message type. The receipt chain extends with one signed event per decision.
Nothing about that scene is hypothetical. RP1's architecture describes a browser that caches credentials and presents them to services. UM is the credential format the browser caches. Every service interaction the architecture diagrams is a projection of the manifest the browser holds.
What changes
For RP1, adopting UM means adopting one cryptographically verifiable format for the identity, consent, trust, and audit data the architecture already requires but has not yet standardized. The browser stops needing to invent its own credential cache shape; the services stop needing to define their own credential read paths; the audit layer stops needing to design its own event taxonomy. The portable-credential decision becomes "use UM," not "design a credential format."
For the broader open-metaverse-browser cohort (using RP1's own term for the implementer community), UM becomes a profile-able envelope that other browser engines can adopt. The same manifest the RP1 browser caches works in a different browser-engine implementation, with the same projection contracts, the same consent vocabulary, the same receipt taxonomy. The credential becomes portable across browser engines, not just across services within one engine.
For enterprise readers, the manifest becomes the audit-trail anchor. A worker's shift produces a signed chain of receipts: who entered which zone, which services authorized which capabilities, which sensors stayed denied, which inter-service messages crossed which categories, which mandatory services activated, which expired credentials triggered alerts. The chain is hashed locally and sealed into a departure manifest at end of shift. Compliance with HIPAA, OSHA, the EU Accessibility Act, and similar regulated regimes stops being a per-fabric implementation problem and becomes a structural property of the credential format.
Three scenes
Three concrete moments where UM does the work inside an RP1 fabric. Each one follows a person or a module through a single boundary, so you can see exactly what the browser presents and what the receipt records.
You walk into a spatial fabric. Your browser has been holding your manifest since you signed in this morning, so there is nothing to scan and no form to fill. The fabric asks for proof over RMAP, your browser presents the manifest once, and the session stays open until the manifest expires.
The fabric checks the signature, confirms it has not expired, sees that a trusted provider vouched you are a real person, and lets you in.
Three services light up around you, and each one gets only its slice. The map service sees where you are. A retail kiosk by the door sees your display name and position, nothing more. A bar wants to know you are over 18, so it gets a yes to that one question and never sees your birthday. One envelope, three different views.
The browser brokered every handoff, no service saw a field outside its contract, and each decision left a signed line on the receipt.
Touches identity, entity type, RMAP service credentials, consent, zero-knowledge age proof, and spatial addressing, each step logged to the receipt.
A technician puts on AR glasses to start a shift on a big plant floor. Their manifest already carries the things the job depends on: signed safety certifications, an equipment-access credential for the gear and zones they are cleared for, the plant's own policy, and a list of which sensors stay on and which stay off. Eye tracking and the camera are off, and the plant policy keeps them off.
At the door the fabric checks all of that, then switches on the two services the plant requires: safety alerts and emergency evacuation.
At a hydraulic press, the monitoring service gets just enough to confirm the technician is cleared, and full telemetry appears in the glasses. That service writes only to its own corner of the scene tree and cannot reach into the safety service's branch.
A training guide walks them through a pump swap. Before it runs, the fabric checks the module the same way an app store checks a signed app: right fingerprint, real publisher, not revoked.
Then a forklift rolls into the next aisle. The safety service needs to warn the navigation service to reroute foot traffic. That message only goes through because the plant pre-approved exactly that channel for exactly that kind of alert. A warning lights up in the glasses, and because safety is mandatory here, the technician cannot wave it away.
When the shift ends, the manifest expires, every service drops its access, and the whole run is sealed into a signed end-of-shift record.
Touches identity, equipment-access credentials, consent, the content-trust check, scene-tree write permissions, and service-to-service messaging.
A new fabric is coming together, and a vendor offers a predictive-maintenance module. The browser will not run it on trust. First it checks three things: the file matches the fingerprint the publisher signed, the publisher is who they claim to be and has not been revoked, and their signature on the code is real.
All three pass. The module runs, but only with the access its publisher actually declared, writing to its own branch of the scene and nowhere else.
A second module shows up from a publisher the fabric revoked after the manifest was issued. The browser blocks it cold. The block and the reason go into the audit log, and the code never reaches the runtime.
Touches the content-trust check, the package and service catalog, and scene-tree write permissions, with a signed receipt either way.
Connection to standards
RP1's open-metaverse-browser stack (the proper-noun name for RP1's architecture) is the most architecturally complete published specification of its kind to date. Below, each RP1 component is named in RP1's own terms.
The five-layer browser engine. Layer 5 is content creation, Layer 4 is services and identity providers, Layer 3 is the browser engine itself (RMAP, SOM, WASM runtime, ANARI, OpenXR, SPIR-V validation), Layer 2 is OS drivers and runtimes, Layer 1 is hardware. UM operates at the Layer 3 / Layer 4 boundary: identity service providers (Layer 4) issue manifests; the browser (Layer 3) caches them; spatial fabrics and services (Layer 4) verify and consume them.
RP1's three-layer service protocol: a Service layer (session management, authentication), a Model layer (observable objects), a Source layer (wire-protocol adapter). UM is presented and consumed at the Service layer during session establishment. UM does not travel through the Source layer. The credential is verified once at session admission and the verified session is retained until the manifest's expiresAt.
RP1's underlying service driver model: the open-standard real-time API foundation RP1's services are built on. UM is consumed within the service-driver authentication step. (Earlier RP1 documentation references SMAP under what may be the same protocol's prior name; UM's integration anchors to the authoritative current naming.)
RP1's authority-scoped scene tree. UM's SOM branch authorization facet declares which branch a service is permitted to write to. The SOM enforces the authorization; UM provides the verifiable claim.
UM is not an alternative to any of the above. UM is the credential, consent, trust, and audit format that the architecture already requires. Adopting UM means closing the open question RP1 has explicitly deferred: what shape does the portable credential take?
Receipt taxonomy
UM's six-stage evaluation sequence gets a typed event taxonomy at the receipt stage: session-admitted, session-denied, session-degraded, capability-granted, capability-denied, capability-revoked, package-trusted, package-rejected, policy-override-applied, cross-fabric-portal-cleared, terms-acknowledged, co-presence-entity-type-asserted, avatar-retrieved, avatar-substituted, shader-trusted, shader-rejected. The chain is local-hashed and sealed into a departure manifest at session end. Sample below is from the factory-floor scene.
Deeper reading
Closing
RP1 publishes the browser engine, the spatial fabric, the service protocol, and the scene object model. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt taxonomy the audit layer produces, and the projection contracts the receiver roles enforce. The browser does not need to invent the credential format. The services do not need to invent the credential read path. The audit layer does not need to invent the event taxonomy. The portable-credential decision becomes "use UM."