[foaf-protocols] linking and authenticating wot-based certs; SSl role reversal

peter williams home_pw at msn.com
Wed Dec 29 02:28:34 CET 2010

Lets say that popular SSL implementations were "completed", allowing the
party in the current https server role to "reverse roles". 
Given that, assume now, that you are the https server with a protected
resource. That is, you are the relying party initiating an https connection
back to a webserver distributing the client's foaf card. You are simply
acting per FOAF+SSL, de-referencing the webid in an SSL client cert.
But on parsing the foaf card, you note that it relates the user to other
resources on the same host. These might refer to a resource such as the
following. In that resource, basically someone is representing that she
verified some other foaf card (and its public key). It's an unsigned
certificate.that is.

<p about="http://perso.hirlimann.net/~ludo/foaf.rdf#me" typeof="foaf:Person"

To the best of my knowledge, <a rel="foaf:homepage foaf:account"
href="http://perso.hirlimann.net/~ludo/">Ludovic Hirlimann</a>&#8216;s PGP
fingerprint is <span property="wot:fingerprint">6EFBD26FC7A212B2E093
B9E868F358F6C139647C</span>. You might also be interested in his <a
rel="foaf:account" href="http://www.flickr.com/photos/lhirlimann/">photos on
flickr</a>, or his workplace, <a rel="foaf:workplaceHomepage"
href="http://www.mozillamessaging.com/">Mozilla Messaging</a>. The GPG key
details were checked over a Skype video call with me, Ludo and <span
rel="foaf:knows"><a rel="foaf:account"
href="http://www.google.com/profiles/Kaare.A.Larsen">Kaare A.
Larsen</a></span>.<br />

<a rel="foaf:depiction"
0.png" alt="" title="ludo-verified" width="299" height="300"
class="alignnone size-medium wp-image-544" /></a>



One thing the w3c incubator for the webid protocol might do is say: why
cannot the party holding the initiator token/role invite its peer to take
over that role, perform a SSL handshake in that capacity, and once again
perform client auth (using a resumed SSL handshake). 


This time around, the client's SSL finished messages securely refers to the
file containing the above cert/assertion, using a padding mechanism that
wraps the finished message with OAEP, where the OAEP generators are suitably
parameterized using the _hash_ of this file's transfer syntax/encoding.


Much like classical FOAF_+SSL has the SSL channel authenticate the user
controlling the foaf card, this minor extension generally allows many
assertions in such as that WOT-notated graph to get the same kind of benefit
- from a "semweb-updated SSL".

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

More information about the foaf-protocols mailing list