You may have read Henry Story's recent post about RDFAuth, an RDF-oriented mechanism to access (partly) protected web resources. He's not describing the RDFAuth protocol, though. I've tried to clarify things a couple of times on the semantic-web list, but somehow he seems to prefer to hijack the name instead, together with parts of the idea and claim it as his invention (it's not mine either, to make things clear). Now, innovation is always based on a combination of prior work and improvements, but his "following my strict architectural guidelines, I came across what I am just calling RDFAuth" preening goes a tiny bit too far to not trigger a comment.
What he describes (a PGP-based authentication protocol) is clearly interesting, but it's simply not what RDFAuth, an idea that was developed in the knowee project, is about. For knowee (which just released the alpha version, btw), we needed something that can be implemented on basic, shared web servers. PGP is simply not an option (if considered mandatory). People won't upload their private keys to 3rd party servers, and PGP libs are not necessarily available in those environments either.
Final clarifications:
- RDFAuth may support PGP, it's just not a requirement.
- I'm pretty sure that Henry's PGP-only approach will attract more SemWeb geeks than RDFAuth, it just wouldn't necessarily work for knowee's target audience.
- The RDFAuth idea is in no way special or new. It more or less predates oAuth, but long-term-ish I'll most probably have to replace it with oAuth, once there is a way to generate tokens without the browser redirect dance (fully server-side token generation is another knowee requirement).
- I read about a token-based, decentralized identification mechanism on a very early OpenID FAQ page that described a non-browser-dependent way to log into web sites. I can't find the link anymore, but this is basically what RDFAuth is based on. So, this is not my idea either.
- The possibility of combining 200 OK response headers with WWW-Authenticate was suggested by Etan Wexler on the FOAF mailing list
- Dan Brickley explored SPARQL-based group membership discovery a while back. I like this idea of de-coupling data exchange decisions from the identification/authorisation process very much (RDFers don't need things like sReg or Attribute Exchange).
- The only thing that RDFAuth adds is light-weight, personal token services (as a replacement of OpenID's browser-based identification), and the re-use of straight HTTP BasicAuth, so that partly protected resources can more easily be discovered by both server-side and client-side tools (e.g. Tabulator), and also to allow widely deployed modules like mod_php to access the login token and client identifier using built-in functionality. And I doubt that layering a protocol on top of HTTP BasicAuth hasn't been done before, so, again, nothing special to brag about here.


Comments and Trackbacks
I do mention our talk together at the end of the post. I also pointed to the mailing list trail, and I was very careful to say that all this is sketchy, and that the name was just one I chose "for want of a better one". I should perhaps have put the section where I thank people for their contributions in helping me reach this point at the top of the post. But with the post being already so long I fear nobody would have read it. In any case I was not speaking for anyone - you for example put two criticisms forward of that way of doing things. At the end I also mention that all this is evident, and so "unpatentable"; so I am not even trying to impose any rights on this.
Note thought that this was a very long post I wrote out. It took me a day to write. And that was after spending a lot of time preparing it: the last week starting and following a discussion on the foaf and swig mailing lists. That discussion was even a follow up on one started in January.
In any case perhaps we should call this the RDFAuth startandard project(s). A standard can only emerge through open discussion with different points of view put forward. This is what we should be able to start now since we have a client and a server. And some common ground.
I still think that having a token mechanism is unnecessarily complicated. I may be convinced of the contrary. Let's see.