Subject: [ogpx] Feedback to draft-hamrick-vwrap-authentication-00.txt

From: Carlo Wood <[email-masked]>
Date: Sat, 6 Mar 2010 15:26:07 +0100

2.3.1.  Agent Identifier
2.3.2.  Account Identifier

These paragraphs (and possibly further on in the document)
refer to a first_name and last_name that together identity
an agent.

The very word 'name', certainly in combination with 'first'
and 'last', strongly suggest that these two are sequences
of octets from a restricted set, most notably, that they
should not contain unprintable characters, punctuation or
spaces.

* What is missing the definition of what characters each
  name may be made up of, and what are the maximum lengths
  that need to be supported.

Moreover, if first_name and last_name may not contain a
space, and if neither makes ever sense to be used alone
(which is the case imho), it is not really the business
of VWRAP to deal with first_name and last_name separately.

Instead one can simply define an opaque sequence of octets
representing the "Agent Identifier", which in practise
might or might not be "first_name last_name" (separated
by a space).

* I miss the point that makes it necessary to take the
  Agent Identifier apart into two not further defined
  strings.

Note that if a client application wishes to make an
explicit difference between the "first name" and "last
name" part, for example by using two separate input
fields when the user has to input them, then it can
still do so, and catenate the two before sending it
to the agent domain.

1. I propose to remove the notion of "first and last
   names" from the VWRAP documents. And only speak
   about Agent Identifier (a single sequence of octets),
   and Account Identifier (likewise).

2. Maximum length and the characters that need to
   be supported should be defined in the document.

Finally, note that if Second Life (tm) requires
a First and Last name string internally, they can
still have those: The Agent Identifier is generated
by Linden Lab, they can enforce that it exists of
two names separated by a space. So, it would be
minor/small change to accept a single string in
the authentication protocol and than separate that
again into two tokens upon receipt.

-- 
Carlo Wood <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Sat, 6 Mar 2010 20:39:32 +0000

> refer to a first_name and last_name that together identity

The {first_name} + {last_name} concept has no place in VWRAP as a
requirement anyway.  That's a particular property of Second Life.

We've discussed agent naming here on previous occasions, and suggested more
general alternatives to the approach used in SL.  Needless to say, policy on
the names that are visible within any given world is a matter for that world
to decide.

Many worlds will have in-character naming policies which reflect the nature
of their world to preserve immersion, others will enforce narrow RL
worldviews, while others will be entirely free.  It's not our job to dictate
naming policy, but to provide the protocol infrastructure to allow all
technically-viable naming policies to be expressed.

This -00 draft is the original draft which has not yet taken our previous
discussions on this topic into account.  Subsequent drafts will no doubt
reflect our input.

>   be supported should be defined in the document.

I agree.

However, don't forget the "@<world>" or "@<identity_provider>" issue which
we've discussed before.  Unadorned names will not be unique by themselves.
It is of course up to users whether other people's fully qualified identity
is displayed in their viewer or not.  No doubt this will become a user
setting.

A region will commonly contain visitors from many different worlds.  Some of
those worlds will run their own name registration service as well, but there
will also be independent name registrars that run no world of their own,
providing identities which can be used with any compatible world.  Again, we
do not set policy, but we expect VWRAP to enable worlds to accept agents
names (as well as full avatars) registered with any compatible service,
should they wish to do so.

Morgaine.

============================

On Sat, Mar 6, 2010 at 2:26 PM, Carlo Wood <[email-masked]> wrote:

> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Carlo Wood <[email-masked]>
Date: Sun, 7 Mar 2010 01:38:56 +0100

On Sat, Mar 06, 2010 at 08:39:32PM +0000, Morgaine wrote:
> The {first_name} + {last_name} concept has no place in VWRAP as a requirement
> anyway.  That's a particular property of Second Life.

+1

Meadhbh wrote me back in private (something I don't understand, why
not use this list?) that the reason for using first + last name
is to accommodate existing implementations like Second Life and
Opensim.

