[foaf-protocols] relation from foaf to pubkey -- was: [foaf-dev] strawpoll: migrate from foaf:holdsAccount to foaf:account?
henry.story at bblfish.net
Tue Aug 25 13:38:12 CEST 2009
[[Just as a note: the holdsAccount discussion should really be limited
to the foaf-dev list. It is not relevant to the foaf-protocols
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>
>> On 22/08/2009 20:23, Melvin Carvalho wrote:
>>> On Sat, Aug 22, 2009 at 7:30 PM, Dan Brickley<danbri at danbri.org>
>>> 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
>> 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> .
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
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
: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
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
- 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
- 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.
>> 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
>> 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
>> 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
>> libraries you can expect to find in modern java installations, and
>> "graph" capabilities now offered by all SPARQL systems.
>> Where I got stuck with the earlier wot: experiments, not being a
>> 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
>>> 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.
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
More information about the foaf-protocols