The Sun BabelFish Blog

Don't panic !

Friday Mar 20, 2009

Join the foaf+ssl community and get OpenId for free

Toby Inkster today was the first to put up an OpenId authentication service, that uses foaf+ssl certificates as credentials. This means that anyone with a foaf+ssl certificate can now log in not just to all the fun foaf+ssl services that are popping up, but also to the 100's of thousand of other services out there that are using OpenId - making it so much more valuable.

The OpenId service is written in Perl and requires less that 100 lines of code (see source).

From a user's perspective this is what happens, once everything is set up.

Go to an OpenId enabled service - I tried DZone and Identi.ca.
Enter your OpenId - I used http://bblfish.net/ - in the provided field. And click return.
Your browser will open a client cert popup asking which certificate you want to send - (you should set your browser up to ask you). Choose your foaf+ssl enabled cert. Press enter.
You will be logged in.

This has a few advantages:

You no longer have to remember a password for the OpenId server. Your browser keeps that information.
The OpenId server does not know your password either.
You never had to tell the OpenId Server anything about yourself. All the information is available in your foaf file. And you could protect parts of your foaf file with foaf+ssl so that the OpenId service need know just the public stuff. You could then give special access to the service you are logging into to see protected parts.
It is very easy to change the OpenId Server: just change the openid.server line in your OpenId page. Since the server maintains no state about you, this is easy to do: you won't have to create a new account, specify your name, address, ... remember another password, etc...
No need for attribute exchange - though the server could easily be enhanced to enable it - since the attributes are all in the foaf file, linked to from the OpenId page. See my 2007 post: Foaf and Openid.
It takes one less request to do this than in usual OpenId implementations, as the login step is removed. (this is replaced it is true by one more connection from the OpenId server to the foaf file. But this could be cached.)

It is very easy to get going - especially given that we are dealing with the first release software! Here are the steps:

First of course get yourself a foaf+ssl certificate in your browser, and a correspondingly foaf id. There are a number of services listed on the foaf+ssl wiki. Two solutions:
- You can use the easy to use foafssl.org certificate creation service, but you'll need the foaf file to then point back to the OnlineAccount just created. This would require adding the following triple in geek mode to your foaf file, in order to help verify your identity claim:
```
<http://you.com/foaf#me> <http://xmlns.com/foaf/0.1/holdsAccount> <http://test.foafssl.org/certs/0xx.rdf#accnt>.
```
- Or you can follow the even more geeky instructions from my original blog to create yourself a certificate.
We need to work on making the user experience much easier of course. This here is still just a proof of concept.
Next add a link from your OpenId page to the foaf server, and to your foaf file. A good choice for your OpenId page is your home page. Add the following in the <head>...</head> section of your html. <link rel="openid.server" href="https://ophelia.g5n.co.uk:10443/openid/provider.cgi?webid=http%3A%2F%2Fbblfish.net%2Fpeople%2Fhenry%2Fcard%23me" title="FOAF+SSL OpenId Server"/> <link rel="meta" title="foaf" href="http://bblfish.net/people/henry/card" type="application/rdf+xml" /> You can see an example in the source of my home page at http://bblfish.net/. The pattern to follow for the href attribute is https://ophelia.g5n.co.uk:10443/openid/provider.cgi?webid=W where you replace W by the URL encoded value of your WebId. (You can use an online service such as this devshed one to do the encoding). The encoded WebId helps the OpenId authentication service verify that the person logging in there is really you - the person referred to by your webid. You should also point to your foaf file using the meta link, so that other services on the web can find this information easily.
You need to add a foaf:openid relation from your WebId to your OpenId page in your foaf file. This is so that the OpenId server can identify you in your foaf file. I added the following triple in my foaf.
```
<http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid> <http://bblfish.net/> .
```
Which can take a number of different forms in rdf/xml of course.

That is it. This could easily be automated by foaf service providers. I'll update it as soon as we have some easier means of doing this.

Posted at 03:37PM Mar 20, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Thursday Dec 04, 2008

video on distributed social network platform NoseRub

