Subject: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: OpenID and OGP : beginning the discussion ...]

From: Infinity Linden <[email-masked]>
Date: Sun, 28 Jun 2009 09:06:08 -0700

aha! yes! totally!

OGP is being designed in such a way that "agent concerns" are
separated from "simulation and object presence concerns." One of the
features of OGP is it allows (but does not require) that the
simulation host responsible for maintaining the physical state of
objects (location, orientation, shape, motion, etc.) _can_ be
administered by a different authority from that of the host
responsible for maintaining user information.

or, more succinctly, "the agent domain" may be run by a distinct
organization from the "region domain."

one of the reasons this was introduced was to allow one virtual world
to consist of regions that are administered by different people or
companies, but maintaining central services (like presence, inventory,
group IM, etc.) that lead to a consistent user experience.

in other words, our objective is to allow a user to login to an agent
domain, then establish their avatar's presence in a particular region
and allow that avatar to easily walk across a region boundary to a
region owned and operated by a different trusted operator, and have
that avatar's attachments, appearance and possessions follow them.
(though for expectation setting purposes i should mention that having
adjacent regions from distinct region domains is something that's "way
out there" in terms of schedule, as there's a lot more protocol
between adjacent regions than non-adjacent regions and it's yet to be
standardized in any meaningful manner.)

so... yes... moving from one region domain to another is fully
supported by the protocol.

having an agent defined in multiple agent domains is a little trickier.

On Sun, Jun 28, 2009 at 5:34 AM, Carlo Wood<[email-masked]> 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<[email-masked]> 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 <[email-masked]>
>

---

From: Carlo Wood <[email-masked]>
Date: Mon, 29 Jun 2009 12:51:40 +0200

But the fact remains that,

1) there will be more than one agent domain authorities where
   people can login.
2) The first+last name is the only way to identify people by
   the protocol(?) while in-world (everything else can be
   faked) and therefore, to stop impersonation, first+last
   name has to be unique globally.
3) This is NOT scalable. We'll run into a namespace problem
   (or you'll have to provide millions of last name -- is
   that possible without starting to use numbers?).

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 29 Jun 2009 04:13:08 -0700

>   name has to be unique globally.

as mentioned in the draft, deployers MAY choose to identify users via
account ids rather than first+last.

>   that possible without starting to use numbers?).

we've yet to run out of email addresses.

> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Carlo Wood <[email-masked]>
Date: Mon, 29 Jun 2009 13:45:12 +0200

> account ids rather than first+last.

But that is local to the deployers.

What is used to ID an agent in the server-server protocol
when a user walks from one region into another, or teleports
to a different region?

Firstname Lastname should be merely payload, not interesting
to the servers, not being used for anything except passing
it on the the viewers so they can use it to put in the tags.

There must be some other string, that is globally unique,
that is used to ID the agent. I was missing that string
in the first post that started this.

---

From: Mike Dickson <[email-masked]>
Date: Mon, 29 Jun 2009 08:44:51 -0500

I have to agree with Carlo on this.  This is a case where virtual life
needs to model real life.  Lots of people with the same name in the
world.  The protocol needs to support some other way to uniquely
identify a "user" other than FN/LN. 

When crossing into a new region it seems highly possible that a region
owner may want to require a re-authentication also. 

I'm not suggesting a solution becaus this isn't my personal area of
expertise.  Simply stating I see the problem and agree a good solution
needs to be found. 

Mike

---

From: Christian Scholz <[email-masked]>
Date: Mon, 29 Jun 2009 15:04:22 +0100

> identify a "user" other than FN/LN. 

I would also go further and say that it would be great to reuse
identities on non-3D social networks. As we see with OpenID this usually
is done via URLs (like myspace.com/mrtopf and now also
facebook.com/mrtopf) and I don't see why this shouldn't be used here as
well.
firstname/lastname should be provided as well of course (e.g. via
reading it over an OpenSocial REST API) but the real identity is then
defined via the URL. I am not sure where to display it though, if
directly over an avatar or inside the profile page but that needs some
experimentation I guess. At least some means need to be given to find
out which person it actually is.

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Carlo Wood <[email-masked]>
Date: Mon, 29 Jun 2009 16:17:49 +0200

