Re: [mmox] MMOX: Strawman scope/goals/approach

[Christian Scholz <[e-mail]>]

Meadhbh Hamrick (Infinity) wrote:
> cool. lemme put on my linden hat and throw out my US$0.02...
> 
> in terms of identity, we have a strong preference for authenticating
> application to application. part of the reason we like this is we have a
> requirement that our HTTP traffic be able to flow over proxies (of both
> the SOCKSish variety and the squidish caching variety.) we are therefore
> paranoid that somewhere, somehow, transport layer authentication
> information would be "eaten" by a misconfigured or miscoded piece of
> required infrastructure. we understand that many people deploying VW
> applications may not have this requirement, but we kindly ask people to
> respect our requirements. but... just because we have defined an
> application-layer-endpoint to application-layer-endpoint authentication
> protocol does not mean we're going to try to ram it down everyone else's
> collective throats. OpenID, OAuth, PKIX client certs and even *shudder*
> gss-api all have a place in the world, and that place may include
> authenticating endpoints in virtual world interactions.

What do you mean by eaten? Are there proxies eating e.g. cookies or GET
parameters? E.g. OAuth after all is just some GET parameters or a header
field but you can choose.
I understand that you have lots of infrastructure in place which might
not be that easily compatible with it though. But this will be the case
for everybody for most protocols we develop.
But as said earlier, I would like to see the use cases being written
down first with the requirements if *all* participant and then we can
think about what the best solution might be (and we apparently need
criteria for that where one might be the change costs for vendors,
another interoperability outside the VW space).

