On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:
On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth <[email protected]>
wrote:
On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees <[email protected]
> 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