That is a good idea.

My user editable 'postfix' in the tag is just a means to quickly
keep two friends apart, and get noted of a possible impersonation.

However, if the Real ID (tm) has any external significance as
you proposed, then it would make sense to show that in the profile.

On the other hand - if at some point you can only get into a
virtual world with some globally accepted and legally valid
ID that everyone got (that might be another 50 years, lol)
then I'd not be happy if that was sent to the viewer of everyone
that I run into. You have to keep the possibility open for
remaining relatively annonymous.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 29 Jun 2009 07:51:09 -0700

okay. i get you.

the question is, "how do you ID distinct users with the same name from
two different agent domains?"

an example use case might be... "You have two distinct users who both
have avatars named 'John Smith' registered with two distinct agent
domains (we'll call them 'avatarsrus.com' and 'businessworlds.com'.)
how do you make the 'John Smith' from avatarsrus.com identifiable as a
distinct entity from 'John Smith' from businessworlds.com so that both
could be rezzed into the same region and both own assets that are
rezzed in world simultaneously."

so you have two issues: first, how do you identify the two as being
distinct to the simulator and second, how do you identify the two as
being distinct to other users since they'll both have the "John Smith"
avatar name displayed.

the first (how are the two identified to the simulator) is that agents
will have a publicly addressable protocol endpoint in the form of a
URL at their agent domains. The first agent might have the URL
http://avatarsrus.com/a/Smith/John while the second has the URL
http://bsinessworlds.com/BDFB8691-9FD5-444A-B601-4075E7226242. The
format of the URL doesn't matter as long as the agent domain
guarantee's they're unique and under the control of the agent domain.

the second one is left as an exercise to client application developers
and is analogous to the difficulty end users may have in
differentiating two entities with the same name but distinct email
addresses.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 29 Jun 2009 08:01:18 -0700

if you implement an agent domain, you may choose to do this, but in
the same way that RFC822 and it's successors didn't require your email
address to be first initial + last name + @ + fqdn, i don't think it's
appropriate for a protocol to require a naming structure for the
virtual world.

we SHOULD definitely try to create a system by which you can publish a
URL for your agent (like http://example.org/Oh/Meadhbh or
http://example.com/MeadhbhOh) that is memorable and will yield a HTML
page with info about the agent, but also accepts LLSD messages for
things like "give me the user's public profile in LLSD" or "i'm a
trusted region domain, give me a capability i can use to return items
to the user's inventory". Further, i would add, that client
applications SHOULD respond to redirects when accessing these
resources. That way, if my agent domain _really_ wanted to export
something as http://example.org/a/BDFB8691-9FD5-444A-B601-4075E7226242
and then expose multiple URLs like http://example.org/Oh/Meadhbh and
http://example.org/Hamrick/Meadhbh, they COULD do that. (thought it
wouldn't be required that an agent domain do that.)

---

From: Infinity Linden <[email-masked]>
Date: Mon, 29 Jun 2009 08:35:47 -0700

> 1) there will be more than one agent domain authorities where

yes

>   name has to be unique globally.

no

>   that possible without starting to use numbers?).

doesn't matter, since we're not using first+last to try to uniquely
identify agents.

---

From: Carlo Wood <[email-masked]>
Date: Mon, 29 Jun 2009 18:11:21 +0200

> differentiating two entities with the same name but distinct email

Well, then I'm almost satisfied :).

There is still one problem however. Before the application developers
can do this, they need to receive some globally unique identifier
that is always the same (ie, an email address, but again, I REALLY
don't want to share my email address with people online).

Example, a viewer is connected and the corresponding agent resides
in a given region. There it meet another avatar. In order to display
the tag above this new avatar the viewer needs to receive Firstname
Lastname... but, as I've tried to argue so far, it ALSO needs to
receive a globally unique identifier that uniquely identifies the
person behind the avatar (or rather, his account) and please don't
let it be an email address ;).

