[foaf-protocols] push webid, vs pull
kidehen at openlinksw.com
Sun Mar 13 21:09:03 CET 2011
On 3/12/11 1:29 PM, peter williams wrote:
> 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
Many ways to push. One example is PubSubHubbub, another could be via
What we need to do is setup usecase demos. There was a SWAT0 effort that
sorta failed on the WebID side cos we were the sole WebID and
SemanticPingback entrant. All others worked with Salmon Slap and Magic
As you can see this realm is immensely flexible, but very short on
interop usecases :-(
> http:/// <http://>#me?sparql=..... where the server only has to choose
> which sparql server to hit, making http://<mychoice>/#me?sparql
> <http://%3cmychoice%3e/#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
> 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).
boils down to an interop and usecase activity. I don't see any technical
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols