Re: [mmox] OGP scalability concerns

[Christian Scholz <[e-mail]>]

Hurliman, John schrieb:
> Thank you Christian, I think this is the right approach. Using
> partially defined blanket terms such as "Agent Domain" or "Region
> Domain" conjure up different ideas in everyone's head and also tend
> to imply an unnecessary aggregation of services. If we can clearly
> define the actual work items such as identity, authentication,
> authorization, asset storage, asset representation (content types and
> metadata), communication and contact lists, etc. we would likely find
> much more common ground between parties and could start partitioning
> the work into manageable sized chunks.

Thanks!

In fact we could actually start with thinking about 
identification/authentication right away and maybe taking OpenID and see 
how it might fit in a not web-based environment (read: VW client).

Another option would be to join forces with the OAuth group at IETF and 
check on how we could add identity to OAuth (there is discussion about 
that already). Eventually this might be an easier choice and you could 
do authorization in one step, at least for some centralized services.

We could start by fleshing out some more detailed use cases to see what 
is needed, what can be provided by existing standards and what might be 
missing and needs some inventing.

I am just too tired to start right away ;-)

-- Christian



> 
> John
> 
>> -----Original Message----- From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Christian Scholz Sent:
>> Thursday, April 02, 2009 1:05 PM To: Jon Watte Cc: [e-mail] 
>> Subject: Re: [mmox] OGP scalability concerns
>> 
>> Jon Watte schrieb:
>>> Meadhbh Hamrick (Infinity) wrote:
>>>> so maybe we might say "virtual world avatar interop" or
>>>> "virtual world event stream interop"?
>>>> 
>>>> but not say "virtual world interop" 'cause it's too vague?
>> I would say that in fact we have quite a few areas where 
>> interoperability is possible if we start to cut the problem space
>> into smaller chunks.
>> 
>> Here are some:
>> 
>> - Identification (who is this agent?) - Profiles (information about
>> the logged in user) - friends/contacts (probably most worlds have
>> this) - group memberships (not every world might have this) -
>> (instant) messaging - presence - Assets such as
>> textures/photos/sounds etc.
>> 
>> Now if you take those than we can discuss what interoperability
>> means for each of them. In fact there are many formats/protocols
>> already available:
>> 
>> - OpenID, InformationCards etc. for identification - OpenSocial
>> RESTful API or PortableContacts (the same protocol) for profile and
>> contacts (in a limited fashion at least) - XMPP or IRC (and other
>> proprietary formats) for instant messaging. Might also include
>> presence although maybe this needs to be extended. - SMTP for not
>> so instant messaging
>> 
>> So in fact for some areas interoperability would already be
>> possible. It would at least allow a user with an account on service
>> A to login to service B and maybe be able to match contacts, chat
>> with people on other services and so on.
>> 
>> And basically what is describes then is a simple social network. If
>>  you add 3D services on top then you have your virtual world and
>> this is where it becomes complicated.
>> 
>> If you take the above elements you also have an Agent Domain. So in
>>  fact it's nothing else than the social networking part where the 
>> Region domain would be those additional 3D services.
>> 
>> Of course the AD also does a bit more, like trust brokering.
>> 
>> The thing is though: Why group all this together into one big
>> chunk? It will be more likely in the future that you will have data
>> stored on several services: your profile might be on MySpace (or
>> one of many), you chat via IRC on freenode, you have photos on
>> flickr which you might want to use as textures. So IMHO it makes
>> sense to allow this to be split up into several services. The only
>> question is how to bind this together.
>> 
>> I already mentioned XRDS here once, which is basically a list of
>> type URI/service URI pairs. A user could describe via XRDS where
>> profile, friends list etc. is stored and the client or the
>> simulator could then go and fetch it. No big Agent Domain would be
>> needed and you also could support various services where client and
>> simulator could choose those they understand.
>> 
>> The only thing of course where it gets tricky is authorization 
>> brokering. You don't want your data public (at least not all of
>> it). OAuth might give you some means of authorizing third parties
>> to give out data on your behalf. But the problem is of course that
>> you'd need to authorize each service individually which is not user
>> friendly.
>> 
>> So here is where some thinking is actually needed: How can an 
>> authorization broker be implemented. I would prefer it be OAuth
>> based because libraries and understanding of OAuth is there (and of
>> course it's also at the IETF ;-). And maybe we come back here to
>> the original scalability problem of the AgentDomain but at least it
>> would be only one problem for the AD to solve (although the name
>> might be not correct anymore then because all the stuff related to
>> an agent would be spread across different services).
>> 
>> 
>> As for naming though: it would then be
>> 
>> - profile interop - contactlist interop - group interop - chat
>> interop
>> 
>> etc.
>> 
>> The question to the group would now be: Would it be worthwhile to
>> try to use all those existing specifications and just build a way
>> around them to bundle those things? IMHO the implementation
>> wouldn't be so hard to do. It would be an area though where it's
>> very mixed with where the web/social networks are going so it would
>> make sense to do this together with web folks.
>> 
>> 
>> 
>> 
>> 
>> -- Christian
>> 
>> 
>> 
>> 
>> -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33,
>> 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben
>> Scheffler, Christian Scholz
>> 
>> email: [e-mail] fon: [phone] fax:
>> [phone]
>> 
>> personal email: [e-mail] personal blog:
>> http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de,
>>  http://datawithoutborders.net
>> 
>> _______________________________________________ mmox mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/mmox


-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: [e-mail]
fon: [phone]
fax: [phone]

personal email: [e-mail]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net