Re: Linked Data Profile and CORS

On 7/18/12 4:08 PM, Nathan wrote:
> Henry Story wrote:
>> Hi,
>>
>>   [I sent the following mail to the Linked Data Profile WG, to see if 
>> it is something they are able to add to their topics of interest 
>> (that may take some time, and so should not stop us looking into it 
>> too).]
>>
>>   I think as mentioned previously LDP does require some form of 
>> authentication, as it allows non-idempotent methods such as POST, PUT 
>> & DELETE . This means that there will be some interesting things to 
>> think about relating to CORS [1]
>>
>>   One application of an LDP server would be to have a javascript 
>> client [2] be able to crawl RDF linked data in order to build up a 
>> user interface. I have a really simple example that kind-of™ works.
>>
>> http://bblfish.github.com/rdflib.js/example/people/social_book.html
>>
>>  The page contains no data just a reference to my foaf profile, which 
>> is how it fills in the user info and the first column of the Social 
>> Book. If you click on some users, such as "Joe Presbrey" the 
>> javascript will make an XHR request to his WebID Profile 
>> http://presbrey.mit.edu/foaf, which since it contains the right 
>> headers especially the "Access-Control-Allow-Origin: *"
>>
>> $ curl -I http://presbrey.mit.edu/foaf
>>   HTTP/1.1 200 OK
>>   Date: Tue, 17 Jul 2012 08:35:03 GMT
>>   Server: Apache
>>   Access-Control-Allow-Origin: *
>>   Last-Modified: Tue, 20 Dec 2011 01:02:36 GMT
>>   ETag: "43c4058c-1437-4b47b9f740300"
>>   Accept-Ranges: bytes
>>   Content-Length: 5175
>>   Content-Type: application/rdf+xml
>>
>> the browser is authorised to pass that profile on for use by the 
>> javascript that will display the info. Most linked data sites do not 
>> put such headers up, and so make it necessary then to develop CORS 
>> proxies (which that social_book application also uses).
>>  It may be worth exploring this side of things a bit. Perhaps adding 
>> to the LDP Use Cases [3] a javascript based linked data browser could 
>> bring these issues up in the LDP Working Group.
>> Some questions that come up from my little experience in this area are:
>>  - should all public RDF resources always return 
>> Access-Control-Allow-Origin: * to all public resources?
>>    ( I would tend to think so, because a simple proxy will always 
>> give access to that resource anyway )
>>  - How does a server know which Origin JS agents to trust for a 
>> particular user? Since we are are working in a linked data 
>> environment that at its best spans many organisations how is the IBM 
>> linked data provider to know that it should trust my bblfish.net JS 
>> Agent to get a particular resource for me?
>>    (my suggestions if I add :me cert:trustOrigin 
>> <https://bblfish.net> to my WebID profile? )
>>  - what types of improvements to the identity of JS applications 
>> might in the long term help develop better apps? ( perhaps having 
>> signed JS apps? )
>
> do see:
> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0884.html
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0614.html
>
>

We need signed JS from trusted sources.

We need user agents and servers to be able to recognize one another via 
WebIDs en route to appropriate interaction context e.g. access controls 
driven by relationship semantics discerned from resources and response 
header based metadata that manifest during RESTful interaction cycles etc..

Methinks: we get this done here rather that debating with others. The 
more we show, the more progress we make en route to critical Web usage 
tweaks.

Just Do It! Remains the best way on the Web, as long as "Doing It" 
doesn't compromise core architecture :-)

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen