[foaf-protocols] push webid, vs pull

peter williams home_pw at msn.com
Sat Mar 12 19:29:36 CET 2011


As I build actual stuff, wanting to use your SPARQL server entirely for
anything to do with RDF processes (consuming it as a service), wondering
about engineering issues.

 

Wondering if we might take a leaf out of the SAML book, and push data
(rather than only pull it).

 

For example, could the client talk to your SPARQL server, must as does the
validating agent, receiving an "artifact refnum" to be given to the actual
verifier. The idea is that it gives the SPARQL server a few milliseconds
advance warning, before the verified comes a calling.

 

Then the verifier comes to pick up the same result, citing the artifact
number. With the response (which includes has to include the pubkeys now,
the verifier confirms that the pubkey is present in the asserted response.

 

What this would allow is the webid in the client cert to be a complete
sparql protocol URL, of form

 

http:/// <http://> #me?sparql=..... where the server only has to choose
which sparql server to hit, making http://
<http://%3cmychoice%3e/#me?sparql> <mychoice>/#me?sparql=. This is of course
a classical, serverless URI pattern.

 

This would seem to reduce further the work needed to be done by webapp
plugins doing webid acceptance, since they don't need to form up the query,
then. It comes built into the self-signed client cer, and can stanradize the
form of the output resultset (for such validation queries).

 

Of course this introduces risks (due to bad/deceptive query formation, by an
untrusted client). But those are addressed by the push model, in which the
"trusted" sparql server qualifies the query, to ensure - in a webid security
context - it only mints the artifact-refnum when its willing to condone use
of the query's results for an act of webid validation.

 

This works despite the msft patent, since the facts about location of the dc
= authentication server are all within the cert, or deduced from the cert
locally.  They are not implied by facts from the wire (other than the cert).

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110312/ed6efe66/attachment.htm 


More information about the foaf-protocols mailing list