Re: Accountability in AC4CSR

Ian Hickson wrote:
> We need a terminology section that defines these terms so we can use them 
> in these conversations.
>
>    party A: original server
>    party B: third-party server, service provider
>    party U: user, client, user agent, browser
>    
> U visits A, which returns a page that then attempts to communicate with B.
>    
>
> On Wed, 13 Feb 2008, John Panzer wrote:
>   
>> What mechanism do you propose clients and servers implement use to 
>> authenticate users for CSR requests?
>>     
>
> HTTP Authentication and/or cookies, like they do now. If the user isn't 
> logged in, the third-party server would return an error to the client, and 
> the page from the original server would then redirect the user to the 
> third-party server (the service provider) to get them to log in.
>   
Except that's not what they do now.  If you look at the Flickr auth API 
for example:

http://www.flickr.com/services/api/auth.spec.html

you'll see that it does use redirects and cookies to establish a user 
session at their site.  But for the actual API calls, it relies on 
signed JSONP cross-domain requests, not cookies, to mitigate request 
forgery.  Anyone can do a <script src=...> to do a CSR, but without the 
appropriate proof that the end user has given permission to that 
specific party A via a conversation with party B, the request would just 
bounce off.   Note that party B is not identified by a URL, but rather 
by an API key.
 
Forcing CSR requests to rely only on cookies would prevent the use of 
additional security mechanisms (such as signed requests).

Well, actually it won't, it will just force those security mechanisms to 
continue to be stuffed into the URL parameters and/or custom headers.  
This has impacts on libraries, proxies, and cacheability.
>
>   
>> Because servers have to implement _something_.  Realistic mechanisms 
>> have to be resistant to distributed brute force attacks even without 
>> AC4CSR (thank you, Storm Worm). On a side note, I hope that servers 
>> opting in to CSR would never consider using username/password auth on 
>> each request.  Since it is possible to implement username/password auth 
>> in ways opaque to browsers ("&u=foo&pass=bar"), perhaps this is worth a 
>> note in the security section.
>>     
>
> The original server shouldn't ever have access to the _user's_ 
> credentials, certainly.
>   
Yes, it should.  If the user has had a conversation with party B and 
elected to share credentials with party A, which is what happens with 
Flickr auth today.  (Note that 'credentials' in this case are going to 
be an opaque and likely limited access token, _NOT_ a password of any kind.)

John