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.
>
>
>   
>> 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.
>   
To try to be more concise:

Cookies can (somewhat) prove "I am user X".
They can't prove "I authorized this request."
I'm concerned about the latter.

Don't know if that helps... :)