[ogpx] Supporting Multiple Agent Domains [Was: Re: OpenID and OGP : beginning the discussion ...]

[Infinity Linden <[e-mail]>]

so there's a related question that's been batted around in hushed
tones. it hasn't yet emerged in the full light as i believe there's a
fear it will complicate OGP or at least it's use cases: "what if i
want to define my avatar name and password in one agent domain, but
draw services from another?"

OGP originally envisioned two distinct types of entities: an agent
domain and a region domain. the idea was that _all_ agent services
would go through one agent domain. however, the use of capabilities
allows us to easily deploy critical services in two distinct
administrative domains. this construction was originally introduced to
allow agent domain operators to easily change their service
architecture without having to change it's interface. For example, if
a small operator put user profile services and login services on one
host and later discovered the profile load was bogging down logins,
they could easily move the user profile services to another host and
simply have capabilities for that service point to the new machine.
(Zha Ewry has a good quote related to this, something like "we should
separate deployment from service definition.")

several people noticed that this construction could allow complete
services (like asset management, group chat/IM, etc.) to be managed by
systems in a completely distinct agent domain. that is, the
authentication service host _could_ be managed by one entity while
your inventory was managed by another. this is a great idea... it
allows a business to emerge that focuses on one aspect of the virtual
world: digital asset management, group chat, authentication, whatever.
but.. it GREATLY complicates trust and security issues. and i can
think of at least one grid operator that will not deploy a service if
there's a hint of a security vulnerability.

however... we all know the future of OGP includes multiple, distinct
operators contributing to create a unified virtual world. to this end,
we've been working on enhanced trust models and using PKI and OAuth as
mechanisms to support them. (Kudos to John Hurliman for practical
examples of how OAuth might work in OGP and David Lavine for applying
many cycles thinking about PKIX.)

So... essentially... i think where we're at right now... we anticipate
_the_ "Agent Domain" (note the capitalization) to offer services which
may come from several different "service domains." we anticipate
existing trust relationships to exist between these  "service
domains." further, we anticipate mechanisms such as TLS client
certificates and OAuth tokens to carry trust assertions between
service domains, so these service domains may make meaningful access
control decisions and NOT require end users to separately log into
each distinct service domain.

or.. in other words.. somewhere in the cloud of services termed "The
Agent Domain" is one entity that maintains an authoritative
relationship with the end user. That entity maintains account
information sufficient to authenticate the end user and may (at it's
option) administer a "single sign on-like" service in which trusted
third parties may maintain sensitive information on the user and agent
domain's behalf.

an example of how that might work might look like this: I (Meadhbh
Hamrick) may have an account with "Bob's Avatar Emporium and Internet
Bait Shop (BAE&IBS)," that's identified with an account identifier
"[e-mail]" and a password. Bob's Emporium and Internet
Bait Shop operates an authentication service that i point my client
application at when i want to enter the virtual world. My avatar
"Meadhbh OhNoes" is mapped to my account by this service. BE&IBS may
sub-contract to "Cord Shores Industries (CSI)" to operate their asset
servers. when i log in, i use my account identifier and my password,
and after the service establishment dance my client application given
a capability that points at CSI instead of BE&IBS. CSI will no doubt
require information from BE&IBS, and when it does, it makes a request
to a "private" interface (one intended for trusted partners only,) and
uses a TLS client certificate to verify its identity and it's
authority to use the private interface. When BE&IBS makes requests to
CSI to establish a capability for me, it uses a TLS client certificate
to identify itself. When the client application needs to communicate
directly with CSI, it does so through a pre-authenticated capability.
If I need to establish a service capability without establishing agent
domain presence, I may do so using OAuth.

On Sun, Jun 28, 2009 at 5:34 AM, Carlo Wood<[e-mail]> wrote:
> I'm glad it doesn't imply that then :p
>
> Nevertheless, it worries me a bit. At some point we want to be able to
> teleport between grids right? Surely the people will want to have the
> same name (and shape) after they teleported in most cases.
>
> If the same first_name+last_name is only unique per grid, then
> people will (have to) start fights about names: one has to register
> the same first_name+last_name on every grid you want to use.
>
> The make a long story short: they same wars and trouble will immerse
> as are happening on IRC now: too many people in a too small namespace.
>
> At some point there will come the strong demand for a "nick serv",
> some central point where people can reserve their name for every
> large grid on the planet and claim for themselves (for example, to
> stop forms of impersonations). That would be 'hack'.
>
> I think we have to seriously think about this. Perhaps there is a
> better solution than 'first name / last name' to login ;).
>
> On Sat, Jun 27, 2009 at 03:54:08PM -0700, Infinity Linden wrote:
>> why would this imply global uniqueness? it describes a message sent
>> from a client to a particular protocol endpoint.
>>
>> On Sat, Jun 27, 2009 at 3:33 AM, Carlo Wood<[e-mail]> wrote:
>> >>    & identifier = {
>> >>      type: 'account',
>> >>      account_name: string,
>> >>      first_name: string,
>> >>      last_name: string,
>> >>    }
>> >>
>> >>    & identifier = {
>> >>        type: 'agent',
>> >>        first_name: string,
>> >>        last_name: string,
>> >>    }
>> >
>> > This seems to implicate that first_name + last_name
>> > have to be unique not only per grid, but globally
>> > for every virtual world.
>> >
>> > Is that true? Or would it be possible to use a different
>> > name on different grids? Would it be possible that different
>> > unrelated people use the same name on different grids?
>
> --
> Carlo Wood <[e-mail]>
>