I think that is not a valid agrument. We're designing a standard
here, and there is no place for legacy in a new standard. I already
pointed out in my first post that it is extremely simple to switch
to a single Agent Identifier string anyway (just catenate first and
last with a space in between).

What also worries me in this is that apparently the current
Second Life protocol is considered to be canonical VWRAP, and
it is apparently not possible to define a VWRAP that doesn't
match the current existing protocol used by Linden Lab.

If Linden Lab thinks that it's hard to switch such things
(from First + Last to a single AgentIdentifier), then I'd
like to stress again the importance of protocol negotiation!!!

PS With protocol negotiation being a standard part of every
   VWRAP connection, it would be the simplest of tasks
   to switch from First+Last to VWRAP, even allowing
   a few years for viewers to switch (before dropping
   support for the legacy login).

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 6 Mar 2010 18:44:14 -0800

Sorry. Yes, this was supposed to go to the list.

---------- Forwarded message ----------
From: "Meadhbh Hamrick" <[email-masked]>
Date: Mar 6, 2010 8:18 AM
Subject: Re: [ogpx] Feedback to draft-hamrick-vwrap-authentication-00.txt
To: "Carlo Wood" <[email-masked]>

hey carlo.

i think the intent was that names (first, last and account) were to be
LLSD strings, which are defined in the LLSD / LLIDL draft. at a first
order of approximation, this means they can consist of any unicode
code point (note that this is not precisely true. refer to the type
system draft for more info.)

the rationale behind using a first and last name is to support
existing systems like Second Life and OpenSimulator, both of which
still consume first/last/password in the login sequence. the auth
draft includes an option to log in using an "account" identifier.

i think the idea here is that implementers that currently expect a
first/last/pass that want to use VWRAP to transport the authentication
info would use the agent identifier while implementers that wanted to
use a different ID ( like email address ) would use the account
identifier.

so they're there for two different use cases. agent id is for legacy
systems (and for people who just want to continue using
first/last/pass) and account id is for future implementations that may
want to use a single id.

that these two points weren't obvious probably points to a need to add
some verbiage in the draft discussing the motivation for account vs.
agent identifiers, and to mention (at least in passing) that
identifiers are strings as defined in the type-system draft.

thx for bringing this up, carlo.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Sat, Mar 6, 2010 at 6:26 AM, Carlo Wood <[email-masked]> wrote:
>...

---

From: Morgaine <[email-masked]>
Date: Sun, 7 Mar 2010 05:33:28 +0000

> match the current existing protocol used by Linden Lab.
Haha, don't even jest about it. :-)

The Linden goal I suspect is to ensure that VWRAP includes that subset of
protocol functionality that they intend to use some years in the future, so
that they will have a good chance of evolving SL to become VWRAP-compatible
one day.  At least that's what my interest would be if I were in their
shoes.

It's worth pointing out that nobody gets a free ride here though.  Everyone
will have a large implementation job ahead of them to implement VWRAP even
minimally, and even more so if they embrace multiple external services and
multi-world interop.

Limiting VWRAP to *only* the subset that a particular party wishes to deploy
would of course be completely inappropriate, and once we agreed on our
scope, such a thing became impossible anyway.  After all, VWRAP is to
be a *virtual
worlds interop* protocol (as we finally ascertained after much heated
discussion), not a walled garden building protocol, even though building a
walled garden will be one possible deployment, a subset of its capabilities.

The article that we wrote for IEEE Internet Computing pretty much says it
all in its title alone:  "*VWRAP for Virtual Worlds Interoperability*".  The
current SL protocol doesn't do that at all, so considering it "canonical
VWRAP" isn't even an approximation.

In summary, I think your worry might be slightly too strong.

Morgaine.

===================================

On Sun, Mar 7, 2010 at 12:38 AM, Carlo Wood <[email-masked]> wrote:

> requirement

---

From: Carlo Wood <[email-masked]>
Date: Sun, 7 Mar 2010 15:37:35 +0100

