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

[Gareth Nelson <[e-mail]>]

> 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.
I believe that it would be quite trivial to have separate identity
provider services which merely point at other services that are hosted
by the same provider or hosted somewhere else.
For example, I can picture something like this in the login response:
{'inventory':'https://providera.com/inv/<MyUUID>',
 'im':'https://providerb.com/im/<MyUUID>'}

> 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.
Is it not that people have been lumping them into one domain because
for the most part we only have single domains right now?
When was the last time someone realistically had any means to "mount"
their inventory from say OSGrid and Second Life, with identity being
hosted somewhere else and then logging into some random region domain?

> 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.
The capability URL is the proof that they have the right :)
I'd go so far as to say that we need a proxy-type service for
generating new limited caps URLs that can be revoked by the user