W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 14 Dec 2009 11:35:39 -0800
Cc: Adam Barth <w3c@adambarth.com>, Jonathan Rees <jar@creativecommons.org>, "Mark S. Miller" <erights@google.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
Message-id: <62784B15-F987-41B0-BE2B-4DE3FBFA42C9@apple.com>
To: Tyler Close <tyler.close@gmail.com>

On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:

> On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth <w3c@adambarth.com>  
> wrote:
>> On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees <jar@creativecommons.org 
>> > wrote:
>>> The only complaint I know of regarding UM is that it is so  
>>> complicated
>>> to use in practice that it will not be as enabling as CORS
>>
>> Actually, Tyler's UM protocol requires the user to confirm message 5
>> to prevent a CSRF attack.  Maciej's CORS version of the protocol
>> requires no such user confirmation.  I think it's safe to say that
>> asking the user to confirm security-critical operations is not a good
>> approach.
>
> For Ian Hickson's challenge problem, I came up with a design that does
> not require any confirmation, or any other user interaction. See:
>
> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 
> 1232.html
>
> That same design can be used to solve Maciej's challenge problem.

I see three ways it wouldn't satisfy the requirements given for my  
CORS example:

1) Fails "AJAX UI" requirement in the grant phase, since a form post  
is required.

2) The permission grant is intiated and entirely drive by Site B (the  
service consumer). Thus Site A (the service provider in this case) has  
no way to know that the request to grant access is a genuine grant  
from the user.

3) When Site A receives the request from Site B, there is no  
indication of what site initiated the communication (unless the  
request from B is expected to come with an Origin header). How does it  
even know it's supposed to redirect to B? Is site A expecting that  
it's only going to get service requests from B? That would amount to a  
prior bilateral arrangement.

I also note that the protocol you describe there uses cookies (and  
possibly origins, if point 3 is addressed) to bootstrap a shared- 
secret based scheme. As I've mentioned before, CORS would be a useful  
tool for that type of technique. It can allow such bootstrapping  
without having to jump through hoops with form posts, without  
disrupting the user's interaction with a full page load, and without  
necessarily having to put secrets in the URL (since the URL part of  
the request is by far the most likely to leak to the outside world  
inadvertantly.

Regards,
Maciej
Received on Monday, 14 December 2009 19:36:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT