.png)
Last month OMA3 opened its draft specification of the Inter World Portaling System (IWPS) to public comment. If you want to read it, go to OMA3’s Github page. We recently hosted a webinar on IWPS with the Metaverse Standards Forum and the recording is available.
In this post we outline the thinking behind the spec design and summarize the major components of the system. Since this is just the base specification, we also list the additional specifications we still need to create. Please keep in mind that this is a draft. We need feedback from the community to make it as solid as possible. If you have suggestions, we’d love to hear them!
Background
As we detail in our IWPS position paper, the purpose of IWPS is to enable metaverse hyperlinks. A user in one virtual world uses an IWPS link to teleport to another virtual world. Intra-world portals have existed for decades but travel between worlds has not been possible, leading to a siloed metaverse. IWPS bridges the siloes.
Web hyperlinks are relatively simple, but IWPS is more complex because the metaverse doesn’t only exist in your browser. It’s accessible via different application clients on different operating systems and hardware. To truly connect the metaverse, IWPS needs to incorporate worlds wherever they are, hence the additional complexity of the specification. Requirements such as cross platform support guide design, and we list all IWPS requirements in our IWPS Request for Proposals. Our design makes more sense when viewed against these requirements.
A two-phase protocol
The IWPS requirements pushed us to design a protocol that has two phases as compared to the single-phase nature of web hyperlinks. The first phase negotiates multiple parameters that are important in a multi-platform, diverse metaverse with valuable assets. The second phase executes the teleportation using the parameters from the negotiation phase.
Negotiation Phase
The negotiation phase begins with a GraphQL API call to the destination world’s Portal URI. Where the Portal URI comes from is outside the scope of the specification, but it can be as simple as an advertisement with a QR code or a link sent in a chat message. The negotiation phase answers questions such as: What is the destination location? Which client should be launched? Who is coming through the portal? With what assets? What is allowed in the destination world? Are there any teleportation fees that need to be paid?
The negotiation phase API can be called multiple times before the actual teleportation. Negotiated parameters can be cached and then updated with additional API calls. Once these parameters are negotiated, the teleportation can happen using the negotiated values.
Execution Phase
The job of the execution phase is to securely launch the destination client (using a URI parameter finalized in the negotiation phase) and get the user to the point where they are fully logged into the destination world or prompted with a login. If two clients are on the same device the process is much simpler than managing a teleport between clients on different devices. The mechanism for launching a client on a different device is also out of the scope of the specification, but multiple OMA3 members are using various forms of push notifications to do this.
Privacy
One of the many drawbacks of today’s centralized web is widespread tracking of users. The draft specification begins to address this problem by enabling the use of trusted user agents that act as a privacy buffer between worlds. Of course the risk is that the user agents themselves become data collectors so there is still more work to be done.
Future Extensions
As mentioned above, we just released the base specification and the document has placeholders for protocol extensions in cybersecurity, identity, asset transfer/negotiation, and payments. Work on these extensions will continue in OMA3 working groups.
Cybersecurity
The web has never been a secure environment. It has gotten better through technologies like TLS and X.509 certificates, but breaches of all shapes and sizes are still commonplace. Security adds complexity, so OMA3 chose to outline different levels of security in IWPS and worlds can decide what kind of security they want to implement, and require from other connecting worlds. It is our hope that most worlds implement OMA3’s high security standards which are alluded to in the specification, but it is optional.
