Tommil,
Thanks for the pointers about OAuth. I think this is really important.
We need to figure out what security scheme works best for open Virtual
Worlds. I don't necessarily think that we need to tie OpenSim to one
specific scheme, but we really need to figure out what the user
experience will be with the different schemes. My belief is that Virtual
Worlds are [should be] slightly different than plain Web because of the
focus on identity preservation, which the Web has sucked at big time,
and things that work well for [these annoyingly identity-unaware] Web
apps may not work so well for VWs. Or, put in another way, we can make
VWs work better than the Web -- that's my goal, at least :-)
Being a researcher, I am naturally unimpressed by credentials on paper /
standards, etc; we always need to think through the details and find out
the real consequences of applying one thing vs. the other in the
concrete context we have here.
All this is relatively new to me, so I may not have the complete
picture, but let me make that much needed attempt at comparing
Capabilities and OAuth in the context of something very concrete in
OpenSim: inventory access. I'm going to be using a mix of OAuth terms
and caps terms.
Let's assume that in both cases the untrusted regions are not given
a-priori the authorization to access the user's inventory service (this
is policy, not mechanism). Instead, the client that the user is directly
using will be given that capability/authorization. So assets will flow
directly from the Service provider to the User's client, without the
region ever being involved.
The interesting thing is what happens when the user Rezzes something
from her inventory onto the region. Let's walk through the details in
each case.
*** Capabilities ***
That POST will be guarded by two capabilities:
(1) The first Capability is the one granted (or not) by the region to
the user's agent for the function of posting something to it. This cap
is obtained in the initial negotiation that happens when the user's
agent connects to the region. This would precede or replace or build
upon the existing "permissions" -- we would basically move the existing
authorization logic to capability exchanges. Then posting something is
just a matter of invoking a secret CAP URL on the region.
(2) The second Capability is the one granted by the user to the region
for the function of accessing that specific item in her inventory
service provider. So the user's client would do two things, under the hood:
(a) Instruct the inventory service to place a service handle at a
specific secret URL, for example:
http://osgrid.org:8004/d65bdadd-781f-41f8-ae68-d1791e7e3af4/<ItemUUID>
(b) Send that secret Cap URL to the region
Note that this would all happen without explicit user intervention; the
simple fact that the user has issued the "order" to rez an object from
her inventory in that region would trigger all these capability
exchanges automatically.
*** OAuth+OpenID ***
The Rez scenario is as follows:
(1) The user's agent posts the order to rez the object to the consumer
region. There needs to be logic on the region side dictating whether
that user has the authorization to do such a thing. This logic defies
OAuth as it is designed, because it would require the region admin (a
person) to explicitly give the authorization. OAuth assumes that there
is a *person* involved in the authorization step. So this "person" needs
to be coded in the regions, more or less like what it is now --
ACL-style. The mechanics can be the same, i.e. OAuth protocol, but the
authorization step is ACL-style, which means that the region needs to
authenticate the user in another separate/prior step, before the ACL
logic is run. That authentication would use OpenID - that is, the user's
request would send her OpenID information; the region would then ask the
OpenID provider if it has that user there.
After all that, the user's agent finally acquires the authorized token
to post something to that region.
(2) This second step is the most clean for the typical OAuth use case.
The region contacts the user's inventory server in order to request a
token for authorization to access the item. The inventory service
provider proceeds with the normal OAuth protocol, prompting the user for
explicit authorization. This is a redundant step from the User's point
of view, given that the user has, indeed, initiated the process. But
this redundant step is necessary, because the region might very well try
to grab an item from the user's inventory without the user having
started that. So the inventory service really needs to prompt the user
for authorization. The best we can do is to keep state and logic in the
client, so that when that prompt comes from the inventory server, it can
be replied to automatically.
*** Discussion ***
My impression is that the OAuth style of authorization will end up being
a lot more complicated to implement in the context of VWs than the
Capabilities style. This is sort of expected, in a way. If you look at
OAuth, it is designed with very clear roles in mind: there's (a)
consumers, (b) service providers and (c) users. The users are logged in
to a specific service (google, flickr, Linden Lab, etc), and OAuth helps
in giving an eager 3rd party (the consumer) a limited entry in the
interactions between the user and that service provider.
This works well for the Web.
However, in our case the lines between consumers and service providers
(and even users) are a lot more blurred. The regions are both consumers
of the users' assets and service providers -- they allow users to place
things there, as a service. Mutual authentication and mutual
authorization is required.
But, those of you who know OpenID+OAuth better than me, please point out
the mistakes I have done on my walking through the details.
Tommi Laukkanen wrote:
Hello
Everyone who is interested in authentication should check this out:
http://oauth.net/core/1.0/
Looks well established standard which does OpenId+Tokens and is
getting adopted in web industry. What do you think?
regards,
Tommi
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