The point being: the server-client *protocol* needs to be designed
such that this globally unique ID is made available to all viewers.

If this is the case, then I'm happy and there should be no problems
in the future regarding this. If no separate ID is provided then
several problems occur:
* Impersonation (people deliberately using the same shape and skin etc)
* IM's will be logged to the same file, because the viewer can't
  know who is who.

Also, the ID has to be same every time - because the viewer will
need to recognize that this John Smith is not AGAIN a new one,
but the same, every time.

---

From: Carlo Wood <[email-masked]>
Date: Mon, 29 Jun 2009 18:18:15 +0200

> but the same, every time.

To clarify; what started this thread was this:

    & identifier = {
        type: 'agent',
        first_name: string,
        last_name: string,
    }

Here I only see 'first_name' and 'last_name'.
As we've established now (I hope) this is not enough at
any level of the protocol, not between servers, but also
not between server and client.

Hence, it worried me. If you say "identifier" I expect
something globally unique.

I think this should be:

    & identifier = {
        type: 'agent',
 	uuid: string,
        first_name: string,
        last_name: string,
    }

Where the uuid is not only unique, but constant for any given
account (it doesn't change if one logs out and logs in again).
It could be an email address, but for privacy reasons I think
that should not be used; some hash seems much more logical.

---

From: Charles Krinke <[email-masked]>
Date: Mon, 29 Jun 2009 11:11:42 -0700 (PDT)

In some interop scenarios, and I am using HyperGrid as an example as it addresses the same problem, the current solution is to use:

<First>.<Last>@GridName.Com

Which is not an email, but is a unique identifier for an avatar on a particular grid.

As OGP moves forward, it seems reasonable to me that the Grids (or perhaps AgentDomains to use the vernacular here) are the authority for a particular avatar that comes from that grid.

Charles Krinke

________________________________
From: Carlo Wood <[email-masked]>
To: Meadhbh Siobhan <[email-masked]>
Cc: Infinity Linden <[email-masked]>; [email-masked]
Sent: Monday, June 29, 2009 9:18:15 AM
Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: OpenID and OGP : beginning the discussion ...]

   & identifier = {
       type: 'agent',
       first_name: string,
       last_name: string,
   }

I think this should be:

   & identifier = {
       type: 'agent',
    uuid: string,
       first_name: string,
       last_name: string,
   }

---

From: Infinity Linden <[email-masked]>
Date: Mon, 29 Jun 2009 12:19:18 -0700

hmm... i think over in the OGP world we have a history of being
enamored with capabilities and RESTful resources, ergo my suggestion
that an agent's unique ID be an URL. If the public URL a service may
go to to get public information about an agent is the unique ID for an
avatar, then you don't need a name to service resolution step, which
has some advantages. i don't want to sound partisan, but the
formulation below (that looks like an email address) seems to have the
potential for ambiguity.

On Mon, Jun 29, 2009 at 11:11 AM, Charles Krinke<[email-masked]> wrote:
> In some interop scenarios, and I am using HyperGrid as an example as it
> addresses the same problem, the current solution is to use:
>
> As OGP moves forward, it seems reasonable to me that the Grids (or perhaps
> AgentDomains to use the vernacular here) are the authority for a particular
> avatar that comes from that grid.
>
> Charles Krinke
>

---

From: Charles Krinke <[email-masked]>
Date: Mon, 29 Jun 2009 12:25:10 -0700 (PDT)

Hmmm. Well, it seems reasonable to me that each grid has one and only one first/last avatar of any particular first and last.

Admiteddly, I am more focused on the OpenSim and the OSGrid side of this interop discussion, but, since the precedent has already been set for <first>.<last>@GridName.Com it seems a reasonable and non-ambiguous method.

All avatars on OpenSim grids do have a UUID, so that could certainly be exposed. Then we could have conversations between "0123-4567-89ab-123456899abc-defa" and others instead of <first>.<last>@gridname.com, I suppose.

Charles Krinke

