Re: [ogpx] Names, Identity and Protocol elements

[Morgaine <[e-mail]>]

+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 <[e-mail]> wrote:

>
> 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 "[e-mail]" 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
>
>
>
> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>