A Foaf file for Sun!
By bblfish on Jul 25, 2007
Sun Microsystems has recently given all its employees an OpenId that is guaranteed to identify each person at Sun. This has allowed me to add the following to my foaf file:
:me foaf:openid <http://openid.sun.com/bblfish> .
Now it would be nice if Sun could make the statement that all of its employees have such ids in a machine readable way. This could then be used by other organisations, say the W3C of which Sun is a member, to identify all of Sun's employees, and so give them access to member only parts of the W3C web site. But with OpenId as it currently stands this is usually thought to be impossible. For at its core OpenId just allows a client service to verify that an EndUser has its identity confirmed by a certain service, which the end user points you to. There is no way to specify what the service is, who it is related to, who owns the id, etc...
Well OpenId does not provide for this out of the box, but it is not difficult to imagine how one could do this. The first thought that comes to mind is to have Sun Microsystems publish a foaf file (for Sun) that listed all its members using the new foaf:openid inverse functional property. I am imagining something like this:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://sun.com/sunw#> . <> a foaf:PersonalProfileDocument; foaf:primaryTopic :sunw. :sunw a foaf:Organization, foaf:Group; foaf:name "Sun Microsystems"@en; foaf:homepage <http://www.sun.com/>; foaf:member [ foaf:openid <http://openid.sun.com/bblfish> ], [ foaf:openid <http://openid.sun.com/jag> ]; ....
So Sun would just have to point the W3C to <http://sun.com/sunw> and it could find all the Sun employees OpenIds and give them special priviledges on the W3C web sites. By regularly polling that file, the W3C could keep up to date with its list.
But the problem with the above solution is that it is releasing perhaps more information than necessary. After all each of those openids could be linked to a foaf file, as I explained recently, so revealing a lot of information about the employees at Sun. It would also require regular polling to be kept up to date, and so would be leaky. That is it might not work right after a employee has created his brand new OpenId, thereby leading to some tricky to report bug reports, bad feelings, etc... It may also end up being a very long files - quite long for companies the size of Sun, a lot longer for companies the size of IBM, too long for the Indian Railways (which has over a million employees) and certainly not imaginable for countries such as the USA were it to want to list all its citizens.
What is really needed is a service that can verify the belonging of an id to a group. Wait! That is what OpenId 1.1 provides! The OpenId Server URL names a resource that does two things:
- It can veryify OpenId URLs as being ones that are part of the group it can identify
- It can identifies User Agents as being ones that knows a secret tied to that OpenId (owns it).
So to take the Sun example, all that is needed is to specify that
https://openid.sun.com/openid/service is an openid group identifier, and that all IDs that can be identified via that service are identifiers for members of that group.
So let us create such a relation now, and place it in some temporary openid namespace:
@prefix openid: <http://openid.org/tmp/ont#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . openid:memberIdService a owl:ObjectProperty; rdfs:label "openid member identification service"; rdfs:comment """Any agent that can identify with an openid ID to this service is the agent who is the subject of the foaf:openid relation to that ID, and that agent is a member of this group."""@en; rdfs:domain foaf:Group; rdfs:range openid:IDAuthService . openid:IDAuthService a owl:Class; rdfs:label "OpenID Authentication Service"; rdfs:comment "Members of this class are resources that can authenticate agents who present an OpenID."@en .This would allow us then to write our information about Sun Microsystems like this
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://sun.com/sunw#> . @prefix openid: <http://openid.org/tmp/ont#> . <> a foaf:PersonalProfileDocument; foaf:primaryTopic :sunw. :sunw a foaf:Organization, foaf:Group; foaf:name "Sun Microsystems"@en; foaf:homepage <http://www.sun.com/>; openid:memberIdService <https://openid.sun.com/openid/service>.
So now when Sun wishes to become a member of a prestigious organisation like the W3C, all we need to do is send them Sun's foaf file URL. This will give them our openid:memberIdService which they can use to identify all of our members. That way they or any other service can tell who our employees are without us ever giving them a list.
Let's look at this the other way around. A web service such as DZone asks me to identify myself and I give them my OpenId
http://openid.sun.com/bblfish. That OpenId may have links to a number of different OpenId Servers. Which one should DZone use? Well it may recognise one of them, and just use that. But would it not be nice if the OpenId services could say something about themselves? One very useful thing they could say is what group they identified. This could be done in a nice RESTful way by simply asking for an RDF representation of the service for which we could get the easier to read N3 representation like this:
hjs@bblfish$ cwm https://openid.sun.com/openid/service @prefix openid: <http://openid.org/tmp/ont#> . <> a openid:IDAuthService; openid:serviceFor <http://sun.com/sunw#sunw> .So this would allow a service to follow its nose from openids to the groups they belong to, and assess the trust it has in those groups. The serviceFor relation above could simply be defined as
openid:serviceFor owl:inverseOf openid:memberIdService .
Now you may ask: How does anyone know to trust Sun's foaf file or the Sun OpenId memberIdService? Here we can work a network of trust model as described by David Weitzner in "Whose name is it anyway". To illustrate this imagine the following: If the W3C's foaf file lists its member organisations, by pointing to each of their foaf files, and if the NASDAQ lists its member companies that way using the same foaf file, and Sun itself points back to both of them, then that would be a way of having a distributed reinforcement of the confidence one can have in OpenId servers. After all, if one trusts NASDAQ and the W3C's foaf file, then one should be able to trust that they point to the Sun foaf file correctly. A company listing its members or related organisations is a bit like a person linking to its friends. This is what creates a network of trust.