You reverse things. Second Life CAN be a subset of VWRAP, and
VWRAP still being able to do so much more. So, whatever we
agreed upon that VWRAP will support, that basically doesn't
exclude the current SL protocol to be a subset of it.
It WILL cripple VWRAP however-- in the best case it would
be a new standard full with exceptions and special cases
to support some "other" legacy protocol.

Nevertheless, I don't have a problem with even THAT.

For example, instead of sending:

first: string
last: string

we could define VWRAP to accept either, first/last OR

agentID: string

and then define everything in terms of that string and
define it to be "first last" in the case the former is used.
That way SL would be VWRAP compatible as it is.

However, that is not the way to go: it polutes the protocol.
Now, using ONLY first/last and not accepting agentID just
because there is an existing legacy protocol that needs it
isn't acceptable either. So... what is the proper solution?

Imho, the proper solution is to define VWRAP to demand

agentID: string

and add Protocol Negotiation to allow Linden Lab to add
a (temporary, if they so wish) extension for first/last.
The result will be a smooth transition for them, a well
defined VWRAP protocol and no legacy protocol ten years
from now.

Also, I'm convinced that this Protocol Negotiation will
be handy (needed) many, many time more often. Not foreseeable
now even. It's a must, so why not add it and get rid of
problems like this?