________________________________
From: Infinity Linden <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: Carlo Wood <[email-masked]>; Meadhbh Siobhan <[email-masked]>; [email-masked]
Sent: Monday, June 29, 2009 12:19:18 PM
Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: OpenID and  OGP : beginning the discussion ...]

---

From: Infinity Linden <[email-masked]>
Date: Mon, 29 Jun 2009 12:14:07 -0700

okay. cool. i see where you're going with this.

right. as a developer or a region domain, you want to depend on
something more globally unique than first name + last name, otherwise
you risk John Jones from example.com and John Jones from example.org
getting confused with each other. in the email case it's the human
who's the consumer of this name so the human can apply all sorts of
contextual pattern matching and fuzzy reasoning to try to figure out
if the two might be the same. but it would be imperative we have a way
to avoid REQUIRING region domain software from applying a list of
similar heuristics.

so yeah. a global identifier of some sort is good. it does not need to
be an email address, but it will have some of the same
characteristics: part of it will unambiguously identify the authority
(i.e. the FQDN of the agent domain host that holds info about the
agent) and the other half holds the identifier that is unique inside
that domain. i would vote we use a URI; they have these
characteristics, and they're not an email address that can be spammed.

but at the end of the day if you want distant systems to be able to
reference individual agents, you would need a way to address them, and
unless you wanted to REQUIRE a white list you have to admit the
possibility that a malicious adversary might try to force the protocol
or spam you.

i also don't think having two John Jones rezzed in the same region at
the same time is _that_ big of a problem, provided the region domain
and the client application have enough information to disambiguate the
two if it is required.

---

From: Joshua Bell <[email-masked]>
Date: Mon, 29 Jun 2009 13:41:18 -0700

Be aware that (firstname, lastname) as a unique identifier within a 
service is a quirk of Second Life, and not necessarily something that 
every OGP provider must use. One could imagine services that use single 
field account identifiers (like most email providers), or allow more 
flexibility in name choice to match real-world conventions.

It sounds like we're all agreeing, though - there will be some N-part 
unique identifier (which may be easily human readable, but may not) 
issued by an authoritative domain to a user, and given that the domain 
almost certainly has a globally unique identifier of its own (i.e. DNS 
name) there is a composition of the two that can give a globally unique 
identifier for the agent.

We should also be explicit that these identifiers are not necessarily 
also used as authentication credentials. Some service providers may want 
two-factor authentication (e.g. hardware key fob) or private login 
credentials distinct from any public identifiers for additional 
security. The 3-tuple login credentials (firstname, lastname, password) 
which Second Life uses today should not be viewed as the only allowable 
mechanism.

