[foaf-dev] FOAF ping pong, with signed endorsements

Peter Williams pwilliams at rapattoni.com
Mon May 31 21:17:26 CEST 2010


Let's get back to ping and wot-powered endorsements. Both are supposed to be examplars of the rdf+semantic way of doing things.

a. Browser plugin from some vendor spies on user's interactions with websites. It does this at the impulse of the vendor or distributor, or because governments regulating the internet just want the generalized retention of evidence (for law enforcement regime X). More positively, the web is addressing the need to supply evidence of "intent" - a requirement in the legal world of digital signatures.

B As users link resources, the observer follows the observed citation to auto-discover the linked resource's ping endpoint. Autodisdcovery means parsing the foaf card de-deferenced by following the link looking for a characteristic relation announcing a service endpoint of the right type. No XRDS is required!

C Unlike former xml-rpc pingbacks, the form posted by observer to the ping endpoint induces the agent to mint a rdf resource, a (named?)graph which gets a URI ...per web architecture. This URI is the reference for further PUTting and DELeting of the ping item. By default, the managed collection of it and others like it would be copyright by its maker.

D Events then fire in the target's world, which might lead the target to add adding inverse following statements, etc.

TWO things are really interesting about this flow:-

1. Unless foaf+ssl is authenticating the observer to the ping server, the URI to the ping-item has an anonymous "issuer" (even though copyright and ownsership semantics are clear, by default). If foaf+ssl is in effect and the ping server is willing to rely on the webid, then the issuer can be noted to be the foaf+ssl authenticated webid (along with the evidence that led to reliance on foaf+ssl signals). My comment is then that this "issuer" notion needs modeling explicitly. It's what I was trying to express when talking about the "record" of minting the ping-item (vs the ping-item itself). Only once a ping-item with URI reference has the semantics of being a "record" ...is it worth signing/endorsing (at which point American lawyers know it as an "authenticated record"). Records (and endorsed/authenticated written records furthermore) "persist" in the "evidentiary space" even though the issuer/owner may have performed a DELete operation in the rdf/semweb space.

2. The semantic ping back is more interesting than its web2.0 progenitor because it can be superimposing at a _third party_ the linkmaps for  resources of arbitrary types. One notes two examples of specialized linkmaps: friend following, and adding a source's image resource to the target's bookmark lists. This generality is important, as one could be adding the source's referenced public key (rather than an photo ) to the target's wot (or at least presenting the invite to do so). For image, read publickey; for bookmark, read personal-wot.

What I particularly like is the orientation in the presentation that showed a _thirdparty_ ping agent working for the target (in the absence of the target being able to run their own agent processes). This separation would allow the true target to sign the ping-item once notice was received (and add the now signed-value to the wot array in the target's foaf card) - much as the given examples have the user add the inverse following relation in response to an email event. Being a crypto-based signing event, this is something only the target can do (and the third-party operating the ping server cannot). As the signed ping-item satisfies the form now of being an authenticated record (taking the form of a wot-endorsed rdf graph, technically), the act of signing and publishing the endorsed ping-item brings the evidentiary semantics into play (as desired).

What I LIKE about the wot endorsement technology is that it uses rdf - vs being a mere serialization of a signed blog like in the xml-dsig world. The crypto/signature statements can be in one location (users foaf card or filesystem), the ping-item payload in another (third party ping servers repository?), and the notion of the subject "User" maybe managed by fourth agent (exploiting wot's carefully modeling of user relations). This all feels like the "framework" has the flexibility to support huge trust infrastructures, allowing folks to explore their competing needs in each sub-community.

What is interesting to me is that the overall scheme is essentially the same as what I proposed in my (really crap) phd dissertation, back in 2003. Rather than use pingback techniques and foaf+ssl-centered notions of reliance, I happened to use a 3-phase protocol conformed of signed X.500 modify operations, resulting in each side in the negotiation protocol creating/signing backpointing X.509 cross-certificates (read "signed ping-items"). But the result was the same: user-centric trust overlays, of enormous scale potential.







More information about the foaf-dev mailing list