[foaf-protocols] doing webid validation with pgp wot

peter williams home_pw at msn.com
Sun Mar 6 05:43:50 CET 2011

We know the foaf ontology itself was/is signed with pgp, leaving .sig files
in its wake (and wot-described references to those resources in the rdf


Let's assume the graph is signed (using pgp) using the private key used also
for SSL client authn. That is, one private key can drive both pgp and SSL
client auth: pgp cert notation for pgp authn, x.509 certs notation for
client authn (for legacy reasons, since few web browsers/servers can handle
the pgp notation ).


On presenting a client cert to a server using http's client authn procedure
(with RSA signature ciphersuite), surely a validation agent need merely go
find, on some URI on the same stem as the URI from the cert SAN URI, a
stored .sig file/resource, which _verifies_ using the public key in the


Surely, between the stem rule and the pkc rule, this is stronger than merely
finding the same public key in the foaf card.


Has two nice properties: signs the foaf card's document representation AND
now verifies webid protocol.


It's still using the same enforcement argument as with cert/rsa ontology:
that the subject uniquely has write access to the file system storing the
.sig resources (vs storing the foaf card itself).


Assuming a foaf card points to many .sig files, one can look to the wot tags
in the various graphs and statements within the card to match them to the
cert - to quickly identify the right .sig(s). As I remember, there was a
wot:identity "tag" that could be used for this, and it was typeless (so
might be the cert fingerprint). It has specific functional relationships,
that were important and generalized, as I recall.


Now, Im sitting here convincing myself of my own argument's validity; which
is never a good thing to do. What's wrong with the reasoning.?










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

More information about the foaf-protocols mailing list