Subject: [OAUTH-WG] fyi: Cross-Origin Resource Sharing (CORS) [W3C]

From: =JeffH <[email-masked]>
Date: Mon, 21 Dec 2009 16:23:49 -0800

Hi,

At the oauth unofficial un-bar bof in Hiroshima (ietf-76 Nov-2009), I mentioned 
some work in the W3C WebApps WG called "Cross-Origin Resource Sharing (CORS)" 
which will essentially facilitate interactions between web sites on a user's 
behalf, and thus has similar user-visible functionality as OAuth.

At the W3C technical plenary (in Santa Clara) the week prior to IETF-76, during 
the webapps working group session(s), Maciej Stachowiak presented a slide deck 
background/overview of CORS (attached below). Of possible interest to this 
group, at the end of the slides (slide 37) he contrasts CORS to OAuth.

StPeter asked me to send a pointer to the slides to this list, this message is 
to satisfy that action item.

A way to think about the apparent duplication of effort between OAuth and CORS 
is that OAuth is a means to do sharing between one's websites today, with 
today's deployed browsers, while CORS is ostensibly a way to do it in the 
not-to-distant future, with the aid of the latest generation of browsers (and 
thus an at-first-small(er)-user-population, but one which will grow as new 
browser generations are released and deployed).

Also, CORS isn't (AFAICT) vying to become an HTTP authentication method.

That all said, being aware of the CORS is of possible interest to y'all.

HTH,

=JeffH
------

Cross-Origin Resource Sharing
Editor's Draft 5 October 2009
http://dev.w3.org/2006/waf/access-control/

CORS Background slides (Maciej Stachowiak)
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0468.html

[email-masked] Mail Archives
http://lists.w3.org/Archives/Public/public-webapps/

W3C Web Applications (WebApps) Working Group
http://www.w3.org/2008/webapps/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 21 Dec 2009 22:27:37 -0500

Hey Jeff,

Thanks for sending out this slide deck.  Here's a pointer to the  
latest draft spec:
<http://dev.w3.org/2006/waf/access-control/>

I reviewed this document a while back, and was actually surprised that  
it was being proposed as a competitor to OAuth.  Looking back at the  
document, I realized why: None of the authorization system that's laid  
out in the slide deck is actually in the document.  And I don't see a  
deliverable on the relevant working group's page that would indicate  
that the group is actually planning on developing something like this:
<http://www.w3.org/2008/webapps/charter/webapps-deliverables.html>
Obviously, to have an interoperable solution, a specification would be  
a good thing to have; in that regard, OAuth is ahead :)

Technically speaking, I think the proposals are actually mutually  
beneficial.  For example, the OAuth work flow could be used to  
establish an authorization for Site B to send cross-origin requests to  
Site A.   In more detail: Consider the Client/Server/RO interactions  
in two parts (I'll use the draft-hammer-oauth terminology), (1)  
Establishment of authorization, and (2) cross-origin data access.

In terms of establishing authorization, there's essentially no  
difference between OAuth and Maciej's proposal (Slide 18), except that  
OAuth fills in the details of (1) how the user knows what to tell the  
server to indicate "user picked Site B" and (2) how the user gets back  
to Site B from Site A.  Here's a cartoon of how the two overlay:

User        SiteA        SiteB
(RO)       (Client)     (Server)
  |            |            |
  |---------Request-------->|
  |<--------Redirect--------|
  |            |            |
  |--Auth-B--->|            |  ** Maciej Proposal
  |<-Redirect--|            |  ** (2nd round-trip)
  |            |            |
  |---------Request-------->|
  |<--------Response--------|
  |            |            |

OAuth offers more flexibility in the data access step than Maciej's  
proposal: In his proposal, the Server authenticates the request based  
on the identities of the user/RO (via the Cookie) and the Client (via  
the Origin); in OAuth, the Server uses a token that is bound to RO and  
Client identities, but can have additional semantics if the RO and  
Server agree on them.  So OAuth can provide more fine-grained  
permissions than CORS.  This property doesn't necessarily depend on  
the communications model -- in principle, an OAuth token could be  
passed in a cross-domain XHR as an authorization.

There is also a security benefit of server-to-server communications,  
since it can be used to support situations where the RO that  
establishes the authorization is different from the users that benefit  
from it.  For example, consider a payroll-processing company that gets  
a client comany's data and generates paychecks.  The client company is  
the RO that will set up the authorization, and the users that  
ultimately access the paychecks will not be authorized to access the  
raw financial data.  (You can imagine a similar example with an on- 
demand photo printing service that provides printing to my friends but  
not the full-resolution photos themselves.)  For these situations, the  
server-to-server model is nice because the two services (payroll and  
financial data, printing and photos) can authenticate each other  
directly and communicate privately, not exposing data to some  
intermediate user.

(Do you know why "no server-to-server" was a requirement here?  It  
seems like there are a lot of other practical/non-security benefits:  
Synchronizing without user involvement, faster service at client  
interaction time, lower client-facing bandwidth requirements (e.g.,  
for mobile users), etc.)

That's a pretty detailed response, but I hope it helps clarify some of  
the relationships between these ideas.  It would likely be a good idea  
to have more interaction between these two groups.

--Richard

On Dec 21, 2009, at 7:23 PM, =JeffH wrote:

> Hi,
>
> At the oauth unofficial un-bar bof in Hiroshima (ietf-76 Nov-2009),  
> I mentioned some work in the W3C WebApps WG called "Cross-Origin  
> Resource Sharing (CORS)" which will essentially facilitate  
> interactions between web sites on a user's behalf, and thus has  
> similar user-visible functionality as OAuth.
>
> At the W3C technical plenary (in Santa Clara) the week prior to  
> IETF-76, during the webapps working group session(s), Maciej  
> Stachowiak presented a slide deck background/overview of CORS  
> (attached below). Of possible interest to this group, at the end of  
> the slides (slide 37) he contrasts CORS to OAuth.
>
> StPeter asked me to send a pointer to the slides to this list, this  
> message is to satisfy that action item.
>
> A way to think about the apparent duplication of effort between  
> OAuth and CORS is that OAuth is a means to do sharing between one's  
> websites today, with today's deployed browsers, while CORS is  
> ostensibly a way to do it in the not-to-distant future, with the aid  
> of the latest generation of browsers (and thus an at-first-small(er)- 
> user-population, but one which will grow as new browser generations  
> are released and deployed).
>
> <Stachowiak-CORS- 
> Background 
> -2009-11-03.pdf>_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth