MMOX Architecture Discussion
draft-cscholz-mmox-architecture-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 5, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document tries to summarize the different problem areas in the MMOX field and proposed an approach to build interoperability from the bottom up starting with a flexible foundation. It also aims at identifying problem spaces which are more general than the virtual worlds field and also touch on problems found in today's social networks.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
    1.1.  The individual problem fields
    1.2.  Full or partial compatibility
    1.3.  Problems broader than the MMOX space
2.  Proposal
    2.1.  Three initial problem fields
        2.1.1.  Portable Identity
        2.1.2.  Distributed Authorization
        2.1.3.  Service Discovery
    2.2.  An example workflow
3.  IANA Considerations
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Author's Address

1.  Introduction

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.

1.1.  The individual problem fields

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.

1.2.  Full or partial compatibility

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.

1.3.  Problems broader than the MMOX space

There are some problem fields of the list in Section 1.1 (The individual problem fields) 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.

2.  Proposal

As describe in Section 1.2 (Full or partial compatibility) 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.

2.1.  Three initial problem fields

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

2.1.1.  Portable Identity

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".

2.1.2.  Distributed Authorization

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[OAUTH] (Hammer-Lahav, E., “OAuth Core 1.0,” .). 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.

2.1.3.  Service Discovery

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 XRDS (Wachob, G., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) [XRDS]has 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 [DISCOVER] (Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” .)

2.2.  An example workflow

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.

1. 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.
2. The client does service discovery on the virtual world URL to check for available 3D protocols
3. The client receives a list of supported 3D protocols of that virtual world and selects the best one
4. The client established a connection to the virtual world.
5. The virtual world performs service discovery on the user's identity URL and finds an authentication service suitable for it.
6. 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.
7. The OpenID provider sends a success message back to the virtual world which now knows that the user "owns" the URL.
8. The virtual world now checks for further services such as profile information or friends list.
9. 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
10. 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.

3.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

4.  Security Considerations

This document proposes a process for authentication and authorization which need to be secure. We rely on the work being done in the respective protocols in that field, namely OpenID and OAuth.

5.  References

5.1. Normative References

5.2. Informative References

Author's Address