[foaf-dev] relation from foaf to pubkey -- was: strawpoll: migrate from foaf:holdsAccount to foaf:account?

Melvin Carvalho melvincarvalho at gmail.com
Tue Aug 25 17:04:12 CEST 2009

On Tue, Aug 25, 2009 at 1:38 PM, Story Henry<henry.story at bblfish.net> wrote:
> [[Just as a note: the holdsAccount discussion should really be limited to
> the foaf-dev list. It is not relevant to the foaf-protocols discussion. ]]
> The discussion below on public keys on the other hand is directly relevant
> to foaf-protocols.
> On 23 Aug 2009, at 21:08, Melvin Carvalho wrote:
>> On Sat, Aug 22, 2009 at 8:40 PM, Dan Brickley<danbri at danbri.org> wrote:
>>> On 22/08/2009 20:23, Melvin Carvalho wrote:
>>>> On Sat, Aug 22, 2009 at 7:30 PM, Dan Brickley<danbri at danbri.org>  wrote:
>>>> On the subject of simplifications.
>>>> Do you think it might be worthwhile, putting a simple shorthand to
>>>> display your public key as a top level foaf element.
>>> In short, yes.
>>> Actually I was discussing this with Henry Story yesterday, as he passed
>>> through Amsterdam.
>> What I'd really love to see a single entry in the top level FOAF that
>> allows it's object to be a "public key", in much the same way that you
>> upload your public key to an SSH server, or a service like github.
> @prefix cert: <http://www.w3.org/ns/auth/cert#>
> You mean the inverse of the cert:identity relation ?
> I think rdfa allows you to work with inverse relations quite easily.
> Do you mean to do something like this:
> :me is cert:identity of <pubKey.rdf#key> .

I guess my "dream syntax" would be:

:me foaf:publicKey <key>

Where <key> could be a URI or a suitably encoded literal