Joshua Bell (but *not* the Joshua Bell from http://www.joshuabell.com/)

Charles Krinke wrote:
> Hmmm. Well, it seems reasonable to me that each grid has one and only 
> one first/last avatar of any particular first and last.
>
> Admiteddly, I am more focused on the OpenSim and the OSGrid side of 
> this interop discussion, but, since the precedent has already been set 
> for <first>.<last>@GridName.Com it seems a reasonable and 
> non-ambiguous method.
>
> All avatars on OpenSim grids do have a UUID, so that could certainly 
> be exposed. Then we could have conversations between 
> "0123-4567-89ab-123456899abc-defa" and others instead of 
> <first>.<last>@gridname.com, I suppose.
>
> Charles Krinke
>
> ------------------------------------------------------------------------
> *From:* Infinity Linden <[email-masked]>
> *To:* Charles Krinke <[email-masked]>
> *Cc:* Carlo Wood <[email-masked]>; Meadhbh Siobhan 
> <[email-masked]>; [email-masked]
> *Sent:* Monday, June 29, 2009 12:19:18 PM
> *Subject:* Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: 
> OpenID and OGP : beginning the discussion ...]
>
> On Mon, Jun 29, 2009 at 11:11 AM, Charles Krinke<[email-masked] 
> <mailto:[email-masked]>> wrote:
> > From: Carlo Wood <[email-masked] <mailto:[email-masked]>>
> > To: Meadhbh Siobhan <[email-masked] 
> <mailto:[email-masked]>>
> > Cc: Infinity Linden <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> > Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: 
> OpenID and
> > OGP : beginning the discussion ...]
> >
> > Carlo Wood <[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Morgaine <[email-masked]>
Date: Tue, 30 Jun 2009 08:03:28 +0100

On Mon, Jun 29, 2009 at 9:41 PM, Joshua Bell <[email-masked]> wrote:

> Be aware that (firstname, lastname) as a unique identifier within a service
> is a quirk of Second Life, and not necessarily something that every OGP
> provider must use. One could imagine services that use single field account
> identifiers (like most email providers), or allow more flexibility in name
> choice to match real-world conventions.
>

+1

> unique identifier (which may be easily human readable, but may not) issued
> by an authoritative domain to a user, and given that the domain almost
> certainly has a globally unique identifier of its own (i.e. DNS name) there
> is a composition of the two that can give a globally unique identifier for
> the agent.
>

+1

>
> We should also be explicit that these identifiers are not necessarily also
> used as authentication credentials. Some service providers may want
> credentials distinct from any public identifiers for additional security.
> The 3-tuple login credentials (firstname, lastname, password) which Second
> Life uses today should not be viewed as the only allowable mechanism.
>

+1

Joshua, you've provided a very concise and precise summary of the overall
requirement --- I agree with this entirely.  Condensing it even further, we
need 3 things, and they are quite independent of each other:

   1. Arbitrary in-world name tags, which have only one intent: to provide a
   customer-satisfying visual name.
   2. Globally unique identifiers, either UUID or formed by composition of
   N-part local name @ issuing authority.
   3. Entirely separate authentication credentials, in other words,
   unrelated to 1) or 2).

Keeping these 3 things entirely disjoint would serve us well in many ways,
particularly in the key areas of scalability, flexibility, uniqueness, and
user-friendliness / appropriateness.

Morgaine.

---

From: Nexii Malthus <[email-masked]>
Date: Tue, 30 Jun 2009 09:34:06 +0100

Hmmm interesting.

So we have a server-side facing identifier received by the agent domain:
& identifier = {
   type: 'account',
   agent_domain: urlstring,
   account_name: string,
}
(Side question, should there be free-reign for server-side facing arbritary
data too? Could pose some interesting innovations between regiondomains and
agentdomains.)

And client-side facing identifier that is distributed by the server to other
agents as necessary received by the agent domain: (Should the server be
allowed to modify this at will? I could imagine the server wanting to
add/remove or edit meaningful entries programmatically, say a specific user
had admin, maintenance and/or support powers in a region?)
& identifier = {
   type: 'agent',
   arbritarykey: stringvalue,
   morekeys: morevalues,
   etc..
   etc..
}

Limits imposed of course naturally on the amount of keys and values
available and character limit on the strings. It seems like its up to the
client developers how to interpret these. I think, the very first key by
definition should become the most representative name that any client can
use in the most basic form and all other keys left up to interpretation.

What about other profile data? Should there be a agent-domain capability URL
in the client-side facing identifier that a client can use to request a caps
for the profile of this user?

- Nexii

On Tue, Jun 30, 2009 at 8:03 AM, Morgaine <[email-masked]>wrote:

>> service is a quirk of Second Life, and not necessarily something that every
>> OGP provider must use. One could imagine services that use single field
>> account identifiers (like most email providers), or allow more flexibility
>> in name choice to match real-world conventions.
>>
>
> +1
>
>>
>    1. Arbitrary in-world name tags, which have only one intent: to provide
>    a customer-satisfying visual name.

---

From: Carlo Wood <[email-masked]>
Date: Tue, 30 Jun 2009 16:10:49 +0200

> characteristics, and they're not an email address that can be spammed.

Agreed. I'd be fine with an url that includes the authority that holds
my account (login credentials). If only because then all viewers have
a nice point to 'contact' to report abuse.

> possibility that a malicious adversary might try to force the protocol

I'm not that afraid of spam :). I'm "afraid" that I wouldn't be able
to be a different person in SL, because everyone would be able to
find who I am and what i do in RL with a simple Google on my email
address. This is about privacy.