> in terms of non-second-life-like systems... yes... some people may
> remember that Zero and I are both "smalltalk people" and have been
> working with squeak from the early days. i mention it only to
> contextualize the discussion with respect to croquet and some the
> related commercial ventures (like qwaq.) personally, i like croquet and
> have for a while. like any system it has it's benefits and its
> drawbacks, but more germane to this discussion, uses an interaction
> model that is slightly different than the one second life uses.
> however... there's a statement in the draft charter identifying the
> focus of this group as being "application layer wire protocols," and to
> the degree that this statement survives the WG formation process... i
> would hope we could define wire protocols that were independent enough
> of the interaction model to at least allow some reuse of the PDUs. if
> there was a way to make TObjects look like REST-like resources we might
> be able to go further and reuse some of the interaction model. (but i'm
> just offering it as a suggestion! i'm not saying croquet has to change
> to be more SL like before we'll play nice with you!) and who knows...
> maybe after detailed investigation of both system's interaction models,
> we could find a way to denote them both with the same representational
> system.

I think we all need more understanding of how the other systems work. I
know roughly how it's in SL but have no idea about Croquet or OLIVE or ...

> with respect to service discovery... the "SL mode" right now is to
> assume a list of services. ultimately this has got to change, and we
> know that. that was part of the motivation for the design behind
> OGP/Auth. At the end of authentication, the client is in possession of a
> capability (protocol endpoint) from which it may request other
> capabilities (protocol endpoints) that address resources which may be
> accessed to request various services. all of the services CS mentions
> below could easily be implementable with this technique. i've heard from
> some quarters that capabilities give some people the willies and
> honestly... they gave me the willies too until i drank the kool-aide and
> started using BREW a couple years back. i would point out, however, that
> they've been in constant use with SL for over 5 years now and they tend
> to work quite well for us. ultimately, however, there are likely going
> to be some people who won't want to use them and sure... that's fine...
> what this means to me vis a vis protocol definition is we should
> separate the acquisition of a service endpoint from the service it
> enables. and this might be was CS was talking about below.

As you know I don't really like caps ;-) I mostly do not like them
because they are very different from what you do on the web and they are
in fact somewhat more difficult to implement with a web framework (at
least if we assume how the SL infrastructure is, OpenSim does it a bit
differently). But that's probably detail and maybe there is even a way
to keep caps for you and maybe add some header field for more web affine
people. And I think if we still want to support the use case in which
e.g. some social network can act as an Agent Domain (or the equivalent
in some future MMOX protocol) then it's not very likely to assume that
they implement caps. They more likely have OAuth and XRD-based service
discovery in place.
But you are right: We should definitely separate the discovery of these
service endpoints from the services themselves and we shouldn't assume
any service (or specific version of it) to be there. This gives us more
flexibility and shouldn't be too hard to implement.


> or it might have been about service versioning that came up from time to
> time in the PyOGP list. fwiw... we tend to be "chunky" in our service
> deployment, meaning we prefer to not operate several versions of related
> services simultaneously, but i'm sure we can come up with a way to
> create a versioning system in MMOX, and i warn people up front that
> enabling such functionality would likely be a tough sell at linden, but
> we wouldn't stand in the way of other virtual worlds operators / client
> developers wanted to add it to a spec we claim we want to adhere to. but
> just keep in mind we're likely to either strongly request the feature
> was optional or use it in such a way that our grid always looks like it
> only has a single version of each service.

It also depends on how granular a service is. If they are relatively
small then it's easier to exchange them, if they are a huge thing which
do everything (like an AgentDomain in OGP) then it's hard.

> merging social networking sites and virtual worlds sounds like a win,
> but i wonder if it's not a better idea for the two to develop separately
> and allow protocols in each area to reference each other. for example,
> OpenSocial is, as i understand it, currently implemented as a set of
> web-apis. i really like the idea of an opensocial app being able to
> "reach into the virtual world" and i like the idea of our virtual world
> supporting things like existing OpenSocial apps... let's just not make
> it a REQUIRED part of the protocol anytime soon.

Well, you say that it's hard to get changes into your codebase. Would
this be any different if you really want to meet with the web at some
point? I would do it now because I don't really see a win in making our
own thing here. Web protocols might have problems and flaws in our scope
here but those communities are open for discussion and of course cannot
guess all possible use cases. e.g. the multi-service-authorization use
case for OAuth is such a case where right now it's not really well
working. I still think though that it can be made working by talking to
the OAuth folks and proposing some extension.
As for OpenSocial I don't speak about apps. All I am talking about is
the OpenSocial REST API where you can do a simple GET (guarded by OAuth)
to retrieve some persons profile. The OpenSocial Person schema might not
fit our needs but we can again do it as extension and/or start a
discussion on the OpenSocial list to make schemas more extensible
themselves.
We need to transfer profiles anyway and OpenSocial gives us REST and it
gives us some basic schema to build upon. It also enables the
possibility to e.g. import MySpace profiles today already.

But what is required or not is again not a discussion for now but for
sometime after use case definition and requirements capturing. Then we
can really say if it fits or not.

as a sidenote: I wrote down a workflow of an experiment I was coding 2
evenings ago which uses OpenID, OAuth and OpenSocial to import a
profile. You can find it here:
http://socialconnect.info/trac/wiki/WorkflowNumberOne

Code is following soon.

> so... to paraphrase... to the degree that linden can be the 800 lb.
> gorilla in a room where virtual worlds are being discussed and blizzard
> hasn't shown up... i promise to use my secret powers for good. the lab
> has no interest in scuttling anyone else's product roadmap but we ask
> that the more agile participants in this group give us a little slack
> with what we're able to implement and how fast. compared to the open sim
> peeps, we must seem like dinosaurs, and compared to tao, we're probably
> stromatolites. i just ask that peeps here please keep in mind we have an
> onerous repository of legacy code and a large installed base we can't
> abandon, so there's a reason we're moving slower than people might like.

I think protocol definition and implementation are two different things.
 Defining a protocol for VW interoperability is IMHO a very huge
undertaking because the problem domain is so huge and every participant
has their own flavour of what they want, need and can do in a reasonable
time for a reasonable budget.

So everybody needs time to implement changes and they might not be
small. And because of that I hope not that it means just because SL
might be slower in adapting we use more SL related technology just
because it makes it easier for LL.
I am not against using that technology if it makes sense but before that
I really want to know what the other vendors do, why they do it and
what's important to them.
That it already works well can probable be said about the technology of
every vendor participating.

My last point is about the huge problem space. Maybe it really makes
sense to first cut that into pieces. My pet peeve apparently is a
portable identity or in more general maybe data portability and I would
already be happy if I can login with my SL account in There, Kaneva and
so on without creating a new one. Also having my friends from elsewhere
being on my friendlist there automatically would be great. All this of
course under the premise that I can control who can see what data. Other
things like object transfer and making 3D representations compatible
might then come afterwards.


-- Christian

PS: I don't think you are stromatolites ;-) SL came a big way and helped
to make VWs popular. And what now is live deployed is probably all very
much grown and also based in a time where nobody talked about OAuth or
OpenSocial. And I know that changing such a system and keep it running
is a huge task in itself and also risky. So I understand your problems
and I also understand why it's easier for LL to just standardize OGP.



> 
> -cheers
> -meadhbh
> 
> On Feb 24, 2009, at 3:31 PM, Christian Scholz wrote:
> 
>> Mark P. McCahill schrieb:
>>> +1
>>> I really like the approach David is taking here. The first two items:
>>>  * managing identity
>>>  * naming and authenticating services in MMOX worlds
>>> are prerequisites for getting anywhere with cross-system
>>> interoperability,
>>> would benefit users of existing systems, and should be achievable in the
>>> fairly near term. Understanding how to negotiate these services is the
>>> place to start, rather than defining an abstract wire-level protocol, if
>>> the intent is to bring something other than Second Life-like worlds into
>>> the fold.
>>
>> +1 and I would actually list:
>>
>> - defining an identity endpoint
>> - service discovery to find services for this identity such as profile
>>   definition, friends list, inventory server, ...
>> - distributed authorization
>>
>> Then having a way defined for services to be found and authorized one
>> could define the specifics of these services.
>>
>> I would extend this beyond MMOX worlds though because there is huge
>> interest in the web and social networking players as well.
>>
>> So maybe a seperate working group which has not the focus so much just
>> on virtual worlds for this part might make sense. But I have no idea
>> about the IETF process anyway at this time and if and how this would
>> be possible or wanted.
>>
>> -- Christian
>>
>>
>>> Mark McCahill
>>> On Feb 24, 2009, at 11:04 AM, David W Levine wrote:
>>>>
>>>> 1.        The ability to manage one's identity when interacting in
>>>> multiple MMOX spaces.
>>>>       a.        Allowing presence information to be shared and
>>>> coordinated across
>>>> MMOX spaces
>>>>       b.        Permitting friends lists, and IMs to be shared
>>>> across spaces
>>>>       c.        Permitting MMOX spaces to share naming
>>>>       d.        Simple ways of allowing a consistent name, managed
>>>> by the user, and
>>>>               verifiable by other users
>>>>       e.        Single sign on, mediated by multiple spaces, within
>>>> the policy constraints
>>>>               of the spaces
>>>>       f.        A consistent appearance, within the constraints of
>>>> the various systems
>>>>       g.        The ability to manage the degree of visibility /
>>>> coupling between identities
>>>>       in MMOX spaces
>>>>
>>>> Note that for all of these, there is no requirement to couple the
>>>> systems together
>>>> beyond managing identity, and share presence and IM information.
>>>> These use
>>>> cases don't speak to how you move between spaces. You may have to
>>>> shutdown
>>>> your client on one system and start another. This also is not a "You
>>>> must enable
>>>> this" this is very much a "Make it easy for spaces which want to
>>>> enable this to do
>>>> it." Also, note that "presence and messaging" speak to user needs,
>>>> and consitent
>>>> appearance and name (when desired by users) again speeks to meeting
>>>> user's
>>>> desires.
>>>>
>>>> 2.        The ability for the services in an MMOX world to be named,
>>>> and authenticated
>>>>       a.        Services to associate virtual places and the
>>>> services which support them
>>>>       with authentication and administrative domains
>>>>       b.        Services to permit a service to validate the
>>>> membership of a remote
>>>>       service in one or more authentication and administrative domains
>>>>
>>>> This is needed so that we can do essentially any of the
>>>> interoperability work.
>>>> Without some framework which lets us know who we are talking to, it is
>>>> impossible to trust the behavior of distributed systems.
>>>>
>>>> 3.        The ability to share content between MMOX spaces
>>>>       a.        Import and Export of content and models (This may
>>>> well leverage off of
>>>>       existing work such as Collada) Static, import/export of
>>>> content while not
>>>>       terribly dramatic is an important part of the value chain of
>>>> interoperability
>>>>       b.        Mark up schemes which recognize the existence of
>>>> multiple presentation
>>>>       environments, but permit the sharing of content
>>>>               i.        Shared "type" information for the various
>>>> types of graphical
>>>>                       content which MMOX spaces contain
>>>>               ii.        Extensible, with a common registry, so that
>>>> we can understand the
>>>>                       types of contents a client can accept, and a
>>>> virtual space, or virtual
>>>>                       asset store can be asked to provide
>>>>       c.        A MMOX based, system independent asset addressing
>>>> scheme which includes
>>>>               i.        Content negotiation based on 2b
>>>>               ii.        Access Management based on (1) and (2)
>>>>
>>>> This is, to my mind, the key mid term deliverable
>>>>
>>>> 4.        The affordances in MMOX to permit the creation of
>>>> micro-payment economies
>>>>       a.        Appropriate spots defined in MMOX protocols for cost
>>>> information
>>>>       b.        Appropriate spots defined in MMOX protocols for
>>>> reference to
>>>>               micropayment systems
>>>>
>>>> 5.        The ability to share "non immersive streams" between spaces
>>>>       a.        Markup to permit the consistent sharing of stream
>>>> media such as voice,
>>>>               and video, with shared start and synchronization
>>>> information to permit
>>>>               "parallel" events between MMOX space
>>>>
>>>> 6.        The ability to express Policy intent between MMOX services
>>>> and virtual spaces
>>>>       a.        Places in reserved in the MOX protocols for
>>>> expressing policy intent
>>>>       b.        One or more policy languages for expressing policy
>>>>
>>>>
>>>> The solution space:
>>>>
>>>> Most of the deployed solutions partition the software problem into
>>>> the following chunks.
>>>>
>>>> 1.        Some form of a client which permits a user to interact
>>>> with the shared experience
>>>> 2.        Virtual space servers which manage the state of a portion
>>>> of virtual space
>>>> 3.        A set of supporting services used by the virtual space
>>>> servers
>>>>
>>>> Note that exactly how these three large chunks are assembled and the
>>>> granular nature of
>>>> the services can vary radically, even when serving very similar
>>>> environments. Some
>>>> environments push a large amount of rendering and management onto
>>>> complex clients,
>>>> others perform the bulk of rendering in the server portion of the
>>>> deployment. Some
>>>> implementations combine client and simulation into a single entity
>>>> which does some
>>>> simulation and some user presentation. Some distribute the
>>>> simulation, some centralize it.
>>>>
>>>> The heart of most of the solutions is managing to accept and merge a
>>>> stream of updates,
>>>> and then distribute the merged updates back to users. This can
>>>> happen at a range of
>>>> granularities. The two ends of the spectrum, are, roughly, sending
>>>> updates as a fully
>>>> merged audio visual stream, which the client merely displays, and
>>>> sending low level
>>>> changes to a underlying mode, which the client uses to assemble a
>>>> complete visual
>>>> representation of the scene.  Variations include croquet and qwaq
>>>> which use an
>>>> underlying distributed object model to pass large amounts of
>>>> updates, and approaches
>>>> such as used by SecondLife and Protonsphere, where voice is managed
>>>> in a separate
>>>> service, with the merged state service merely letting the voice
>>>> service know where the
>>>> users are located.
>>>>
>>>> Closely related, are issues of representation and format of content.
>>>> This takes several,
>>>> separable forms. Import and Export of material to the core
>>>> environment, and, more
>>>> problematically, run time representations
>>>>
>>>> Approach
>>>> Our overall approach should be web centric, and web services
>>>> oriented. We can, and
>>>> should think of sets of related services which can be composed as
>>>> part of different
>>>> solutions which will enable varying degrees of interoperability. We
>>>> can, and should
>>>> attempt to provide as web like an approach to function as possible.
>>>> Content negotiation,
>>>> separation of protocol from security, separation of interface from
>>>> implementation and
>>>> other techniques.
>>>>
>>>> Our goal is not to enshrine any single virtual world as the standard
>>>> for all MMOX spaces,
>>>> but rather create a flexible, extensible set of services which will
>>>> allow us to grow larger
>>>> and large overlapping sets of capabilities. My expectation is that
>>>> we will see a lot of low
>>>> hanging fruit in the area of identity, authentication, authorization
>>>> and presence
>>>> management (Where a user is, and allowing messaging to them across
>>>> MMOX spaeces)
>>>> and initially, we will find a lot of format and content area
>>>> addressed by gateways,
>>>> markup, and content negotiation. I see nothing wrong with having a
>>>> URI which refers to
>>>> "A pretty maple tree with fall colors" which provides a way to fetch
>>>> the "Collada Style
>>>> version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec
>>>> version"  such that
>>>> a virtual space can select, through content negotiation the one most
>>>> useful to it.
>>>>
>>>> We get value, when we have consistent ways of referring to all the
>>>> various forms of
>>>> content, and we get more value when we have ways of using existing
>>>> content negotiation
>>>> to allow a web light selection of an appropriate form. It is equally
>>>> possible to imagine
>>>> negotiating between a client and a virtual space, the desired form
>>>> of objects. There are
>>>> some deep challenges lurking, such as when two different approaches
>>>> have radically
>>>> different
>>>>
>>>> What I would encourage us, as a mailing list to do, is look through
>>>> the problem
>>>> statement, and interoperability goals I've put together here. They
>>>> are an attempt to
>>>> capture the various sentiments in the ongoing discussion. I am sure
>>>> I have missed points,
>>>> and I am sure some people will disagree with some of the points I
>>>> have made.
>>>>
>>>> I would ask people to look for "No, you missed X" and "Hey, I don't
>>>> think Y" is true. I
>>>> will attempt to capture all of those, and revise the document, until
>>>> we think it represents
>>>> something close to the general group consensus. (I am not looking
>>>> for 100% consensus,
>>>> but a "Yeah, this captures most of what we're trying to do." With
>>>> that in hand, I would
>>>> suggest we could then begin to enumerate the specific services and
>>>> markups we need to
>>>> support our goals, and begin to flesh out use cases to help us
>>>> understand the goals and
>>>> services.
>>>>
>>>> I do not expect this to yield a set of specs which Linden Lab, or
>>>> OpenSim, Or any one
>>>> virtual world vendor or project would implement whole. What I expect
>>>> it to yield is a set
>>>> of specs, which can be combined with existing projects and code
>>>> bases to drive us
>>>> towards a more interoperable future.
>>>>
>>>> Out of scope
>>>>
>>>> I also want to begin to accumulate a short list of "No, this is out
>>>> of scope" assertions
>>>>
>>>> 1.        We will provide all the affordances necessary to permit a
>>>> broad range of
>>>> interaction policies. Appropriate policies for various deployed
>>>> solutions and
>>>> future deployed solutions is out of scope, beyond providing us use
>>>> cases which
>>>> highlight specific affordances we may wish to consider
>>>> 2.        Whether or not immersive multi-party spaces are useful and
>>>> which specific
>>>> capabilities are required is out of scope. We aspire to support a
>>>> broad range of
>>>> possible capabilities, and we respect that different organizations
>>>> will have
>>>> different perspectives on what is required. Our goal is to define
>>>> broad,
>>>> interoperable frameworks which will enable a range of deployments,
>>>> not to define
>>>> the one true model for this space
>>>> 3.        Propose additional statements here
>>>>
>>>> Closing comments
>>>>
>>>> I don't think our collective goal can be to take any one existing
>>>> spec or solution and
>>>> simply declare it the basis for our work going forward. At the same
>>>> time, we must base
>>>> our work in actually running code, showing real interoperability.
>>>> Our goal must be to
>>>> build supersets of function, based on existing products and
>>>> solutions which demonstrate
>>>> real interoperability.
>>>>
>>>> The IETF favors working code and growing consensus over blank paper
>>>> and blue sky
>>>> efforts. This is based in a history of success and failure in the
>>>> industry when it comes to
>>>> building, promoting and succeeding at standards work. Work at the
>>>> IETF is grounded in
>>>> working code.
>>>>
>>>> One way forward is to focus on several clusters of work. One: a
>>>> clear, broad framework,
>>>> which forms the basis for long term broad interoperation. Two:
>>>> Capturing the current set
>>>> of incompatible and overlapping formats and protocols in use, so
>>>> that we can create a
>>>> extensible and shared catalog of artifacts for sharing. (eg. "Here
>>>> is the canonical,
>>>> extensible  list of graphic content types you might want to move on
>>>> a MMOX transport"
>>>> Three grow out  proposed solutions such as LLSD, OGP, and others, as
>>>> they are
>>>> contributed towards a common superset which can be used to as the
>>>> basis for
>>>> demonstrating concrete progress towards interop goals. Four,
>>>> Identify places where we
>>>> simply want to use existing work, such as OpenID, OAuth,  X.509  and
>>>> create a shared
>>>> profile for how we can use these protocols to further interoperability.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> <Scope01C.txt><Scope01C.doc>
>>>> _______________________________________________
>>>> mmox mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmox
>>> _______________________________________________
>>> mmox mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>> -- 
>> Christian Scholz
>> Blog: http://mrtopf.de/blog
>> Company: http://comlounge.net
>> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de
>> _______________________________________________
>> mmox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
> 


-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: [phone]                           E-Mail [e-mail]
Fax: [phone]                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)