this is what we're thinking we're going to do in VWRAP.<div><br></div><div>we're going to define an authentication service that's run by the agent domain. (for peeps new to VWRAP, a "domain" is a collection of network hosts with the same "administrative authority." the "agent domain" is a domain that provides mostly "agent related" services, including the authentication service.)</div>
<div><br></div><div>individual users will authenticate against this authentication service. then some magic happens and the user's avatar is placed in a region in a region domain.</div><div><br></div><div>the "magic" that happens after user authentication and before the user's avatar gets placed is that the agent domain has to figure out the service URL of the region to place the avatar, and that region has to figure out if it trusts that agent domain.</div>
<div><br></div><div>so the current expectation is that we'll probably have a couple large agent domains like secondlife, OSGrid, etc. and maybe even a few managed by large companies for the benefit of their employees. once the user's client application is authenticated to the agent domain, the client application may request that the agent domain place the user's avatar in a region. (note! with VWRAP, you can be authenticated to an agent domain for the purpose of participating in group chat or inventory manipulation without being rezzed in world.)</div>
<div><br></div><div>and here's where it gets mildly funky. the agent domain and the region domain need to have _some_ level of trust with each other, or they have to be explicit about the fact that they trust everyone. agent domain authorities may not want to rez an avatar in an untrusted region. the canonical example of this is second life not wanting to rez an avatar and all it's attachments in the "pirate bay" region. some regions may not trust all agent domains. consider a series of regions administered by IBM, for the purpose of transacting IBM business. i'm not an IBM employee, but it seems reasonable they would like to know who's rezzing in their regions, so they may establish a policy of only allowing people with accounts on IBM's agent domain to be able to rez in their region domain.</div>
<div><br></div><div>there are currently two proposals for managing this trust. the first utilizes PKIX (which is a subset of X.509) to define semantics for interpreting the subject name of client side certificates in transactions carried over HTTPS. the other is the use of OAuth for one domain to explicitly grant access to another domain's systems for a particular purpose. both systems look like they're going to be fully specified, giving deployers a choice as to which auth scheme they want to use.</div>
<div><br></div><div>-cheers</div><div>-meadhbh</div><div><br></div><div>--<br> infinity linden (aka meadhbh hamrick) * it's pronounced "maeve"<br> <a href="http://wiki.secondlife.com/wiki/User:Infinity_Linden">http://wiki.secondlife.com/wiki/User:Infinity_Linden</a><br>
<br><br><div class="gmail_quote">On Tue, Nov 24, 2009 at 06:59, Impalah Shenzhou <span dir="ltr"><<a href="mailto:impalah@gmail.com">impalah@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ok, maybe it's a misunderstood. I will try to explain what I wanted to know:<br><br>Imagine 100000 region servers pretending to be a grid.<br><br>What I understood from Morgaine comment:<br><br> Opensim needs decentralized /
distributed mechanisms for <i><b>identity</b>,<br><br></i>
was<br><br>"I have entered that grid, my authentication was managed by one region server. When I try to jump to another region in the same grid I have to authenticate again in the region server and that region server must contain my data to authenticate me again".<br>
<br>Nowadays is like: Enter in a grid, being authenticated by a common user server, when I want to jump to another region in the grid, I don't need to authenticate me again.<br><br>What I understand with "descentralized" is: each opensim servers has the mechanisms to authenticate an user even when it is part of a grid.<br>
<br>And that is what I don't understand: why? why not to surrogate the authentications to specialized and centralized servers.<br><br>And that was the reason for my question about OpenID, maybe this is a system considered "decentralized".<br>
<br><br>Anyway I can't see anything bad on centralized servers. If anyone wants to enter in my server he/she have to follow my rules; if I have 1000 servers, I provide you with a common auth mechanism for accessing all of them.<br>
<br>Or maybe I am completelly wrong.<br><br><br>Greetings<br><br><br><br><br><br><div class="gmail_quote">2009/11/24 Robert A. Knop Jr. <span dir="ltr"><<a href="mailto:rknop@pobox.com" target="_blank">rknop@pobox.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div class="h5">
I don't know that this really *is* offtopic, unless it's already a<br>
settled issue amongs the OpenSim devs.<br>
<br>
On Tue, Nov 24, 2009 at 02:19:20PM +0100, Impalah Shenzhou wrote:<br>
> I could trust in you, but you need to tell me "you are really you" with a<br>
> local login (i.e. email headers can be altered to impersonate as another<br>
> person) or someone I trust should tell it to me (i.e. OpenID).<br>
<br>
Do you have any personal web pages anywhere? Do you run any CGI or any<br>
PHP there? Do you identify everybody who comes there? That's the<br>
analogy we should think about. Yes, we need a secure infrastructure so<br>
that only the small number of people you *really* trust can do scary<br>
things. But at the level of running regions -- well, you may be using a<br>
hosting provider, or you may be hosting yourself, but you don't need<br>
full and complete trust that everybody is who they claim to be just to<br>
connect to the world.<br>
<font color="#888888"><br>
--<br>
--Rob Knop<br>
E-mail: <a href="mailto:rknop@pobox.com" target="_blank">rknop@pobox.com</a><br>
Home Page: <a href="http://www.pobox.com/%7Erknop/" target="_blank">http://www.pobox.com/~rknop/</a><br>
Blog: <a href="http://www.sonic.net/%7Erknop/blog/" target="_blank">http://www.sonic.net/~rknop/blog/</a><br>
</font><br></div></div><div class="im">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iD8DBQFLC+pcfEn1oMJSrdsRApVqAKCGz8o5gt7vEqvl3HJK07jftpLi5wCg56g+<br>
oq1mcfGvljoH5K0Y6X/WX9M=<br>
=bh/M<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>