Well, if a key is an arbitrary string, then it may also be a constant UUID value, e.g. the standard session id we have now, so (c) really includes (b).
Now, my vision of the future 3d internet is that all grids will be walled gardens, trust domains, as an analog to a large, multi-server website. I see people move between those trust domains using the Hypergrid protocol and client side teleporting. I see people use nonlocal messaging (Jabber, etc) instead of local grid comms. Therefore, I believe the ability to run a trust domain with hypergrid ability should be maintained, we should not mandate that all protocols in all cases must assume untrusted regions, because I see those in the hypergrid, rather than the local grid in the future. Hypergridding between these trust domains, I believe, must involve the target domain's user server, which would, in the case of (c), negotiate the key with the viewer. So, for now, (c) is the way to go, just don't forget the (b) use case. Interregion trust should remain possible. Melanie Diva Canto wrote: > I've been debating with myself and with some ppl in IRC about whether > OpenSim should support many security schemes or shoot for the most > generic one. Advice appreciated. Here's the situation. > > There are already 3 different authentication schemes on the pipeline for > Teleports, one of them being the current one, and two being on my local > non-committed changes. These 3 schemes are: (a) no authentication; (b) > session authentication; and (c) key authentication (keys being unique, > one-time strings for each client-server pair). > > (a) is what is currently in place -- hence my nagging about the lack of > security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine. > (b) is a weak form of authentication that prevents spoofing from the > outside of a grid, but that doesn't prevent spoofing from inside. That > is, regions can find out the sessionID of users when they're logged in, > and impersonate them. In open grids this is highly unsafe; but in > walled-garden grids, this is perfectly fine. > (c) is the strongest form, as it allows clients to have a lot more > control -- not the raw Linden client, which doesn't quite do that, but > others. (c) can also be implemented in the current setup, with the raw > Linden client, and with server-side teleports. It's kind of meaningless > in this case, but it's no worse than (b) for open grids. > > So, back to the original question. Should OpenSim support all of these > and more, or should we shoot for (c) only? > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
