Re: Accountability in AC4CSR

Ian Hickson wrote:
> On Wed, 13 Feb 2008, John Panzer wrote:
>   
>>> 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.
>>     
>
> You asked how the user was authenticated, and that is, even in this 
> example, via the server itself handing out credentials to the user (in 
> the form of a cookie).
>
> Now, the question of how the original server obtains authorisation from 
> the service provider is a different one. However, again, the mechanism 
> described above and used today would still work with Access-Control.
>
>
>   
>> 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.
>>     
>
> Could you give a concrete example of a case that is negatively impacted 
> here? As far as I can tell, the impact to which you refer is exactly what 
> we want.
>
>
>   
>>>> 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.)
>>     
>
> What the service provider gives the original server in the Flickr case is 
> not the user's credentials (or indeed any kind of authentication), but an 
> authorization token to confirm that the user has permitted the site to do 
> what it wants to do.
>
>   
Above, I got a bit tangled up (originally I was making a point about 
re-use of existing APIs that might naively accept usernames and 
passwords, misinterpreted Ian's response, and started talking about 
authorization tokens.)  Sorry, let me start over.

I'm really concerned with authorization, not authentication.   An API 
needs to do an authorization check on a CSR request, not an 
authentication check.  For CSR especially, just doing an authn check 
doesn't give you valid evidence of authorization.

Some of today's APIs like Flickr put authorization evidence into URL 
query parameters for CSR.  It's mildly bad to do this because such 
things are more likely to get logged and sniffed than headers, and you 
can't separate the resource URL from the authorization proof being 
presented to use it, which would be useful in caching.

The OAuth spec uses

    Authorization: OAuth ...

by preference for these reasons, where the ... represents an 
authorization proof provided by the party A script. It looks like this 
is disallowed by the AC4CSR specification.  It says that "authentication 
credentials" should not be permitted to be set by [the party A script].  
Since HTTP doesn't separate authorization and authentication, in 
practice this seems to mean that Authorization: isn't settable.  Per the 
discussion above, we're really talking about authorization, not 
authentication.  So, some random thoughts...

1. Should OAuth invent a new header for authorization?  That is, should 
we not be using Authorization: for authorization?
2. Should the spec wording ban only authentication uses of the 
Authorization header (that is, Basic/Digest) and allow authorization 
uses of Authorization (e.g., OAuth)?

John