Warp +Identity +Assets

When referring to identity herein, the idea is that each user has only a small number of identities (e.g., mother/father, police(wo)man, triathlete/DJ, spy) under which various logins, avatars and assets might fall. Identities might not be entirely distinct, but have substantial overlap. It is not proven that this is the optimal approach for identity, hence, this might change in the future.

The reason for this approach is to enable a user workflow of, when warping between worlds, that avatars and assets can be mapped with respect to an identity, but not assume that the user will have the same identity in each world; in fact they could have multiple identities in the same world.

An implication of this identity approach is that there must be a component that keeps track of which identities the user uses in various world. This component could be same component that handles the users authentication credentials, but this isn’t required.

Upon the player entering the portal, the MC component publishes a Warp message containing the desired destination and a reference to the identity used in MC. At this point two sequences can run in parallel; the first sequence being the mapping of identity and the second being the negotiation of an avatar asset. According to the 2PhW protocol, the ACK to the warp can be sent before the negotiation section is complete (with the danger that the preemptive send being in vain). Identity mapping, however, must be resolved before the ACK is sent, to avoid the player not being successfully logged in to the destination.

The sequence diagram for identity mapping starts with SL receiving the Warp message from MC, including the identity that MC was using. In this example, I’m going to illustrate the use of a translator(mask) for SL, called tx-sl, because SL does not natively support the communication sequence described herein. tx-sl lacks a SL compatible identity and authentication credentials, so it sends out a query for it.

The authentication/authorization component, called Auth, has the ability to protect the user by authorizing warps that go through the system. If worlds only support authorized warps, then the user has control over warps between worlds. The Auth componet sends out an AccessContol request message to the UUI, which displays a dialog box for the user. If the user authorizes the warp, the AccessControl is confirmed and the Auth componet can continue processing the warp. This has already been implemented and demonstrated in the "Install Second Life during cross world Warp" video.

Create Login: If the warp was been authorized by the user, Auth can check if credentials exist for SL; in this first scenario they do not yet exist. The Auth component sends out authorized Warp message, but with missing SL credentials (this send could potentially be piggybacked on the AccessControl request). The tx-sl component understands the user must be asked and therefore sends out a signal to delay the warp source world from timing out; simultaneously, the UUI asks the user for credentials, which are thereafter passed to tx-sl.

Existing Login: If the SL credentials had existed, the Auth componet would simply publish an authorized Warp message with the SL credentials.

The result in both the cases, of a new login or an existing login, is tx-sl receiving the login credentials for SL (if no errors occurred or the user did not cancel). The tx-sl component temporarily holds onto the mapping of ID/MC to ID/SL for the duration of the warp, logs into SL and publishes an ACK to the original Warp message.

There are, of course, many other scenarios for different login types (e.g., crypto wallet, SSO, web login, email, mobile authenticator) and so the translator would have to handle the appropirate one for the world that it is masking. This means that there does NOT need to be a universal way to login in order to achieve interoperability, the translators handle the heavy lifting.

After the initial warp message, the source world can start sending out assets. In this example, the MC component is sending out an avatar to the destination, with either: the avatar in-message in Minecraft skin format, a reference to where the skin can be found, or both. A component, refered here to as the Character Sheet (ChSh) also receives the asset message and can cache the avatar, if the included asset permissions allow. SL receives the asset and can (optionally) immediately ACK it as being received, while simultaneously querying for an avatar translation.

An immediate argument against the above might be the re-engineering cost and the willingness of Second Life and Minecraft to implement the sequences. The rebuttal to this is that they are not required to re-engeineer their systems, only have APIs available in their native platform implementation to handle the functionality. The rest can be handled by a SL translator acting as a mask, similar to how the "Install Second Life during cross world Warp" is handled. Second Life was a good candidate for the implementation, precisely because they have rather open system with APIs available.

Instead of SL replying to the warp and the asset negotiation, the SL translator, tx-sl, can do the work. tx-sl is added engineering cost, rather than re-engineering cost. Second Life could remain up and running while the translator is updated dynamically; those are properties that IPSME offers.

In the above sequence, tx-sl speaks to SL directly when it has the format that SL understands and SL is oblivous to all the external negotiation. SL is, however, required to have an API for logging in and setting the Avatar, if SL is to be considered open for avatar interoperability. The constraints that SL has for avatars doesn’t change, so they only receive avatars that they want to support; the API can reject other requests.

The section on Avatar Negotiation alluded to the existence of the character sheet component, called ChSh. The idea behind the componet is to have a single space where the user can see: all the avatars that are available to them, the reputation they have with each connected platform and other stats. The character sheet can store data, but ideally, it is just a cache of information with references to where the original data can be found e.g., blockchain, a authorized virtual world, a CDN, etc.

The sequence starts with the user activating the character sheet, causing it to load. In this scenario, the user is logged into SL. The data to fill the character sheet can either be loaded from cache and/or queries can be sent out to fetch data.

Using the broadcasting feature of IPSME, ChSh can query all connected worlds for avatar and reputation simultaneously. If authorization is required to access avatar and reputation data, those worlds can go through a sequence similar to the authentication/authorization found in Identity Mapping. The data returned to the character sheet does not need to be the original data, but can even be distilled versions of the data with references to the original data e.g., thumbnails of images or summaries of reputation values.

set avatar: If the user wants to change the avatar of their current world, to one that is perhaps not available in-world, the user chooses the avatar in ChSh causing a set-avatar message to be sent out. Setting the avatar is similar to the asset negotiation in Avatar Negotiation; the avatar can be passed to the current world in-message and/or as a reference.

req request: If a query is received by ChSh, from a particular world, about the user’s reputation, the ChSh component first sends out an AccessControl message so that the user has a chance to confirm they want to share their reputation. A user should not be required to send out all their reputation scores by default, but could choose to share stats from only selected sites. As per the definition of Identity used herein, each user identity might have different associated reputation scores. Retriving and sharing reputation is similar to asset negotiation in Avatar Negotiation, but with the asset being reputation instead. Note that in this example, it is not realistic that MC answers reputation queries currently; a translator is required, but it has been left out for simplicity.

Last updated: 2023-12-04 12:10:00