Re: [ogpx] Unique identities (was: Names, Identity and Protocol elements)
Morgaine <morgaine.dinova@googlemail.com> Sun, 21 March 2010 02:35 UTC
Return-Path: <morgaine.dinova@googlemail.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 49B353A68E9; Sat, 20 Mar 2010 19:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.865
X-Spam-Level:
X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[AWL=-1.889, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_45=1]
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 AZ-lclpCZUNk; Sat, 20 Mar 2010 19:35:22 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 41C0C3A688F; Sat, 20 Mar 2010 19:35:19 -0700 (PDT)
Received: by wwg30 with SMTP id 30so1539229wwg.31 for <multiple recipients>; Sat, 20 Mar 2010 19:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hHzBiz1JWReHZwcsqb9R6hbYqTFK2TShR8ZrBLX2LXQ=; b=Us+fYBKmVwI8HOPpJvAzVsS4MiB22yEZ78GeP0MQ8BiStGrWeIfwCDsfQuOGfnVIud tnPQXCsMo8V/iDzZOCguRfa4YzZHiTsb0Snixl3Qefwouq6/sOOtUbO5GvOzqXbumbkh D+Q3lVTEqzgTqYAoFGW4IUZ3YiTCWeqDlTi00=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ohmLDBIyjN9tcTy/LORJlK5BvN7V/p2UmNIiatxto4awBgVKXOrO/eSLA29DZx6VXo OvKc17epK1CcjRqgUr9HWAhg3vfjeY4rjabNrCRsbAH9onRwOUvKdX64FacsPioR6NUX ExQ64gThJJcpbEanKzzoSNPAZ1IUFYhWG62q8=
MIME-Version: 1.0
Received: by 10.216.188.8 with SMTP id z8mr1745181wem.47.1269138931033; Sat, 20 Mar 2010 19:35:31 -0700 (PDT)
In-Reply-To: <20100320133911.GA9372@alinoe.com>
References: <20100320133911.GA9372@alinoe.com>
Date: Sun, 21 Mar 2010 02:35:30 +0000
Message-ID: <e0b04bba1003201935v5d3db2e8y48831f65a9663d7b@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Carlo Wood <carlo@alinoe.com>
Content-Type: multipart/alternative; boundary="00163683300a27addc0482466f36"
Cc: ogpx-bounces@ietf.org, ogpx@ietf.org
Subject: Re: [ogpx] Unique identities (was: 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: Sun, 21 Mar 2010 02:35:24 -0000
I agree with this advice entirely. +1 Note however that you don't need to chisel bits off UUIDs in order to tag them with provider information. Do it cleanly, by leaving the UUIDs safe and untouched as full 128-bit entities as they are supposed to be, but associate them with a separate unique provider field. After all, there is no need for single-field atomicity nor the whole unique identity fitting into 128 bits. Cramming the 2-part information into 128 bits is premature optimization, and is actually unhelpful since the provider field should be separable. And finally, I'll point out a post from last June<http://www.ietf.org/mail-archive/web/ogpx/current/msg00089.html>about agent identifiers which is consistent with your advice. The unique agent identity should indeed be quite separate from the agent's chosen world name, as well as from the identity used for account authentication. Note also that Joshua likewise supported this kind of separation in the post to which I was responding, so I think there is broad agreement that this is a good approach. Morgaine. =============================== On Sat, Mar 20, 2010 at 1:39 PM, Carlo Wood <carlo@alinoe.com> wrote: > Uniqueness in general > --------------------- > > The generation of unique IDs is quite interesting by itself. > And quite a few unique IDs are needed in a good VWRAP protocol. > The approach taken by LL is generating number so huge that > they are unique by chance. This has two disadvantages: it > increases bandwidth usage and it requires to look up those > ID's in huge trees, because these ID's cannot contain information > in itself. Finally, it is not always possible to have untrusted > parties (ie, the viewer) generate UUID's, because they can > be set to anything and therefore deliberately still match > another already existing UUID. > > Another approach to generate unique ID's is to devide Unique > ID's over "Authorities" that can generate such ID's (these > would be servers). Each Authority would need a unique ID > by itself, and can then generate an arbitrary number of other > unique ID's by appending a locally unique number to it's > own ID. Likewise, the authorities ID could exist of an ID > unique for the administration running the server plus a > number unique within that administration and assigned by > that administration. This is, for example, the approach > that hardware vendors are using to identify hardware being > plugged into a PC. The ID itself contains a part that shows > one that the chip is made by nvidia (for example). > The advantage of that is, apart from that the ID's can be > much smaller, that each ID immediately contains a part > that reveals who is the authority, which then can be used > for routing the message to that authority, etc. > > Authorities are very important concept as well. In order > to avoid collisions (making incompatible changes to the same > thing in different places on the network, after which > re-synchronization becomes a nightmare), it is necessary > to route all messages regarding 'X', to a single authority, > the authority of X. Changing 'X' then exists of requests to > change it, and the authority will inform the requester if > this succeeded or not. For example, if on a given grid > someone creates a new chat group, then the viewer sends > a request to the authority of that chat group name (which > can be distributed by using the first character(s) of > the name to assign it's authority). That way, if two > people try to create the same group at the same time, > only one will succeed. > > Another reason that makes using authority-generated ID's > an advantage is that they are robust: it makes it impossible > to have a viewer generate an ID (see security problem above) > by accident; and it certainly makes it impossible to use > ID's in the protocol that also have the function of being > human readable! A mistake made many times in the current > protocol of SL: avatar names, region names, group names, > ... all of them are not only the human readable texts that > we want to see, they are ALSO the ID's of themselves by > which they are recognized in the protocol :(. As a result, > it is impossible to change them. Human readable text should > be nothing more than meta data. Hell, you could even give > a region more than one name, depending on the language > of the one visiting it. All protocol should use authority- > generated ID's, which by nature cannot be human readable. > The server would include human readable meta data for each > ID that represents something in-world, and the viewer would > do ID <--> human readable name mapping back and forwards > locally. Changing the name of something would be as easy > as sending a request to the ID authority to change the > name (resulting in a message with the new meta data to > everyone using it, without the slightest risk of a desync > during that update. You could even just wait till the > next login before providing the new meta data). > > -- > Carlo Wood <carlo@alinoe.com> > _______________________________________________ > ogpx mailing list (VWRAP working group) > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx >
- Re: [ogpx] Unique identities (was: Names, Identit… Morgaine
- [ogpx] Unique identities (was: Names, Identity an… Carlo Wood
- Re: [ogpx] Unique identities (was: Names, Identit… Michael Dickson
- Re: [ogpx] Unique identities (was: Names, Identit… Joshua Bell