[foaf-dev] how to declare that foaf+ssl should be used?

Peter Williams pwilliams at rapattoni.com
Sat Jul 18 19:56:24 CEST 2009

> I think what I'm looking for in the FOAF world is something like:
> A using HTTP accept headers:  application/rdf+xml;foaf+ssl=true text/
> powder+xml;foaf+ssl=true

You can ask for application/rdf+xml representations if that helps. The
accept headers are there for requesting representation formats. But
SSL is not a format, rather an access mechanism.

> B instruct henry's foaf agent, using http://henry.com/foaf.rdf#me?
> _DR_r=application/rdf+xml;foaf+ssl=true
> C instruct henry's foaf agent for discovery using http://henry.com/foaf.rdf#selector
> ?_DR_r=text/powder+xml;foaf+ssl=true

I think we need to distinguish between SSL protocol (layer 4), https protocol (layer 7), https urlrefs (in semweb graphs), and foaf+ssl (wot-constrained interactions between foaf agents).

Irrespective of application of foaf+ssl for facebook's access control, foaf+ssl is fundamentally a method for (i) discovering, and (ii) walking the friends graph and the wot between any resource, and any client's webid.

By extension, it will hopefully one day discover any (powder) description of any resource, where foaf acts as a framework for the security and trust issues of that act of discovery.

Now, I've used facebook little, except to test when my openid got me access to one of its website. But, what I need to do as client is express a *trust* requirement. FACEBOOK SERVER! don't bother to perform my request to recover henry at facebook's<mailto:henry at facebook's> foaf file UNLESS you apply the foaf+ssl method _whenever_ YOU **or** OTHERS follow urlrefs - when executing your side of the foaf+ssl method.

You clearly laid in a sequence diagram the interaction between backroom servers and other foaf files, when performing the server-side of foaf+ssl. So, now let's secure the backroom channels over which the foaf files are retrieved...so that I, as client on the foreground channel, can have "assurance" that when facebook deliver a foaf file, that delivery channel provides satisfies my rule ; and is thus "trustworthy".

What I'm doing -- as intended consumer of foaf stream  -- is levying a trust requirement. Before I will use the resulting foaf stream, yo must Facebook provide assurance about the "provenance" of the objects in the foaf stream. At this class of assurance, its enough to satisfy your obligation to me by asserting that you used https or foaf+ssl on ALL communication channels induced by my request.

here is the obvious list of channels:-

(1) foaf+ssl: between my http client and the facebook-sourced foaf resource

(2) server-side https: when the foaf agent for facebook talks to its sparql server,

(3) foaf+ssl: when that sparql server follows any urlrefs to any external foaf file, as it performs the requested query

(4) foaf+ssl: when facebook's foaf agent recovers foaf files from ANY urlrefs in the sparql-server's graph-response ... while walking the friend's network and wot back to the client's webid

Now I recognize that accept headers with ";foaf+ssl=true" appendages is not very "semweb".  We cannot expect in the open semweb each foaf agent, or the sparql server following external references in a query, to be adding that accept header to its downstream http requests when walking around the semweb - where deferencing any one urlref can spawn additional requests to unseen third parties. We *can* expect just that - in the world of XRI "trusted resolution" used in openid: but this is the world of semweb and logic vs XML data processing.

So! Somehow! ...in a manner consistent with semweb's logic framework ... as "originating client" I have to be able to express to facebook's foaf agent that (a) it MUST apply foaf-ssl downstream... when it retrieves any other foaf file in the course of discovering and walking the wot; and (b) any and all foaf+ssl agents must apply https when communicating with a sparql server.

More information about the foaf-dev mailing list