> Where <pubKey.rdf#key> would be in another document?
> I think we can do this with the current ontology. We may just need to update
> our implementations for that.
> ( But I suspect you mean that the other document could be an x509 or a PGP
> key document. See my response to that further down.)
>> This would essentially mean that adding or removing a public key to a
>> page is roughly speaking a one line operation, which has been pretty
>> successful in the OpenID world.  However, there are a number of ways
>> to represent a public key, so it may be quite challenging to make
>> things ultra simple.
> that makes sense. I don't think we need a new relation though for this.
> Though perhaps I can see that we could have a relation in the foaf namespace
> that is the inverse of cert:identity, so that foaf files don't need to add
> one more namespace. But that is a very minor advantage.
> To see how useful this is, we need to look at the consequences on
> implementations of foaf+ssl. If it makes those implementations a lot more
> complex, they will be more difficult to debug, and as a result we will have
> a lot of situations where people cannot log into services they should be
> able to log into, resulting in a bad user experience. The user experience in
> the end should be what is paramount.
> One disadvantage of that is just that it will make implementations of
> foaf+ssl more complex at the reasoning layer. It will require a reasoning
> component in the rdf database so that queries for cert:identity return a
> value when the document contains information on the foaf namespaced inverse
> of that relation. Not a lot you may say, but at present we are getting
> people with little experience of semantic web to implement foaf+ssl in many
> different languages, and adding a reasoning component now, will make it more
> difficult for some implementations to get going.
> Another disadvantage is that if you have multiple certificates you would
> have a foaf:file with something like this:
> :me is cert:identity of <pubKey1#key>, <pubKey2#key>, <pubKey3#key> .
> Then the authentication agent on the server  would have to dereference each
> of those documents to find out which one referred to the public key that it
> is looking for. This could increase the login time quite dramatically if a
> person had a large number of such files.
> Ok, this could be solved by placing all the keys into one file like this:
> :me is cert:identity of <pubKeys#key1>, <pubKeys#key2>, <pubKeys#key3> .
> Relation to a PGP or X509 document
> ----------------------------------
> Now it could be interesting to have a relation that points from a foaf:Agent
> to a document that is a pgp key or an x509 key. This would not be the
> inverse of cert:identity, as that is a relation between a cert:PublicKey and
> a foaf:Agent.
> PGP keys or x509 certs, are in reality certificates, not keys. They contain
> keys, but they are signed documents that contain identity information, and
> are signed (by one or more signers).
> An advantage of such a relation would be that people who have pgp or x509
> certs could just dump them on their apache server.
> A disadvantage would be that implementations would now need to contain
> translations from PGP and X509 representations to RDF relations (allowing
> one then to query one's RDF store independent of the representations used).
> X509 is particularly tricky representation to parse btw, see Dan Kaminsky's
> presentation "X509 considered harmful" which I link to from
> http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009
> I don't doubt that Java does a good job at this, but other languages may not
> be as well tested as the code that goes into browsers.
> Another disadvantage is that the solution to the problem we had above of
> linking to public keys won't work here. That is we will only be able to
> write
> :me is cert:identity of <pgpdoc1>, <pgpdoc2>, <x509doc1>, <x509doc2> .
> But we cannot put more than one of these certs per doc. (I think, may be
> wrong here)
> So what we need to work out is how much the increase in complexity that we
> get here - that no doubt will come - is something we want to embark on at
> this point of the development of foaf+ssl.
> There may be other tasks that would be more useful for the moment to work
> on.
> I can think of the following:
>  - make sure all foaf+ssl agents can read rdfa representations
>  - make sure we can all deal with redirects - and the http-range-14 question
>  - increase the user base of foaf+ssl: get implementations to work in
> application servers like Drupal, Zope, Glassfish, etc...
>  - write many really cool apps that make use of it, so that it becomes a lot
> clearer to everyone what the advantages of the protocol are
>  - work on ways to authorize remote agents access to resources for a short
> period of time
>  - Access control vocabularies (see papers at SPOT2009)
> As the number of applications that use foaf+ssl grows - with serious apps
> using it - we will certainly discover some interesting problems that need to
> be solved. Making the base protocol more complex will only retard the
> development of such apps.
> So though I think these ideas are very good, I think the time is not yet
> ripe for them.
>>> The wot: namespace at http://xmlns.com/wot/0.1/ was always a bit of a
>>> messy
>>> first cut, and I had planned to integrate lessons from it directly into
>>> the
>>> FOAF namespace. A long time ago we had some experiments around signed
>>> FOAF
>>> (eg. see http://usefulinc.com/foaf/signingFoafFiles
>>> http://www.ibm.com/developerworks/xml/library/x-foaf2.html from Edd
>>> Dumbill), and also I made some less-directly-useful experiments taking
>>> the
>>> who-signed-which-key database from GPG and dumping that out in RDF. I've
>>> always thought it would be great if claims like "Dan says that Edd's key
>>> has
>>> fingerprint 1234" could more easily be thrown into the Web via FOAF. So I
>>> tend to come at this more from the "who signed this bunch of bytes which
>>> parse as RDF" side, rather than the protocols / SSL side.
>> Thanks for the links, this is really interesting, and perhaps the
>> final piece of the puzzle for FOAF.
>> I agree that it would be great to be able to transmit assurances from
>> one foaf to another, though it seems you'd really need to make things
>> highly usable, for it to gain some traction, or perhaps integrating
>> with some of the keyrings.  There are a lot more tools this time round
>> for things like single sign on (FOAF+SSL / OpenID), and updating FOAF
>> (SPARUL) as well as the xmlsig stuff.
>>> The signed FOAF stuff went a bit quiet, basically 'cos everyone who plays
>>> with it says "oh, cool", and then within a few weeks has forgotten how to
>>> use GPG, lost their passphrase, or whatever. These days I'd like it if we
>>> could have some advice and tools for signing FOAF (and checking) with
>>> xmlsig
>>> tools. I think it's worth revisiting for various reasons, including the
>>> libraries you can expect to find in modern java installations, and the
>>> "graph" capabilities now offered by all SPARQL systems.
>>> Where I got stuck with the earlier wot: experiments, not being a crypto
>>> person, was w.r.t. wanting to sit on the fence as much as possible re
>>> x509
>>> "vs" pgp ...
>>> How much can be done that would work in both worlds?
>> I've read about public keys being used in X.509 and GPG, though it's
>> not normally encouraged.  It would make sense for a user to reuse the
>> same key for both purposes (authentication and signing) if possible.
>> Though, I believe Toby Inkster has managed to sign an email using the
>> key from his X.509 certificate.
>>>> This would be all you need to do, to make your profile into a F.OAF+SSL
>>>> identity.
>>>> I do think that the current RDFa for expressing a public key in RDFa
>>>> is quite tricky, at the moment.
>>>> While I dont have an issue with nested tags or bnodes, perhaps it
>>>> could be offputting to some adopters?
>>> If it can be made simple and flat and in the same namespace as FOAF, that
>>> does ease some deployment hurdles.
>> I'll spend some time exploring possibilities in this direction, with a
>> view to getting a proof of concept working, and will post back to the
>> group when I've been through some more of the details.
>>> cheers,
>>> Dan
>> _______________________________________________
>> foaf-dev mailing list
>> foaf-dev at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-dev

More information about the foaf-dev mailing list