- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 14 Feb 2008 19:09:59 +0000 (UTC)
- To: John Panzer <jpanzer@acm.org>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
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). 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 14 February 2008 19:10:10 UTC