<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tommil,<br>
<br>
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 :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
*** Capabilities ***<br>
<br>
That POST will be guarded by two capabilities: <br>
<br>
(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.<br>
<br>
(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:<br>
(a) Instruct the inventory service to place a service handle at a
specific secret URL, for example:<br>
<a class="moz-txt-link-freetext" href="http://osgrid.org:8004/d65bdadd-781f-41f8-ae68-d1791e7e3af4/">http://osgrid.org:8004/d65bdadd-781f-41f8-ae68-d1791e7e3af4/</a><ItemUUID><br>
(b) Send that secret Cap URL to the region<br>
<br>
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.<br>
<br>
*** OAuth+OpenID ***<br>
<br>
The Rez scenario is as follows:<br>
<br>
(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.<br>
<br>
After all that, the user's agent finally acquires the authorized token
to post something to that region.<br>
<br>
(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.<br>
<br>
*** Discussion ***<br>
<br>
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.<br>
<br>
This works well for the Web.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Tommi Laukkanen wrote:
<blockquote
cite="mid:ad15b9430903010642p509738d6pdfd6888a2b244d6@mail.gmail.com"
type="cite">
<div>Hello</div>
<div> </div>
<div>Everyone who is interested in authentication should check this
out: </div>
<div> </div>
<div><a moz-do-not-send="true" href="http://oauth.net/core/1.0/">http://oauth.net/core/1.0/</a></div>
<div> </div>
<div>Looks well established standard which does OpenId+Tokens and is
getting adopted in web industry. What do you think?</div>
<div> </div>
<div>regards,</div>
<div>Tommi</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>