Re: [mmox] OGP scalability concerns

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

hmm... there was a lot of discussion about this a year and some ago.  
("this" being how to wedge OpenID into SL)  i think it fell off  
everyone's radar 'cause there were larger fish to fry. i was looking  
in the goupies chat logs and logs from zero's office hours and sldev,  
but for the life of me i can't find the discussions i was thinking  
about. anyone else remember hashing over OpenID in the past? it might  
be a good place to start.

On Apr 2, 2009, at 2:27 PM, Christian Scholz wrote:

> 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
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox