Re: Authorization Delegation & CORS

I had a little Skype discussion with Henry about that topic. Here a
short summary:

Both, delegation and CORS, give you an agent and a secretary which can
be used for access control. But there are some differences till you get
a verified agent and secretary:

			delegation			CORS

authenticated
object			secretary			agent

secretary
object type		URI				host

trust relation		property in profile		selecting
							a cert*

* Works only if the browser opens a new connection for every host that
uses CORS and asks every time for a cert. We have to check how the
browser behaves.


For further discussions we should agree to a vocabulary for the
following stuff:

In the delegation discussion the secretary term is already established.
Can we also call CORS-Origin secretary?

How do we call the combination of agent + secretary? I will call it this
email source, which doesn't exactly fit from my point of view.

This allows us to talk about dimension for the access control stuff. A
source with the dimension agent+secretary can access a target with the
dimension resource (and maybe a definition for triples). Also I'm not
very happy about "target".


Some of the CORS discussion was based on this diagram [1]. It's a very
early version without numbers, good descriptions and terms. But maybe
somebody wants to use/improve it.


bergi


[1] http://www.w3.org/community/rww/wiki/Pingback#Client-Side_Pingback

Am 04.07.2012 16:08, schrieb Henry Story:
> 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
> 
>  1. GET /resources/public-data/ HTTP/1.1  
>  2. Host: bar.other  
>  3. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
>  4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
>  5. Accept-Language: en-us,en;q=0.5  
>  6. Accept-Encoding: gzip ,deflate  
>  7. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
>  8. Connection: keep-alive  
>  9. Referer: http://foo.example/examples/access-control/simpleXSInvocation.html  
> 10. *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
> 
>  1. HTTP/1.1 200 OK  
>  2. Date: Mon, 01 Dec 2008 00:23:53 GMT  
>  3. Server: Apache/2.0.61   
>  4. Access-Control-Restrictions: /acl#foaf  
>  5. Keep-Alive: timeout=2, max=100  
>  6. Connection: Keep-Alive  
>  7. Transfer-Encoding: chunked  
>  8. 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
>  
> 
>  1. 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.
> 
>  1. OPTIONS /resources/post-here/ HTTP/1.1  
>  2. Host: bar.other  
>  3. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
>  4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
>  5. Accept-Language: en-us,en;q=0.5  
>  6. Accept-Encoding: gzip ,deflate  
>  7. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
>  8. Connection: keep-alive  
>  9. *Acting-on-behalf-Of: http://bblfish.net/#hjs*  
> 10. Access-Control-Request-Method: POST  
> 11. Access-Control-Request-Headers: X-PINGOTHER  
> 12.   
> 13.   
> 14. HTTP/1.1 200 OK  
> 15. Date: Mon, 01 Dec 2008 01:15:39 GMT  
> 16. Server: Apache/2.0.61 (Unix)  
> 17. *Access-Control-Allow-Agent:  **http://bblfish.net/#hjs*   
> 18. Access-Control-Allow-Methods: POST, GET, OPTIONS  
> 19. Access-Control-Allow-Headers: X-PINGOTHER  
> 20. Access-Control-Max-Age: 1728000  
> 21. Vary: Accept-Encoding  
> 22. Content-Encoding: gzip   
> 23. Content-Length: 0  
> 24. Keep-Alive: timeout=2, max=100  
> 25. Connection: Keep-Alive  
> 26. Content-Type: text/plain  
> 27.   
> 28. POST /resources/post-here/ HTTP/1.1  
> 29. Host: bar.other  
> 30. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre  
> 31. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
> 32. Accept-Language: en-us,en;q=0.5  
> 33. Accept-Encoding: gzip,deflate  
> 34. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
> 35. Connection: keep-alive  
> 36. X-PINGOTHER: pingpong  
> 37. Content-Type: text/xml; charset=UTF-8  
> 38. Referer: http://foo.example/examples/preflightInvocation.html  
> 39. Content-Length: 55  
> 40. *Acting-on-behalf-Of: http://bblfish.net/#hjs*  
> 41. Pragma: no-cache  
> 42. Cache-Control: no-cache  
> 43.   
> 44. <?xml version="1.0"?><person><name>Arun</name></person>  
> 45.   
> 46. *[ NOTE: here WebID Authentication takes place ! ]*
> 47.   
> 48. HTTP/1.1 200 OK  
> 49. Date: Mon, 01 Dec 2008 01:15:40 GMT  
> 50. Server: Apache/2.0.61 (Unix)  
> 51. Access-Control-Allow-Origin: http://foo.example  
> 52. Vary: Accept-Encoding  
> 53. Content-Encoding: gzip   
> 54. Content-Length: 235  
> 55. Keep-Alive: timeout=2, max=99  
> 56. Connection: Keep-Alive  
> 57. 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/
>

Received on Saturday, 7 July 2012 13:06:40 UTC