Re: [mmox] The Story So Far...

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

since when?

the current implementation does, but the protocol definition is pretty  
explicit that you cannot assume that just because you authenticate to  
"host a" that the cap that will be granted to rez in world or to  
access inventory won't be on "host b" or "host c". I'm happy to start  
the discussion about whether identity should explicitly be divorced  
from authentication, so identification can be deferred to an even  
different host.

people have been talking about them being in the same administrative  
domain because we have no OAuth like mechanism defined to provide a  
non-forgeable authenticator that can be consumed by a third party.

that is to say... the spec does not mandate that identity, presence   
and inventory be managed by the same administrative domain, it's just  
that doing that seems to give peeps the security heebie-jeebies.

what you are asking appears to be the same as a Google service  
exposing a sensitive resource (maybe the right to read your gmail) to  
Yahoo! or Microsoft, but not REQUIRING that Yahoo! or Microsoft  
provide an authenticator indicating they have that right.

one of the reasons we're participating in the IETF is the wealth of  
experience this brings us in terms of people familiar with all sorts  
of enabling technologies (including things like TLS, HTTP, OAuth, etc.)

On Feb 17, 2009, at 4:16 PM, Hurliman, John wrote:

> The agent domain concept takes several independent services  
> (identity, presence, inventory) and lumps them together into a  
> single trust domain. This inhibits the development of a widely  
> distributed ecosystem like we find on the web today, and is really  
> only convenient for large virtual world service providers that  
> already have a vertical stack of services. It also drags in the  
> assumption that there must be a backend communication layer between  
> services such as inventory and simulation regions.