It seems to me that if the "global" name is considered to actually be URI/user/UUID/[+stuff] as diva is suggesting, then any ambiguity is resolvable by the original system.<br><br>If that URI becomes invalid then there are already mechanisms to resolve successor URIs as needed.<br>
<br>If there is some conflict (i.e. a long stored backup) then the assumption must be that wherever the UUID is found must be the "successor". <br><br>This is not foolproof if someone is truly malicious, but any naming system can be spoofed without some other form of authentication.<br>
<br>The obvious "worst case" here is to have several systems which appear to be the "sucessor" to the original.<br><br>This is why I suggested using a type 1 UUID which is derived from the originator's MAC address and a time stamp. It was originally abandoned because identified the originator so very well (see THAT extended discussion! LOL), but in this case we actually want an unambiguous identification.<br>
<br>In the worst case I described then you would have to hunt for other UUIDs available to you which have the same MAC address and similar time stamps for clues as to which is the "genuine" system. It then becomes a probability game in which the genuine successor has likely originated many more name/UUID pairs than a forger.<br>
<br>I agree fully that the central authority does not solve this problem, it merely makes another target for the "bad guy" to corrupt, take over or spoof. Peer to peer technology (e.g. Bottorrent and Emule/KAD) has developed a very robust authentication system with no central server required for example.<br>
<br>Karen<br><br><div class="gmail_quote">On Sun, Aug 29, 2010 at 11:50 AM, Mike Dickson <span dir="ltr"><<a href="mailto:mike.dickson@hp.com">mike.dickson@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sigh<br>
<br>
The name has absolutely zero value for any sort of attribution.  I can<br>
have the same name someplace else (or on the same grid if the grid owner<br>
allows it an uses some other identifier or mechanism for<br>
authentication). Only UUID is valid to identify a specific agent.  Also,<br>
what if I don't want just anyone to know the full names of my users.  Or<br>
if I use a slightly different mechanism to describe a user (email<br>
addresses for instance).<br>
<br>
The core developers have said over and over again that OpenSim is a<br>
framework.  That being the case the semantics of "names" can vary across<br>
grids and how could you ever depend on anything like that to do<br>
"attribution".  Only the Agent service for a grid should be able to<br>
resolve agent id's down to more specific information.  In that way it<br>
can also provide whatever access controls on that information the grid<br>
owner prefers in order to enforce that grid's TOS.<br>
<font color="#888888"><br>
Mike<br>
</font><div><div></div><div class="h5"><br>
On Sun, 2010-08-29 at 18:33 +0000, Melanie wrote:<br>
> I disagree strongly.<br>
><br>
> Assume object O has been created by user A on grid X.<br>
><br>
> He then rezzes a copy on grid Y and sets it for sale.<br>
><br>
> Grid X then goes down, either because it was just a temporary<br>
> standalone, or it went bankrupt, or got sued out of existence.<br>
><br>
> Someone buys O in Y and takes it to grid Z.<br>
><br>
> Now, what is grid Z going to display as creator name? It can't ask<br>
> grid X, since it's gone. Can't ask grid Y, as it would claim to be<br>
> nonauthoritative, even if it did have a cached value.<br>
><br>
> Result: attribution is lost.<br>
><br>
> This is why I believe the URL needs to contain enough information to<br>
> at least allow the display of the name of the creator as the creator<br>
> was known at that time and the grid of origin.<br>
><br>
> Melanie<br>
<br>
</div></div></blockquote></div><br>