I just came across this video on Twitter by pixelsebi explaining Distributed social networks in a screencast, and especially a php application NoseRub. Here is the video.

Distributed Social Networking - An Introduction from pixelsebi on Vimeo.

On a "Read Write Web" article on his video, pixelsebi summarizes how all these technologies fit together:

To sum it up - if I would have to describe it somebody who has no real clue about it at all:

Distributed Social Networking is an architecture approach for the social web.
DiSo and Noserub are implementations of this "social web architecture"
OpenSocial REST API is one of many ways to provide data in this distributed environment.
OpenOScial based Gadgets might run some time at any node/junction of this distributed environment and might be able to handle this distributed social web architecture.

So I would add that foaf provides semantics for describing distributed social networks, foaf+ssl is one way to add security to the system. My guess is that the OpenSocial Javascript API can be decoupled from the OpenSocial REST API and produce widgets however the data is produced (unless they made the mistake of tying it too closely to certain URI schemes)

Posted at 12:49PM Dec 04, 2008 [permalink/trackback] by Henry Story in SemWeb | Comments[0]

Friday Mar 28, 2008

RDFAuth: sketch of a buzzword compliant authentication protocol

Here is a proposal for an authentication scheme that is even simpler than OpenId ( see sequence diagram ), more secure, more RESTful, with fewer points of failure and fewer points of control, that is needed in order to make Open Distributed Social Networks with privacy controls possible.

Update

The following sketch led to the even simpler protocol described in Foaf and SSL creating a global decentralized authentication protocol. It is very close to what is proposed here but builds very closely on SSL, so as to reduce what is new down to nearly nothing.

Background

