- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 7 Jul 2012 16:07:07 +0200
- To: bergi <bergi@axolotlfarm.org>
- Cc: WebID <public-webid@w3.org>, Read-Write-Web <public-rww@w3.org>
On 7 Jul 2012, at 15:06, bergi wrote:
> 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*
My table is a bit different. I make the secretary a role, and the role
is that of keeping secrets, and passing them on to another agent. The
secretary deals with messages coming in and out, can see some of them
and makes sure only the right ones get seen by the right agents.
delegation CORS
authenticated secretary User-agent
agent that forwards (code typically ( Browser )
secret message running on a server)
to another agent
client worked
for (receiving some other agent Javascript agent
secreet messages ( often human ) ( programmed )
indirectly ) (boss) ( salesperson,
external agent )
identifier of WebID all auth types
secretary (typically) incl WebID
identifier of WebID service
the agent (protocol:host:port)
receiving secrets
trust relation :secretary relation missing (out of band)
in profile to be added in RDF
>
> * 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.
Also I disagree with bergi that selecting a cert is how the trust relation
is selected. I don't think that is how CORS works, and I don't think it could
work that way. Because clearly browsers are not equipped to do this right:
imagine you are on some random site browsing a page, and the javascript
there wanted you to connect to your bank asking you to select your identity.
If you were to select it on that site, the browser would have to make clear
to you that you were logging in to the bank, not to the site you were looking
at - which is clearly way beyond the UI abilities of browser vendors .
>
>
> 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?
I tend to think of the CORS-Origin JS as the agent the secretary is working
for. Not sure what a name for that entity is. In this case it is a foreign
object, so this is more like a client calling the secretary by telephone,
or coming to the office. Here the secretary has to make sure she does not
give the intruder all the information it asks for.
>
> 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.
e-mail? Which agent + secretary?
>
> 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".
yes, those don't seem that easy to understand.
>
>
> 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.
Thanks, I think the parallels are becoming clearer and clearer, making
it easier to understand both.
>
>
> 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/
>>
>
Social Web Architect
http://bblfish.net/
Received on Saturday, 7 July 2012 14:07:42 UTC