From: Story Henry [mailto:henry.story@bblfish.net]
Sent: Fri 9/21/2007 3:12 AM
To: Peter Williams
Cc: OpenID General
Subject: Re: [OpenID] cryptographics web of trust
On 15 Sep 2007, at 05:16, Peter Williams wrote:
> I played more with your foaf file, its wot, its implied recommendation
> to certain public keys.
>
> http://yorkporc.spaces.live.com/blog/cns!5061D4609325B60!167.entry
By the way, one thing to remember about writing blogs is that people may be arriving at your blog from anywhere. So they don’t have context. It is important therefore to decontextualise as far as possible what you are writing.
The query in the original reference used a java-script-like server-side scripting language, extended with a proprietary RDF query language. Its easy to learn, as its very similar to that underlying a million older Microsoft websites using Active Server Pages (ASP). A lot of programmers would relate to it (if indeed I contextualized, properly in an ezine-grade blogsite, seeking recommendations).
What matters most for now is the query design, not the language of its expression. Perhaps, continued discussion should aim to help OpenID community (a) focus on the appropriateness of its end-used identifier rules (https/http/no-fragments), (b) review how proposed wot:SigEvents documenting KeySign-ings may support OpenID Auth by adding assurance to the distribution of keying material, (c) allow optional FOAF discovery to add assurance to OpenID HTML Discovery of URIs, (d) let FOAF optionally be used as a basis of fulfilling AX queries, (e) let FOAF be a source of security policy controlling the release of attributes via AX, and (f) let FOAF/RDF document and/or define OpenID namespaces and protocol extensions.
In that vein, I can then note that FOAF cards are one of the earliest of SemWeb experiments – one that "captures its major design tenets". (I don’t want to "abuse" SemWeb, as some claim SOAP abuses the "intended role" of XML.) I note that FOAF vocabulary is used most of the examples in the SPARQL Query Recommendation. I note than foaf:openid is now an experimental term. I note that versions of FOAF’s own ontology have been signed using the WOT vocabulary. I note how your own FOAF card shows how one might similarly sign some byte form of a unique PersonalProfileDocument, bearing your openid assertions and a list of URI references to various friend assertions. I note that some of those friends have openids and publickeys. I note you have certified some of the openid/cardURI/pubkey bindings, essentially.
So lets perform another thought experiment – with just those elements.
Rather than experiment further with that javascript language, lets only use the SPARQL use case models shown in and around http://www.w3.org/TR/rdf-sparql-query/#specDataset .
Lets say henry’s new friends include:-
<http://example.org/foaf/aliceFoaf>
<http://example.org/foaf/bobFoaf>
Can we imagine that each graph indicated the n FROM NAMED elements in the query is one of the URLs henry’s card file points out – each pointing to the card of each of henry’s friends?
PREFIX foaf: http://xmlns.com/foaf/0.1/
SELECT ?src ?friendopenid ?friendpka
FROM NAMED http://example.org/foaf/aliceFoaf
FROM NAMED http://example.org/foaf/bobFoaf
WHERE
{
GRAPH ?src
{
?x wot:pubKeyAddress ?friendpka .
?x foaf:openid ?friendopenid
}
}
Can we now imagine that henry’s card also has a "foaf:queryme" term. Its value might the conventions of the SPARQL protocol binding for HTTP URL. The query above would presumably be encoded as the queryme object, citing a relative-URL to be resolved against the locally-scoped name #me
[ foaf:queryme #me?query=PREFIX+foaf%3a+%3chttp%3a%2f%2fxmlns.com%2ffoaf%2f0.1%2f%3e%0d%0aSELECT+%3fsrc+%3ffriendopenid+%3ffriendpka%0d%0aFROM+NAMED+%3chttp%3a%2f%2fexample.org%2ffoaf%2faliceFoaf%3e%0d%0aFROM+NAMED+%3chttp%3a%2f%2fexample.org%2ffoaf%2fbobFoaf%3e%0d%0aWHERE%0d%0a++%7b%0d%0a++++GRAPH+%3fsrc%0d%0a++++%7b+%3fx+wot%3apubKeyAddress+%3ffriendpka+.%0d%0a++++++%3fx+foaf%3aopenid+%3ffriendopenid%0d%0a++++%7d%0d%0a++%7d . ]
Can we imagine that an address book tool used to maintain Henry’s friend list also rewrites the foaf:queryme?
Can we imagine the query might reference an inference rulebase, that allows the query to prefer to pickup henry’s copy/endorsement of Alice’s pubkey from henry’s website (rather rather than the copy from Alice’s own website?)
Is there an existing "standard" SPARQL query that takes a PersonalProfileDocument card, and reduces the list of knows relations to a set of named graphs in a "template" SPARQL query – one that gets specialized by some kind of internal GRAPH "join" to then lookup the friends’ current openids, or pubkeys, or other "X" terms that a particular FOAF applications focuses on?
Just a few ideas, to play with.
Peter's ruminations 