[OpenID] cryptographics web of trust

[Peter Williams]

Henry:

I've now learned basic N3. Programming it helped. Reading an RDF book did not.

RDF:Type seems to play the role of ObjectClass in LDAP, in this context.

A RDF PersonalProfileDocument  seems to be a "Directory application" - a set of objectclasses tuned up for a use-case other than ....the common world of white-, yellow-, green-pages telephone books.

When you signed your FOAF file, I'm guessing you chose a  particular file-signing vs graph-signing method.

I'm guessing you are not only signing your public key (so other have a basis for relying on those crypto parameters) but you are including in the hash computation your set of cross-references to those people whose public keys you are stating to the world: I relied on these public key bindings, already. 

If you include the bytes of each of their public key files in your signature hash ...as well as your own PGP file's bytes ...you'll have something VERY similar to the first half of the reliance method I wrote up in my (discarded) dissertation. 

You can spec and signal that RDF graph-signing method in RDF metadata or DAML, I've no doubt :-) In X.800, there is a formal treatment of many different security-services/signing-semantics. In ISO 8613 there was a signing method for signing parts of (several) compound documents - which will be highly relevant to a signing/verifying a graph formed from several FOAF files.

-----------

For Opened Auth security purposes, the graph constructed by the OP-Server could be 

(a) a merger of the wot statements from the claimant user's file and the OP-server's own file

(b) a selection/search for the paths through all the wot statements to form a (partial) reliance graph, targeting the OP-Consumer's "Trust Point" URI. 

Ideally, the OP-server would induce from this computation both a "forward wot path" and "reverse wot path". Each end doing a mutually-suspicious OpenID Auth run can then first rely on each other's DH key, once they done signature verification of the underlying FOAF/PGP file(s) byte streams. 

Both paths should be computed by the OP-server. The OP-Server should not commit its checkid response to the "association," until it has formulated a reverse chain to the trust point signaled in the checkid request. An OpenID check resp extension element will probably need to send the forward path, where the RDF is signed by the OP-Server on the fly.  This avoids a low-assurance OP-consumer having to have all the same chain inducing apparatus.

Alternatively, check resp message extensions could signal a transient URL, so the Consumer can come and pick up the on-the-fly-signed RDF/N3 or on-the-fly-signed RDF/XML file.

Note, I totally removed all SAML and SOAPish patter. This is a pure FOAF-extension to OpenID Auth.