Re: Authorization vs. Authentication (was Re: Accountability in AC4CSR)

Ian Hickson wrote:
> On Thu, 14 Feb 2008, John Panzer wrote:
>   
>>>> 1. Should OAuth invent a new header for authorization?  That is, 
>>>> should we not be using Authorization: for authorization?
>>>>         
>> Take the delegated server case first.  I, the user, talk to server B and tell
>> it that it's okay for server C to do certain operations on my behalf (read my
>> address book for example).  I believe I'm A in this case.  So later on, C can
>> talk to B on my (A's) behalf in order to retrieve my address book data.
>>     
>
> No, C never talks directly to B on A's behalf here. A talks to B on C's 
> behalf (using the terminology of the above paragraph).
>
>   
I'm sorry, I wasn't clear.  By 'delegated server' I meant that there's 
no CSR involved at all in this case, but I'm delegating some of the 
access rights that I (the user) have to C (in this case, a server).

Example:
A: Robert Scoble
B: Facebook
C: Plaxo

Scoble (A) tells Facebook (B) it's okay for Plaxo (C) to pull contact 
list data.  He then goes to sleep and shuts down his computer.  Plaxo 
(C) then contacts Facebook (B) and retrieves the data, acting on behalf 
of Scoble (A) but not impersonating him. 

The scenario you're talking about below is I think the second case, 
which I'm viewing as an extension of the first case but I think you're 
regarding as an entirely separate case.


> There are three IP addresses performing HTTP in this example, but all of 
> the HTTP transactions are initiated from the same IP address, that of the 
> user/client. That is, all of the requests are done by the user/client. The 
> only unusual, or new, transaction here is the one that the client sends to 
> the service provider, on the request of the Web page that the client 
> fetched from the original server.
>
> In every messages to the service provider, the user/client authenticates 
> to the service provider.
>
> The original server authentications to the service provider in the message 
> that the client sends to the service provider on behalf of the Web page of 
> the original server.
>
> The original server also includes authorisation information in the message 
> that the client sends to the service provider on behalf of the Web page of 
> the original server.
>
> All three of these things are sent in the request we primarily care about.
>
> The "Authorization" HTTP header and the cookie headers are used for the 
> first of these three, the user/client authentication. Thus they cannot be 
> used for either of the other two. This only leaves custom headers (or part 
> of the payload, though that is a bad practice).
>
>
> This is completely separate from the case where the original server and 
> the service provider communicate directly, with the message coming from 
> the original server's IP address and without there needing to be any 
> user/client involved at all. In this case, the "Authorization" HTTP header 
> and the cookie headers can only be used to authenticate the original 
> server, there is no authentication of the user/client involved (indeed, 
> there is no user/client involved period).
>
> This last case, I believe, is what Google AuthSub and Amazon's auth are 
> used for today.
>   
In these cases, Authorization is authenticating the server (Plaxo) _and_ 
authorizing its request based on prior input from the user.  When you 
say there's no user/client involved I get confused -- the 'original 
server' and 'client' are the same thing in this transaction (Plaxo to 
Facebook), unless you're saying that a server can never be an HTTP 
client, which confuses me even more.  The user is involved but not in 
real time -- indeed, it's key that they be involved since they're the 
ones authorizing the transaction.