- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 14 Dec 2009 11:35:39 -0800
- To: Tyler Close <tyler.close@gmail.com>
- 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>
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 UTC