foaf and openid

My Sun OpenId is helping me use many services I would not have used before. For example I have started using DZone which is a service like DIGG in that it allows one to vote for interesting stories on the web. But unlike DIGG, I don't have to go through the rigmarole of setting up a new account, waiting for an email, replying to the email, remembering one more password which I have to look up in my keychain anyway, etc, etc...

From my short experience I have identified some simple ways one can improve the user experience. Currently for example all the server knows about me is my openId URL. That makes for an impersonal experience, as you can see from this comment I posted:

I am identified as "" and there is no icon to represent me. If I want a more personal experience I need to register! Which means just entering my name, an email address and a few passwords. Ouch! So we are back to pre-openid land. One more password to enter, and to remember...

Luckily there is an obvious and easy fix to this. My openid should not just return a representation that contains a link to the openid server

<link rel="openid.server" href="" />
but also a link to a representation that contains more information about me, which would be my foaf file. This could be done very simply by growing the header of my openid html by one line, as specified by the foaf FAQ:
<link rel="openid.server" href="" />
<link rel="meta" type="application/rdf+xml" title="FOAF" href=""/>
which is what has been doing since 2005 [1], and has been providing since early July [2]. Now all that would be needed then is for dzone to read the foaf file pointed to, and extract the name relation, email and logo from the person described in the foaf file with the same openid. This could be done with a simple SPARQL query such as
PREFIX foaf: <>
SELECT ?mbox ?logo ?nick
        ?p foaf:openid <>.
     OPTIONAL { ?p foaf:mbox ?mbox } .
     OPTIONAL { ?p foaf:logo ?logo } .
     OPTIONAL { ?p foaf:nick ?nick } .
If you save the above to a file - say openid.sparql - you can run it on the command line using the python cwm script like this:
hjs@bblfish:2$ cwm --sparql=./openid.sparql 
#   Base was:
     @prefix : <> .
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <>     :bound "mbox" .

        }     a :Result .
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <>     :bound "mbox" .

        }     a :Result .
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <>     :bound "mbox" .

        }     a :Result .

That's how simple it is! [3]

For those who are still trying to keep their info private, one could add some content negotiation mechansim to the serving of the foaf file, such that depending on the authentication level of the requestor (dzone in this case), the server would return more or less information. If dzone could somehow show on requesting my foaf file, that I had authenticated them, and that should not be difficult to do, since I just gave them some credentials, I could give them more information about me. How much information exactly could be decided in the same box that pops up when I have to enter the password for the service... A few extra checkboxes on that form could ask me if I want to allow full, partial or minimal view of my foaf relations. Power users with more time on their hands could even decide on a relation by relation basis.


[1] works nicely, and can even import all the information nicely from an existing foaf file! I would rather they give me the option to link to my original foaf file, which I am maintaining, rather than create yet another one on their server. Their foaf creates bnode urls, which makes me a little nervous (The only bnode url that makes me smile is Benjamin Nowack's). Also there is a bug in their foaf file, in that they have given me a URL which makes me both a foaf:Person and a foaf:Document. foaf does specify that there is nothing in the intersection of those sets. Does this make me a budhist?
Sadly I have not been able to use that account to log into anything yet. There seems to be a bug in their windows service. Their foaf file returns nearly no information at present and is incomplete. But the idea is good.
Here cwm returns an N3 representation. SPARQL servers usually can return both a SIMPLE XML and a simple JSON representation. Those working with a programming library, will skip the serialization step end up directly with a collection of solution objects that can be iterated through directly.

"all the server knows about me is my openId URL" is incorrect though; the OpenID specification includes the ability to send an icon and a name. Whether the service you are utilising via OpenID actually uses those pieces of information though is clearly another matter.

Posted by Alison Wheeler on July 20, 2007 at 08:58 AM CEST #

Come on Dmitry this has all been done before (re: comment 1 - ideas work through constructive suggestions, such as this post). I provided FOAF as an experiment - i wish i had more time to devote to the site. I hope I get more time in the coming weeks to fix a few things that seem to have broken. VIdentity is cool too - i signed up some time ago. Good post.

Posted by Steven Livingstone on July 20, 2007 at 10:37 AM CEST #

Is there a way to get this information just in the normal course of things through Attributes in the OpenID spec?

Posted by Matthew on July 23, 2007 at 06:24 PM CEST #

Mathew wrote:
Is there a way to get this information just in the normal course of things through Attributes in the OpenID spec?
I searched the openid site and found the Openid attribute exchange draft, which describes a proposed way to do this by querying the Identity Provider ( in my example) for attributes. It also defines a method for storing attributes there.

I see two problems with this:

  • It ties the identity provider to the identity. The nice thing about OpenId, is that it separates the role of the identity provider and the identity. This allows one to have an id (I could use and change identity provider over time, as I change job for example, or even have a number of different ones at the same time. The OpenId attribute exchange is overloading the identity provider (which is really an identity verifier) functionality relating to identity description.
  • It does not feel RESTful. If something is to return information it should have a URL. Here there is very clearly overlapping of concerns as explained above. What is the url for information for one identity here? I have a large alarm bell ringing when I read sections such as: "Fetch message" and "store message". Is that not the equivalent of HTTP GET and PUT?
  • duplicating effort. This spec is inventing a metadata format, a query language and storage API, which is a lot of work. These things have been done before:
    • metadata framework: as shown above RDF does this very well already. It has a very powerful semantics, has gone through years of review by some of the best thinkers in the world, is extensible, self describing, etc, etc... having to learn another special convention as proposed here, is one more unnecessary piece of work.
    • query language: SPARQL though not yet finished does everything that is needed here as shown in the example above
    • storage: this could be done using a number of well known technologies, such as ftp, scp, Atom Protocol, or even WebDav. AtomP and WebDav are even nicely RESTful.
A simple link to a foaf file as described in this article covers most uses cases, and is incredibly flexible. If one wants to have different personas, one should probably use different openids anyway, since as the foaf people have correctly defined it foaf:openid is an inverse functional property. So if someone knows that
_:niceJoe a foaf:Person;
         foaf:openid <>;
         foaf:nick "joey";
         foaf:email <> .
and also knows that
_:badJoe a foaf:Person;
         foaf:openid <>;
         foaf:nick "bj";
         foaf:email <> .
Then they know that
[] a foaf:Person;
         foaf:openid <>;
         foaf:nick "joey";
         foaf:email <> ;
         foaf:email <> .
An open id identifier is an identifier. You should really not be using the same identifier if you want to have different independent personas.

Posted by Henry Story on July 25, 2007 at 04:45 AM CEST #

Norman Gray set me right on a few points with respect to the functioning of the OpenId attributes exchange draft. I had not understood that the query goes through the service via the UserAgent, and that the User can then be given the choice as to which properties to send the Client Service that he wishes to log into. The query makes more sense that way. It is very limiting in what attributes it can show, unlike rdf, but the idea is neat. So the foaf link from the OpenId resource makes it possible to reveal more information, but does not make it easy for the End User to decide what the Client is going to see. The attribute exchange makes it easy to for the EndUser to determine what the Client is going to see, but is not very flexible. In any case I don't think the way they go around adding attributes is such a good idea. An HTTP PUT of rdf would be a lot better...

Posted by Henry Story on July 26, 2007 at 06:16 PM CEST #

Peter Williams, who was hanging out on the OpenId mailing list, has gone from not knowing anything about the Semantic Web, to getting very enthusiastic about it. Check out this blog of his:!5061D4609325B60!212.entry

(A little ironic that one can only use Microsoft CardSpace to drop a comment on there!)

Posted by Henry Story on September 18, 2007 at 05:37 AM CEST #

The Linked Data workgroup at the W3C is using foaf and openid to help filter out who can access their wiki in a distributed but effective way.

See this very interesting article:

Posted by Henry Story on January 05, 2008 at 08:10 AM CET #

Post a Comment:
Comments are closed for this entry.



« July 2016