Posts tagged with: openid

Update: Dan Brickley suggested (in a private mail to Henry and me) that "RDFAuth" is most probably not a very smart name anyway, as something that contains official/generic technologies (RDF and oAuth in this case) may send wrong signals and cause misunderstanding. And that we shouldn't waste time fighting. He suggests more specific names (BeatnikAuth/knoweeAuth) for the time being, as this is all still premature stuff, and because no one should claim to have created an "RDFAuth", especially not if it isn't backed by the whole community. Well, what can I say, he's of course right. I apologize and will s/RDFAuth/knoweeAuth/ from now on.

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.

OK, enough geek whining ;), don't want to waste more time of my precious weekend.

Update: Dag Arneson gives some hints for OpenID server implementors on how to protect their scripts.

Update 2: Brad Choate of the Six Apart crowd informed me that OpenID server implementors are well aware of XSS possibilities. Platforms like Movable Type and Live Journal already use token mechanisms to make sure that received data were sent from a locally created form. I guess when the main server systems are protected, the mentioned security by obscurity effect kicks in again, I assume I could remove the 'shocking' from the blog title ;)

Update 3: The new Drupal versions also support optional form tokens. Blue sky again :) Disclaimer: I didn't spend time for a more detailed look at the OpenID 2.0 spec, maybe the problem is already addressed (I truly apologise in that case), but danbri suggested to blog it anyway. Here we go.

While working on a distributed identity system for my SemWeb CMS, I had a look at what's already out there. (This sentence is absolutely unnecessary, it's just an excuse for pushing it out with the Planet RDF feed). One of the most promising (and already deployed) approaches seems to be OpenID. OpenID's core idea is piggybacking on existing service providers which offer personal home- or profile pages for their users. OpenID provides "a way to prove that you own a URL (identity)".

There are of course a lot of security concerns which are apparently nicely addressed by letting users specify which services ("consumers") to accept, you never have to tell your password to a consumer, and the communication between the consumer and the server is even encrypted. This is all cool stuff, but I'm wondering if the security focus is on the wrong link in the chain. The weakest one not being the consumer or the user, but the home service.

As we recently learned, we must assume incompetent users (or, even worse, semantic ones), so when my service provider tells me that I'm now OpenID-enabled, and someone claims on his blog that [your favorite technology/toolkit here] is nothing but crap, of course I want to login and join the discussion! Oh, cool, the blog has simple instructions: "To post comments, please enter your OpenID". I'm logged in at LiveJournal, all I have to do now is to tell that idiot my homepage URL.

And here (finally) is my concern: When I tell the site my homepage URL, it's super easy to find my login name or user id for the most common services (e.g. LJ). Now the site knows

1. my user id or account name
2. the service/software I'm using (LJ, Drupal, Wordpress, ...)
3. that I'm currently logged in (otherwise, OpenID doesn't work)

As we know, none of the software packages used for online services is perfect. They are based on HTML forms which, when submitted, create blog posts, change profiles, add friends, etc. (In Drupal, for example, a single POST can be used to change your password, there is no need to verify the current one).

All the evil site has to do is to mimic a service form and submit it via a hidden iframe. The form will be submitted as if the user did it manually.

This is an interesting counter-example for two Web/IT principles: URI opacity and that Security by obscurity never works. The former isn't true for very successful sites (you could hardcode an exploit for LJ users only), the latter actually worked quite well in the last years, as it simply didn't make sense to secretly POST to a number of sites via an iframe, hoping to hit a service the current visitor is logged in to. With OpenID, though, we make things really simple for trap services.

As I said at the beginning, I don't know if the 2.0 spec addresses this issue. What we basically just need is something similar to a mobile phone's "plane mode" where you could log into your home service, but with limited functionality (e.g. "activate id services only").

Sorry, I deactivated comments. To protect you from spam. ;-)