Ok, so now I have your attention, I would like to first mention that I am a great fan of OpenId. I have blogged about it numerous times and enthusiastically in this space. I came across the idea I will develop below, not because I thought OpenId needed improving, but because I have chosen to follow some very strict architectural guidelines: it had to satisfy RESTful, Resource oriented hyperdata constraints. With the Beatnik Address Book I have proven - to myself at least - that the creation of an Open Distributed Social Network (a hot topic at the moment, see the Economist's recent article on Online social network) is feasible and easy to do. What was missing is a way for people to keep some privacy, clearly a big selling point for the large Social Network Providers such as Facebook. So I went on the search of a solution to create a Open Distributed Social Network with privacy controls. And initially I had thought of using OpenId.

OpenId Limitations

But OpenId has a few problems:

First it is really designed to work with the limitations of current web browsers. It is partly because of this that there is a lot of hopping around from the service to the Identity Provider with HTTP redirects. As the Tabulator, Knowee or Beatnik.
Parts of OpenId 2, and especially the Attribute Exchange spec really don't feel very RESTful. There is a method for PUTing new property values in a database and a way to remove them that does not use either the HTTP PUT method or the DELETE method.
The OpenId Attribute Exchange is nice but not very flexible. It can keep some basic information about a person, but it does not make use of hyperdata. And the way it is set up, it would only be able to do so with great difficulty. A RESTfully published foaf file can give the same information, is a lot more flexible and extensible, whilst also making use of Linked Data, and as it happens also solves the Social Network Data Silo problems. Just that!
OpenId requires an Identity Server. There are a couple of problems with this:
- This server provides a Dynamic service but not a RESTful one. Ie. the representations sent back and forth to it, cannot be cached.
- The service is a control point. Anyone owning such a service will know which sites you authenticate onto. True, you can set up your own service, but that is clearly not what is happening. The big players are offering their customers OpenIds tied to particular authentication servers, and that is what most people will accept.

As I found out by developing what I am here calling RDFAuth, for want of a better name, none of these restrictions are necessary.

RDFAuth, a sketch

So following my strict architectural guidelines, I came across what I am just calling RDFAuth, but like everything else here this is a sketch and open to change. I am not a security specialist nor an HTTP specialist. I am like someone who comes to an architect in order to build a house on some land he has, with some sketch of what he would like the house to look like, some ideas of what functionality he needs and what the price he is willing to pay is. What I want here is something very simple, that can be made to work with a few perl scripts.

Let me first present the actors and the resources they wish to act upon.

Romeo has a Semantic Web Address Book, his User Agent (UA). He is looking for the whereabouts of Juliette.
Juliette has a URL identifier ( as I do ) which returns a public foaf representation and links to a protected resource.
The protected resource contains information she only wants some people to know, in this instance Romeo. It contains information as to her current whereabouts.
Romeo also has a public foaf file. He may have a protected one too, but it does not make an entrance in this scene of the play. His public foaf file links to a public PGP key. I described how that is done in Cryptographic Web of Trust.
Romeo's Public key is RESTfully stored on a server somewhere, accessible by URL.

So Romeo wants to find out where Juliette is, but Juliette only wants to reveal this to Romeo. Juliette has told her server to only allow Romeo, identified by his URL, to view the site. She could have also have had a more open policy, allowing any of her or Romeo's friends to have access to this site, as specified by their foaf file. The server could then crawl their respective foaf files at regular intervals to see if it needed to add anyone to the list of people having access to the site. This is what the DIG group did in conjunction with OpenId. Juliette could also have a policy that decides Just In Time, as the person presents herself, whether or not to grant them access. She could use the information in that person's foaf file and relating it to some trust metric to make her decision. How Juliette specifies who gets access to the protected resource here is not part of this protocol. This is completely up to Juliette and the policies she chooses her agent to follow.

So here is the sketch of the sequence of requests and responses.

First Romeo's user Agent knows that Juliette's foaf name is http://juliette.org/#juliette so it sends an HTTP GET request to Juliette's foaf file located of course at http://juliette.org/
The server responds with a public foaf file containing a link to the protected resource perhaps with the N3
```
  <> rdfs:seeAlso <protected/juliette> .
```
Perhaps this could also contain some relations describing that resource as protected, which groups may access it, etc... but that is not necessary.
Romeo's User Agent then decides it wants to check out protected/juliette. It sends a GET request to that resource but this time receives a variation of the Basic Authentication Scheme, perhaps something like:
```
HTTP/1.0 401 UNAUTHORIZED
Server: Knowee/0.4
Date: Sat, 1 Apr 2008 10:18:15 GMT
WWW-Authenticate: RdfAuth realm="http://juliette.org/protected/*" nonce="ILoveYouToo"
```
The idea is that Juliette's server returns a nonce (in order to avoid replay attacks), and a realm over which this protection will be valid. But I am really making this up here. Better ideas are welcome.
Romeo's web agent then encrypts some string (the realm?) and the nonce with Romeo's private key. Only an agent trusted by Romeo can do this.
The User Agent then sends a new GET request with the encrypted string, and his identifier, perhaps something like this
```
GET /protected/juliette HTTP/1.0
Host: juliette.org
Authorization: RdfAuth id="http://romeo.name/#romeo" key="THE_REALM_AND_NONCE_ENCRYPTED"
Content-Type: application/rdf+xml, text/rdf+n3
```
Since we need an identifier, why not just use Romeos' foaf name? It happens to also point to his foaf file. All the better.
Because Juliette's web server can then use Romeo's foaf name to GET his public foaf file, which contains a link to his public key, as explained in "Cryptographic Web of Trust".
Juliette's web server can then query the returned representation, perhaps meshed with some other information in its database, with something equivalent to the following SPARQL query
```
PREFIX wot: <http://xmlns.com/wot/0.1/>
SELECT ?pgp
WHERE {
     [] wot:identity <http://romeo.name/#romeo>;
        wot:pubkeyAddress ?pgp .
} 
```
The nice thing about working at the semantic layer, is that it decouples the spec a lot from the representation returned. Of course as usage grows those representations that are understood by the most servers will create a de facto convention. Intially I suggest using RDF/XML of course. But it could just as well be N3, RDFa, perhaps even some microformat dialect, or even some GRDDLable XML, as the POWDER working group is proposing to do.
Having found the URL of the PGP key, Juliette's server, can GET it - and as with much else in this protocol cache it for future use.
Having the PGP key, Juliette's server can now decrypt the encrypted string sent to her by Romeo's User Agent. If the decrypted string matches the expected string, Juliette will know that the User Agent has access to Romeo's private key. So she decides this is enough to trust it.
As a result Juliette's server returns the protected representation.

Now Romeo's User Agent knows where Juliette is, displays it, and Romeo rushes off to see her.

Advantages

It should be clear from the sketch what the numerous advantages of this system are over OpenId. (I can't speak of other authentication services as I am not a security expert).

The User Agent has no redirects to follow. In the above example it needs to request one resource http://juliette.org/ twice (2 and 4) but that may only be necessary the first time it accesses this resource. The second time the UA can immediately jump to step 3. [but see problem with replay attacks raised in the comments by Ed Davies, and my reply] Furthermore it may be possible - this is a question to HTTP specialists - to merge step 1 and 2. Would it be possible for a request 1. to return a 20x code with the public representation, plus a WWWAuthenticate header, suggesting that the UA can get a more detailed representation of the same resource if authenticated? In any case the redirect rigmarole of OpenId, which is really there to overcome the limitations of current web browsers, in not needed.
There is no need for an Attribute Exchange type service. Foaf deals with that in a clear and extensible RESTful manner. This simplifies the spec dramatically.
There is no need for an identity server, so one less point of failure, and one less point of control in the system. The public key plays that role in a clean and simple manner
The whole protocol is RESTful. This means that all representations can be cached, meaning that steps 5 and 7 need only occur once per individual.
As RDF is built for extensibility, and we are being architecturally very clean, the system should be able to grow cleanly.

Contributions

I have been quietly exploring these ideas on the foaf and semantic web mailing lists, where I received a lot of excellent suggestions and feedback.

In January I asked on foaf dev list how one should cut up a foaf file in order to be able to protect parts of the information, in a thread entitled "for more information please log in". This lead to an initial proposal by Dave Brondsema which I summarized on Jan 18.
This week I started out the conversation again, and extended it to the semantic web mailing list to get some wider interest with a thread entitled "privacy and open data".
The above thread led me to sketch out more clearly the functioning of this protocol, with a post entitled "RDFAuth: an initial sketch", that developed into a very useful thread. I tried to take account some of the suggestions put forward there in writing this post. Others suggestions, such as the idea by Renato Gollin to work into this a three way challenge response are very interesting and should be looked into, but are way over my head.
I had a very useful discussion with Benjamin Nowack (a.k.a. bengee) on #swig where he pointed me to some initial work he had done on the same subject. He had sketched this out on the swig wiki and called it RDFAuth. Since this was clearly going in the same direction I took us to be working on the same project. The next day I found that we may have slightly different views on how this should go. Bengee seems to think we need a token server. I hope we really don't. The big advantage of using Public Key cryptography is that it massively simplifies the protocol. I still think I can convince him :-), so I have kept the name.
Toby Inkster, suggested a way to link this in with HTTPS which would be fabulous. I missed the post, and he reminded me by summarising it here. Not being an https expert (yet) I can't comment. I have been reading up on this and it does seem to be an even better solution. See the thread on the HTTP-WG mailing list. It is really a brilliant idea. I am working on this and will post an update as soon as I have something working.
Peter Williams suggested looking at RFC 2617: on Basic and Digest Authentication and the less successful RFC 2693 SPKI Certificate Theory.

Finally

So I suppose I am now looking for feedback from a wider community. PGP experts, security experts, REST and HTTP experts, semantic web and linked data experts, only you can help this get somewhere. I will never have the time to learn these fields in enough detail by myself. In any case all this is absolutely obviously simple, and so completely unpatentable :-)

Thanks for taking the time to read this

Posted at 04:09PM Mar 28, 2008 [permalink/trackback] by Henry Story in SemWeb | Comments[18]

Wednesday Jul 25, 2007

A Foaf file for Sun!

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.

Posted at 06:05PM Jul 25, 2007 [permalink/trackback] by Henry Story in SemWeb | Comments[0]

Friday Jul 20, 2007

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 "openid.sun.com/bblfish" 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 http://openid.sun.com/bblfish should not just return a representation that contains a link to the openid server

<link rel="openid.server" href="https://openid.sun.com/openid/service" />

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="https://openid.sun.com/openid/service" />
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://bblfish.net/people/henry/card"/>

which is what videntity.org has been doing since 2005 [1], and openid.org 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: <http://xmlns.com/foaf/0.1/>
SELECT ?mbox ?logo ?nick
WHERE {
        ?p foaf:openid <http://openid.sun.com/bblfish>.
     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 http://bblfish.net/people/henry/card --sparql=./openid.sparql 
#   Base was: http://bblfish.net/people/henry/card
     @prefix : <http://www.w3.org/2000/10/swap/sparqlCwm#> .
    {
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <mailto:henry.story@bblfish.net>     :bound "mbox" .

        }     a :Result .
    {
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <mailto:henry.story@gmail.com>     :bound "mbox" .

        }     a :Result .
    {
        "bblfish"     :bound "nick" .
        </pix/bfish.large.jpg>     :bound "logo" .
        <mailto:henry.story@sun.com>     :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.

Notes

[1]: Videntity.org 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?
[2]: Sadly I have not been able to use that openid.org 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.
[3]: 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.

Posted at 12:34PM Jul 20, 2007 [permalink/trackback] by Henry Story in SemWeb | Comments[7]

Wednesday Jun 06, 2007

http://openid.sun.com/bblfish

That's my new OpenId.

I was able to successfully log onto:

(Using Safari but not Firefox 2.004 !?)

And I did not have to invent a new username and password, nor fill out any form, other than to fill out my id. I did not have to wait for an email confirmation, nor send an email response or go to a web verification site. I did not have to add one more password to my keychain.
A really small step, but oh what a useful one!

I can add this info to my foaf file with the simple relation :

<http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid> <http://openid.sun.com/bblfish> .

This will come in very useful, one way or another. See the article "foaf and openid", for an example.

Posted at 07:18AM Jun 06, 2007 [permalink/trackback] by Henry Story in General | Comments[0]

Wednesday Feb 28, 2007

OpenId for blogs.sun.com ?

The volume of posts on OpenId, is clearly growing in importance, and big players such as AOL and Microsoft are joining the party. The technical introduction for web developers on the openid wiki will help make more sense of the following discussion:

Tim Bray started a discussion on the subject. It looks to me like most of his question get answered in the replies.
Six Cool Things to do with OpenId
O'Reilly Radar Pros and cons of OpenId
Phil Windley's OpenID Economics Centers on Relying Parties (via Dave M Johnson)

Given the Web 2.0 is so very much about Micro Killer Apps single sign on is an absolute necessity. As Paul Diamond notes web 2.0 has created a huge number of services that need to be integrated. Indeed, there are services (eg Convinceme) I have not used recently, or blogs I have not responded to, just because I did not want to go through yet another sign on service.

Having OpenId on blogs.sun.com would allow many nice features. Once someone had been allowed to answer a comment on a blog, they could be enabled for every other comments they make without requiring any further aproval. One could generalize this to allow anyone who had ever been allowed by someone on blogs.sun.com to comment, or to all of one's friends as specified in a foaf file.
Danbri points to Doxory.com (tag line: life by committee) as being one such service that uses both the openid information with a foaf file to provide some interesting service. Danny Ayers points to videntity.org as one of the many open id identity registrars that offers you a foaf file. Open Data Spaces, which is built on Virtuoso uses the same url for the openid and the foaf file, and furthermore that URL is editable using WebDav!

Having read the technical introduction carefully, I think the meshing with foaf is simply accomplished like this:
The Foaf url can simply be the open id. According to current OpenId specs the id would have to be able to return a text/html representation, so that the consumer (the blog that is requiring authentication for example), can search the html for the openid.server link relation. The foaf id would then also be able to return and xml/rdf representation by a client on request. This would save the end user from having to learn two different ids, and it would be a way of authenticating a foaf file on top of it. In this scenario the html representation should have a foaf link relation pointing back the the same url.

Otherwise it would probably be useful to have a sioc property to link to an open id.

Posted at 07:32AM Feb 28, 2007 [permalink/trackback] by Henry Story in General | Comments[3]