Authorization Delegation & CORS

I am just working on CORS [1] and would like to point out some similarities I am noticing there with the work on Delegation we have been speaking of previously [2] and will help make the case for it.

Identification of the agent that one is acting on behalf of

In CORS (as in Delegation) there is an agent making a request on a resource that is passing through an
intermediate agent. In CORS the final agent receiving the information is some JavaScript being executed in the browser. The browser is hosting another agent - the javascript symbiont (that may be a parasite), which can communicate back with the home web site.  The browser is acting in the role of the secretary -  it is known as the User-Agent - and it wishes to act on behalf of some hosted agent (identified as the service it can communicate with directly: the origin web site).  When the browser makes an HTTP request on behalf of such a  javascript agent it needs to identify the agent it is working for. It does this with the "Origin" header

GET /resources/public-data/ HTTP/1.1  
Host: bar.other  
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip,deflate  
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
Connection: keep-alive  
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html  
Origin: http://foo.example    

Parallel 1: Origin as Acting-on-behalf-of

This Origin header is saying in effect: the request for this resource is destined to an agent that comes from http://foo.example/ and can communicate with that web site. In this the Origin header is somewhat similar to our Acting-on-behalf-of: header. The browser is using the authentication credentials of the user, but acting for another agent.  The parallel here is very strong. What are the differences?
  
  I am not sure if any service uses the information about the Origin to restrict access to information. Perhaps banks do this, because they don't trust that javascript from another site is not passing the information along to someone else.


Restrictions on who can see what

The CORS standard was initially called "Access Control for Cross-Site Requests" [4], and this was later changed to "Cross-Origin Resource Sharing", and a trace of the original thinking remains in the name of the HTTP headers. It is easy to see why this change was made, as CORS is not dealing with access control on the server side as we usually think of it, because the server serving the resource is not refusing to release information - well often this is the case - but it is rather adding information restricting how the resource can be used by XMLHttpRequest agents. The server  (let us call it http://foo.example ) does this by adding HTTP headers such as the following to the resources it releases:
 
   (a) Access-Control-Allow-Origin: *

   or 

   (b) Access-Control-Allow-Origin: http://hello-world.example


(a) is saying: everyone (specifically every javascript agent) can use this information, (b) is saying: this information should only be used by agents named as coming from hello-world.example. 

When none of the above are present then this means that XMLHttpRequests made by agents that do not come from the same domain as foo.example are not allowed to work with the data.

CORS will say that these headers are statements to relax how the information can be used, not to restrict it, because by default XMLHttpRequests made by javascript agents coming from a different server are not allowed to see data or javascript from any other server at all... But we are in the same ball park.

  parallel 2: access control by transmission of policy
 
   With our proposal  of adding an Acting-on-behalf-of: header there is also an assumed policy that needs to be made clear which is that the secretary is not meant to pass that information on to other agents other than the one it is acting on behalf of.  The difference here is that the agent that is following the policy is not the secretary/XMLHttpRequest agent but the browser. The browser acting on behalf of the user is receiving the information from a web site, with an access control restriction ( Access-Control-Allow-Origin: ) and is deciding whether or not it is authorised to pass it on to the potential javascript virus.


 This would be similar to a Web Server adding restrictions on who can do what with some information. In our Authorization Delegation scenario we could imagine that a server only releases information to Secretary Agents that it knows can reason with Access Control Ontologies and add a header to a request such as

   Access-Control-Restrictions: /acl#foaf

HTTP/1.1 200 OK  
Date: Mon, 01 Dec 2008 00:23:53 GMT  
Server: Apache/2.0.61   
Access-Control-Restrictions: /acl#foaf  
Keep-Alive: timeout=2, max=100  
Connection: Keep-Alive  
Transfer-Encoding: chunked  
Content-Type: application/xml  

where at the resource /acl a #foaf restriction would describe precisely who (what group of agents) can see the resource. To be close to the CORS example we would have
 
Access-Control-Only: http://bblfish.net/#hjs , http://joe.name/#me

But that could get to be quite long.


PUT/POST/DELETE

Until now we have only really considered in our Authorization Delegation sketches [3][2], what we are doing with respect to indempotent GET Requests. CORS also has done some work with respect to PUT/POST/DELETE [5] with Preflight Requests. Here the browser - acting again as a secretary - is checking before making a non-indempotent request whether those actions would be authorised if known to be coming from that other agent. 

I think one could apply the same procedure to our Authorization delegation which would need something like preflight-requests for the Acting-on-behalf-of header.  I could take the example from the Mozilla  web site
and adapt it to use the Acting-on-behalf-of header, instead of the Origin header.

OPTIONS /resources/post-here/ HTTP/1.1  
Host: bar.other  
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip,deflate  
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
Connection: keep-alive  
Acting-on-behalf-Of: http://bblfish.net/#hjs 
Access-Control-Request-Method: POST  
Access-Control-Request-Headers: X-PINGOTHER  
  
  
HTTP/1.1 200 OK  
Date: Mon, 01 Dec 2008 01:15:39 GMT  
Server: Apache/2.0.61 (Unix)  
Access-Control-Allow-Agent: http://bblfish.net/#hjs  
Access-Control-Allow-Methods: POST, GET, OPTIONS  
Access-Control-Allow-Headers: X-PINGOTHER  
Access-Control-Max-Age: 1728000  
Vary: Accept-Encoding  
Content-Encoding: gzip  
Content-Length: 0  
Keep-Alive: timeout=2, max=100  
Connection: Keep-Alive  
Content-Type: text/plain  
  
POST /resources/post-here/ HTTP/1.1  
Host: bar.other  
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip,deflate  
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
Connection: keep-alive  
X-PINGOTHER: pingpong  
Content-Type: text/xml; charset=UTF-8  
Referer: http://foo.example/examples/preflightInvocation.html  
Content-Length: 55  
Acting-on-behalf-Of: http://bblfish.net/#hjs 
Pragma: no-cache  
Cache-Control: no-cache  
  
<?xml version="1.0"?><person><name>Arun</name></person>  
  
[ NOTE: here WebID Authentication takes place ! ]
  
HTTP/1.1 200 OK  
Date: Mon, 01 Dec 2008 01:15:40 GMT  
Server: Apache/2.0.61 (Unix)  
Access-Control-Allow-Origin: http://foo.example  
Vary: Accept-Encoding  
Content-Encoding: gzip  
Content-Length: 235  
Keep-Alive: timeout=2, max=99  
Connection: Keep-Alive  
Content-Type: text/plain  


Having written this out it seems to me that the parallels are very strong here, and that 
we are dealing within the same logical domain. With WebID authentication we can be a lot
more precise as to what the agents are - we don't need to limit ourselves to a whole domain.


   Henry


[1] https://developer.mozilla.org/en/http_access_control#Origin
[2] http://www.w3.org/wiki/WebID/Delegation
[3] http://lists.w3.org/Archives/Public/public-webid/2012Jun/0012.html
[4] The older versions of the standard were called "Access Control for Cross-Site Requests"
    eg: http://www.w3.org/TR/2008/WD-access-control-20080912/
[5] https://developer.mozilla.org/en/http_access_control#Preflighted_requests


Social Web Architect
http://bblfish.net/