[Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Christian Scholz]

Good morning!

diva at metaverseink.com 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 (user at IDprovider) and destination world 
> (ARegion at 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 
> ARegion at AGrid, and it launches that agent, along with the key
> 4. ARegion at 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 Foo at FooGrid.
> 5. Client requests a key from IDProvider for launching an agent at 
> Foo at FooGrid, and it launches that agent, along with the key
> 6. Foo at 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
> Opensim-dev at lists.berlios.de
> 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: info at comlounge.net
fon: +49-241-4007300
fax: +49-241-97900850

personal email: cs at comlounge.net
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net