> and the client application have enough information to disambiguate the

It's definitely a lesser problem than if there can't be two John Jones
rezzed at the same time!

---

From: Infinity Linden <[email-masked]>
Date: Tue, 30 Jun 2009 07:05:22 -0700

the LLIDL describes the contents of a message, not it's address. the
construction

  &identifier = {
    type: 'account',        ; identifies this as an "account identifier"
    account_name: string,
    first_name: string,     ; optional - first_name and last_name
    last_name: string,      ; identify agent to log in as for accounts
                            ; with more than one agent
  }

describes a portion of the message a client sends to a fixed URL, for
the purpose of authenticating itself. it is assumed that the fixed URL
(the authentication URI) is known before attempting to log in. note
that in the account authentication technique accepts an optional
first_name and last_name to be used if the account associated with the
account_name maps to more than one avatar name.

the processing expectation is that the account_name will be a "long
lived" value. however, if people want to do service resolution with
another process and reference short lived values as account_names,
sure, but i don't really see the benefit in that.

i think my main point here is that the subject authenticates
themselves to an agent-domain specific URI, but a third party queries
an agent specific URI for public information about the subject, and
may use that agent specific URI as an identifier in other protocol to
request more information.

but maybe you're getting at the use of capabilities for privileged
access? here's an example.

1. a user authenticates with the example.com agent domain by
presenting it's credentials for the avatar InnovationGrrl Tester to
http://example.com/service/authenticate (the agent domain's
authentication URI,) receives an agent specific seed cap and a series
of agent specific service capabilities. InnovationGrrl's long lived
public URI is http://example.com/a/1AB69DB3-6A7C-4743-9651-AAFF2458B03D.
And, there's an alias for this public URI at
http://agents.example.com/Tester/InnovationGrrl, but it simply
redirects to the other URI. (the latter is there only if there's a
requirement for human memorable public URIs and to assist people who
use the <firstname>.<lastname>@<gridname> format convert it into a
canonical identifier.)

2. the user teleports to a region hosted at secondlife.com and leaves
an object in an area with auto-return turned on. (i.e. - in a few
minutes, the region will attempt to return the item to the agent.)

3. when the region needs to return the item, it requests a "return
item" capability from the agent domain and sends a (as of yet
undefined) message to the agent domain indicating that it is removing
a particular item from itself and the item needs to be returned to the
agent. the region identifies the agent with the long lived URI:
http://example.com/a/1AB69DB3-6A7C-4743-9651-AAFF2458B03D .

-cheers
-meadhbh

On Tue, Jun 30, 2009 at 1:34 AM, Nexii Malthus<[email-masked]> wrote:
>> Arbitrary in-world name tags, which have only one intent: to provide a
>> Globally unique identifiers, either UUID or formed by composition of
>> Entirely separate authentication credentials, in other words, unrelated to
>> 1) or 2).
>>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 30 Jun 2009 15:57:51 +0200

On Tue, Jun 30, 2009 at 08:03:28AM +0100, Morgaine wrote:
>  2. Globally unique identifiers, either UUID or formed by composition of N-part
>     local name @ issuing authority.
>  3. Entirely separate authentication credentials, in other words, unrelated to
>     1) or 2).
> 

While I also totally agree-- I think there is something missing there.
The authentication credentials will be 'constant', of course, but the
way the above is formulated, it could very well be possible that 2) is
not constant (A new UUID could be generated every login).

However, it is necessary that 2) is sent to all the viewers that come
into contact with an agent and in order to be able to recognize/verify
that agent automatically as having been seen before, and not being
an imposter, or even to just be sure you can append to the correct
log file (for example), 2) has to be the same every login.

Therefore, I'd like to propose this:

 1. Arbitrary in-world name tags, which have only one intent: to provide a
    customer-satisfying visual name.
 2. Globally unique identifiers, either UUID or formed by composition of N-part
    local name @ issuing authority, that remain the same over logins for any
    given account and that are passed to every viewer that receives 1).
 3. Entirely separate authentication credentials, in other words, unrelated to
    1) or 2).