MMOX Architecture Discussion

From the discussion on the MMOX mailing list it became clear that there are several fields people want to work on there is a big variety of virtual worlds out there which for now at least will not be fully compatible that many problems discussed are broader than just the area of massively multi-player worlds. In order to come to a usable work result a way needs to be found to make those worlds at least as compatible as possible or to give them means to negotiate their capabilities. Moreover the problems which cross the boundaries to e.g. social networks should be solved in a more general way and with participation of the respective communities.

As it was pointed out in the list we at least have the following fields which are identified: Federated/portable Identity Distributed authorization Service Discovery data formats (e.g. LLSD) world simulation protocols presence protocols/services Licensing/permissions/DRM All these problems are not really overlapping each other but might be seen next to each other or in different layers.

There are a lot of virtual worlds vendors out there and most of them have a different approach on how they handle 3D simulation, how they transfer data and so on. There is eventually not much in common and most vendors won't be willing to change their entire system for now. In order to nevertheless reach some interoperability we need to find a way to negotiate capabilities between those worlds and define if maybe a gateway can translate from one world to another or if some features might simply not be available.

There are some problem fields of the list in which are not only relevant to virtual worlds but also for e.g. social networks. These are especially Federated/portable identity Distributed Authorization Service Discovery Presence Protocols Licensing/permissions/DRM It's clear from that list that only really the 3D related services are specific to the MMOX field. That is because one can see virtual worlds as just specialized social networks easily. The question is now how we can proceed with these problems to find a solution which also integrates with other parties such as the social networking area.

As describe in we have a lot of existing protocols and data formats to consider. Because of this a full standardization in only one standard is not very likely for now. What can be done though is to start to build a foundation on which services, be they existing social networks or virtual worlds, can interoperate to a certain level. A foundation might at least enable the following things: Portable Idenity Distributed Authorization Service Discovery After that one can specify those individual services and data formats which MAY be used while they MUST support the above specifications.

There are three problem fields which make sense to discuss first.

Portable Identity means that a user does not have to register on every new service but she can simply login on all networks/worlds supporting the specification coming out of the MMOX WG. There is also a lot of prior art, most prominent example probable being OpenID. As OpenID is gaining a lot of momentum in the social networking scene it makes sense to define it as "MUST implement".

In a decentralized world not only one service holds all the data of a user but there might be many services which all hold partial data. Examples of such data sets can be profile, friends connection, group memberships, assets such as photos or 3D objects and much more. Also service providers can provide several services as e.g. world simulation, Instant Messaging services and so on. All these services need to protect their resources though and MUST NOT give access to unauthorized sources. Thus the user needs to authorize these services to a new third party service for it to have access to them. This again is a topic discussed not only for virtual worlds but also for social networks or for HTTP in general. Here one solution gaining momentum and also being chartered as an IETF WG is OAuth. It allows a service A to access resources of service B on behalf of the user. The user needs to authorize access but can at any point also withdraw that authorization. The problem which still needs to be solved is mass authorization though as OAuth relies on redirects to a service and back to the consumer which is very user unfriendly if there is more than one service to authorize.

Whenever you want to access a service you need to know it's URL (if HTTP is used). Moreoever you want to check what services a certain virtual world supports. In order to do that a means for Service Disovery need to be found. This means that a client which wants to do service discovery accesses a well known URL as e.g. the main domain name and performs a process which in the end results in a list of services distinguished by a type. The client can then check which service types and versions of those it supports and can start with service authorization on those. The same is true for user centric services such as profiles, friends lists and so on. Here the endpoint from which to discover a user's services is a URL which identifies the user such as an OpenID. In fact OpenID uses YADIS which is nothing else than a service disovery on the OpenID URL to check which identification methods are supported. Right now the field of service discovery is a bit in flux. As the document format and the way of discovering the location of that document so far XRDShas been used but work is under way to separate the discovery mechanism from the actual format as well as coming up with a new format for describing services. An Internet Draft regarding service discovery can be found at

In order to demonstrate how those three areas can work together here is an example. The goal here is that a user wants to login to a certain virtual world. The user enters his unique identification URL into the respective field in a client. He also enters the URL of the virtual world he wants to enter. The client does service discovery on the virtual world URL to check for available 3D protocols The client receives a list of supported 3D protocols of that virtual world and selects the best one The client established a connection to the virtual world. The virtual world performs service discovery on the user's identity URL and finds an authentication service suitable for it. The virtual world instantiates an auhentication for the user. In case of OpenID it means to redirect the user to his OpenID provider where he authenticates. The OpenID provider sends a success message back to the virtual world which now knows that the user "owns" the URL. The virtual world now checks for further services such as profile information or friends list. For each service the user is asked if he wants to use it (if not essential) and will then be redirected to that service to authorize access for that virtual world The virtual world retrieves access tokens that way and can then access a user's protected resources such as profile or friends list by using that token. This is only a small example and it has still many shortcomings in e.g. the authorization of each individual service. If this is solved it is extensible though and further standardization might work on defining those wire level protocols which are needed for simulating a 3D world or transferring objects in a secure way.