[ogpx] Names, Identity and Protocol elements
David W Levine <dwl@us.ibm.com> Tue, 09 March 2010 15:53 UTC
Return-Path: <dwl@us.ibm.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1CD3A6957; Tue, 9 Mar 2010 07:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.579
X-Spam-Level:
X-Spam-Status: No, score=-5.579 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBYdvHUmo8WO; Tue, 9 Mar 2010 07:53:24 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 673003A6955; Tue, 9 Mar 2010 07:53:24 -0800 (PST)
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o29FnEa8008035; Tue, 9 Mar 2010 10:49:14 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o29FrSL5074908; Tue, 9 Mar 2010 10:53:28 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o29FrOCq010424; Tue, 9 Mar 2010 12:53:24 -0300
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o29FrOC0010416; Tue, 9 Mar 2010 12:53:24 -0300
In-Reply-To: <OF7DE90FC3.6FB8061F-ON852576E0.007C24F8-852576E0.007C5FF9@us.ibm.com>
References: <20100306142607.GB24621@alinoe.com> <e0b04bba1003061239n5a0f2957w6a506222b5e533ce@mail.gmail.com> <20100307003856.GA26690@alinoe.com> <e0b04bba1003062133s7aac5474qd88de97c78734d86@mail.gmail.com> <20100307143735.GA20862@alinoe.com> <e0b04bba1003070741g114b5ab4yac0794991e58f77f@mail.gmail.com> <OF7DE90FC3.6FB8061F-ON852576E0.007C24F8-852576E0.007C5FF9@us.ibm.com>
To: ogpx@ietf.org, ogpx-bounces@ietf.org
MIME-Version: 1.0
X-KeepSent: 08A0727E:FC0613D9-852576E1:0052B56E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OF08A0727E.FC0613D9-ON852576E1.0052B56E-852576E1.005749F5@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Tue, 09 Mar 2010 10:53:24 -0500
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/09/2010 10:53:24, Serialize complete at 03/09/2010 10:53:24
Content-Type: multipart/alternative; boundary="=_alternative 005749F5852576E1_="
Subject: [ogpx] Names, Identity and Protocol elements
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2010 15:53:29 -0000
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 "dwl@us.ibm.com" 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] Feedback to draft-hamrick-vwrap-authentica… Carlo Wood
- Re: [ogpx] Feedback to draft-hamrick-vwrap-authen… Morgaine
- Re: [ogpx] Feedback to draft-hamrick-vwrap-authen… Carlo Wood
- [ogpx] Fwd: Re: Feedback to draft-hamrick-vwrap-a… Meadhbh Hamrick
- Re: [ogpx] Feedback to draft-hamrick-vwrap-authen… Morgaine
- Re: [ogpx] Feedback to draft-hamrick-vwrap-authen… Carlo Wood
- Re: [ogpx] Feedback to draft-hamrick-vwrap-authen… Morgaine
- [ogpx] Updated draft of draft-levine-vwrap-client… David W Levine
- [ogpx] Names, Identity and Protocol elements David W Levine
- Re: [ogpx] Names, Identity and Protocol elements Morgaine