Good morning! [email protected] schrieb: > Christian Scholz wrote: >> As for the web needing some more intelligent client, maybe that's right >> but then again we have to deal with it as it's now ;-) > > Yes, but that's not the case in Virtual Worlds :-)
Sure, but I think we differ a bit on our goals ;-) You want the best solution for OpenSim related worlds, I want the best solution for getting web and virtual worlds together (which includes some solution for social networks per se as well). So that's why I am mostly proposing standards already being used on the web. I think it also would benefit OpenSim if I can reuse accounts and data I have stored elsewhere and e.g. would be able to login to OpenSim via Facebook and have all my friends instantly available there as well. OpenSim even has an advantage over social networks in this case because distributed authorization and many other things are more naturally needed here than on the web (although that's changing as people store more and more data on more and more services and thus have more and more accounts to remember). It's basically more straightforward to connect certain regions than to connect various social networks because the latter only makes sense in the big picture while connecting regions might already be useful for a few people who want to come together. So OpenSim/Second Life could be pioneering this field (and many data resources are also similar, like profiles, IM, groups, friends list, assets) > Virtual Worlds have really big, fat clients, full of state and logic to > their eyeballs. Carrying keys/credentials for verifiable identity is a > tiny little thing to do, compared to all the other state they carry > around. Let's not complicate things just because the emerging protocols > for the Web 2.0 assume that clients are dumb. Our servers and clients > are being developed as we speak, and we can make them be smart. The > login process can be: > > 1. User enters ID (u...@idprovider) and destination world > (areg...@agrid) in the client > 2. Client logs in with the ID service -- not with the grid/region, > because if you do that you immediately place the user at risk of being > phished. Client gets masterKey directly from the IDprovider. Grid/region > don't exist in this step, there are no redirects. > 3. Client requests a key from IDProvider for launching an agent at > areg...@agrid, and it launches that agent, along with the key > 4. areg...@agrid calls back to IDProvider verifying that the given key > is valid for that user. Sounds good. Any plans on using OAuth for doing those requests? At least for signing them with those keys not for retrieving the access token? It basically would mean that the client is more involved in key transfer then usually on the web but the basic principle would be the same and then standardized. (I assume you have thought on possible attack scenarios for that process) > > Repeat for all other services. > > Later, users wants to Teleport to f...@foogrid. > 5. Client requests a key from IDProvider for launching an agent at > f...@foogrid, and it launches that agent, along with the key > 6. f...@foogrid calls back to IDProvider verifying that the given key is > valid for that user. > > etc. > > This is what Grider does. > A Web client could do that too, if the Web didn't insist on having its > browsers thin and blond :-) > So if there's a place in those new Web 2.0 protocols for smart, slightly > chubbier brunette clients that'd be great! -- then Tommil can have his > wish of login with his google account [safely]. I still cannot really see how you can do that. Where do I enter my OpenID? As for the web, surely browsers could be smarter but then they also would be harder to implement and you'd first to have to agree on a standard to do such things on the whole web. Esp. the latter seems very difficulty. It's also more flexible that way. Now OpenID providers can use various ways to authenticate a user. If clients only provide username/password auth then that would eventually be limiting. Right now web browsers act maybe more like an operating system. You write your app and run it there and it has certain possibilities with the downside of course that you have a dumber client (although one could maybe implement a plugin but getting mass adoption of that is hard and any download a user needs to do will most likely not be made which raises the barrier of entry). -- Christian > > Crista / Diva > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: [email protected] fon: +49-241-4007300 fax: +49-241-97900850 personal email: [email protected] personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