On Sun, Mar 07, 2010 at 05:33:28AM +0000, Morgaine wrote:
> that they will have a good chance of evolving SL to become VWRAP-compatible one
> day.  At least that's what my interest would be if I were in their shoes.
> 
> Limiting VWRAP to only the subset that a particular party wishes to deploy
> would of course be completely inappropriate, and once we agreed on our scope,
> such a thing became impossible anyway.  After all, VWRAP is to be a virtual
> worlds interop protocol (as we finally ascertained after much heated
> The article that we wrote for IEEE Internet Computing pretty much says it all
> in its title alone:  "VWRAP for Virtual Worlds Interoperability".  The current
> SL protocol doesn't do that at all, so considering it "canonical VWRAP" isn't
> even an approximation.
>

---

From: Morgaine <[email-masked]>
Date: Sun, 7 Mar 2010 15:41:53 +0000

I did say that a walled garden would be one potential deployment pattern of
VWRAP ("*a subset of its capabilities*"), so yes, current Second Life
protocols can indeed be a subset of VWRAP.

But that would be a highly degenerate boundary case as it would miss out on
the very clear main thrust and potential of VWRAP, which was very
effectively described in our article as "VWRAP for Virtual Worlds
Interoperability<http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf>
".

And it would also miss out on the massive scalability numbers upon which the
whole OGP effort was founded, so I don't think it's a realistic projection
of anyone's intentions.

Regarding agent naming, sure, the current choice in the SL service is not
generic so hardwiring it into VWRAP would not be sensible, nor would it
serve the general interest.

However, don't assume that LL actually *wants* to retain current
restrictions on agent naming long term --- their vision undoubtedly extends
beyond what they have implemented today, and I expect that draft -00 was
just a starting point.  It's to everyone's ultimate benefit to make such
data fields generic.

What seems to have got lost in the discussion here though is the "<world>"
or "<identity_provider>" data field that is a mandatory complement to the
agent name, since agent names will be unique only within a given identity
registrar service.

Morgaine.

===============================

On Sun, Mar 7, 2010 at 2:37 PM, Carlo Wood <[email-masked]> wrote:

> scope,
> all

---

From: David W Levine <[email-masked]>
Date: Mon, 8 Mar 2010 17:38:28 -0500

I have submitted an updated version of client caps, primarily fixing 
spelling, removing 
a bad example choice, and clarifying a couple of design choices.  This is 
the
version I will be discussing at Anaheim. 

http://www.ietf.org/id/draft-levine-vwrap-clientcap-01.txt  should find 
it. 

- David
~ Zha

---

From: David W Levine <[email-masked]>
Date: Tue, 9 Mar 2010 10:53:24 -0500

There have been a couple of comments on the use of "first name" "last 
name" within the current specifications. 

I think we need to be very careful to sort out the various uses of "name" 
and "identity" in what VWRAP sets out to do. 

There are a number of uses, and I suspect they are currently tangled up, 
because there has been no reason to fully
separate them. 

How are "names" used? 

To start with there is the "user information" used when logging on to an 
authentication service. There is then the identity which
that login asserts. These may not be the same. There is then the display 
name used to tell other users who I am, and lastly, but
in many ways most importantly, one wants a clean, globally usable token 
that can be used by services to identify the end user. 

In Second Life, and in OpenSim, the "user information" has historically 
been "First Name" "Last Name". This is combined with
a password, and gets one logged in. It so happens that the display name is 
the same as the user information provided at login. 
This isn't universal. In the Second Life Enterprise product, I login using 
my Corporate LDAP credential. This means my
"User information" is "[email-masked]" but when I log on, my Avatar's name 
is pulled from LDAP and shows up as "David Levine" 

In both Second Life and OpenSim, the user ends up being associated with a 
UUID. This is fairly acceptable in a closed grid
but in a world with multiple grids, while the UUID is likely to be unique 
(If not, what is the point of the Unique in UUID?) We really
would like to associate a user's identity not with just a token, but a 
source. In the current specifications, this is partly implied by 
the agent domain to which the user logs in. One can reasonable argue that 
"Jane Smith validated by the Agent Domain at Walters
RackHaus SimHosting" is the implicit name when that agent domain presents 
"Jane Smith" to a region. There are at least two
concerns lurking here. In the SLE case I mentioned above, Jane Smith's 
identity, isn't really anchored in the corporate Agent
Domain, but the underlying LDAP, and in many ways, that is something I 
want to know about. This is equally cogent when we
want to permit OpenID or Oauth to participate in the process of managing 
authentication and identity.

The point about the underlying authentication also becomes interesting 
when we want to provide secure access to 
meta data about the user. The current teleport writeup includes a bunch of 
meta data, such as whether the user has 
provided a credit card, whether they are adult (by a  unspecified metric) 
This is good and useful information, but we
probably need to cleanly separate it from identity, and tie it to the 
source. This becomes especially cogent when
one has more and more services which want to apply policy based on the 
user's identity and meta-data. 

I think we probably need to walk through our use cases, and make sure 
we've got all the major bases covered.
At a minimum, I think we need to cleanly separate out "Login information" 
from "Display Name"  I think we also need
to expose the basis of authentication, and we need to expose a path to 
identify and manage meta-data about the user. 
It is far less useful to know that a "rez_avatar" request includes the 
tuple (Age_verfied,True) if I cannot determine the
source of that validation. (or, "Corporate Employee, "Corporation name") 
again, without a source and a path to validate
the source.

- David
~ Zha

---

From: Morgaine <[email-masked]>
Date: Tue, 9 Mar 2010 16:50:39 +0000

+1 to David.  This corner has a lot of cobwebs in it and needs dusting.

As David identifies, common usage and current service policy have got all
mixed up with mechanism in this area.  They need separating so that users of
VWRAP are not bound by someone else's business choices.

David's point about the need to drill down and uncover the underlying
identity in some scenarios is particularly relevant, as it highlights how
certain choices are totally local rather than generic to the protocol.  For
each party that has a requirement to uncover underlying identity, there is
another party that has the requirement that underlying identity *MUST
NOT*be uncoverable.

What's more, issues of privacy, security, and immersionism vs augmentism,
weigh in on both sides of the argument, so this is not a simple area.

As always, the only way we can tread a safe path through this horrible
thicket is by separating mechanism from policy entirely in VWRAP.

Morgaine.

=================================

On Tue, Mar 9, 2010 at 3:53 PM, David W Levine <[email-masked]> wrote:

>
> There have been a couple of comments on the use of "first name" "last name"
> within the current specifications.
>
> Domain, but the underlying LDAP, and in many ways, that is something I want
> to know about. This is equally cogent when we
> The point about the underlying authentication also becomes interesting when
> we want to provide secure access to
> I think we probably need to walk through our use cases, and make sure we've
> got all the major bases covered.