- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 16 Feb 2008 08:56:43 +0000 (UTC)
- To: John Panzer <jpanzer@acm.org>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On Fri, 15 Feb 2008, John Panzer wrote: > > This would only really be useful though if Authorization: is allowed to > convey authorization in addition to authentication. Since is used for > authorization in addition to authentication today in practice (AuthSub, > Amazon AWS, OAuth), I'm worried there's a mismatch between what's done > in the field and what the specification calls for, which is resulting in > conflicts. Ok, let's look at this from the other perspective. Assume that there is a service provider, let's say Calendar, that the user is authenticated with -- either through cookies or through HTTP auth, or both. Now assume that another site from some independent third party, let's say example.com, wants to talk to this application, using a cross-site XMLHttpRequest call from its Web page, running in the browser of the user. It has to also authenticate, and it has to pass an authorisation token that the user has granted it. So the request is coming from the user's browser, which knows the user's authentication details (cookie and/or HTTP auth information), and is being driven by script that comes from example.com, which is not allowed access to the user's Calendar credentials. There are three pieces of information to send in the request: * User credentials (which the UA received as cookies and/or HTTP auth) * example.com credentials * example.com's authorisation to use the Calendar for the user Which of these three pieces of information, only two of which are available to the third party site, should be included in the requests's cookies and/or HTTP authentication headers? How should the other information be sent? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 16 February 2008 08:56:56 UTC