Category: web 2.0

Well, I was very excited to see that some people have created some pretty reasonable protocols to define what your ‘identity’ is in this whacky, Web 2.0 world we live in. Unfortunately, they botched. The protocols they define are based upon identifying yourself with a URL – giving the protocols near-complete decentralization. Yay! Except people aren’t URL’s. The closest thing they are is email addresses. Boo! Furthermore, the protocol adds lots of complexity in terms of what information you share or don’t share, etc. Signing up for an identity being completely separated from using your (completely separate) identity somewhere else. And the most damning thing, is that sites that use openid still retain their old username/password boxes from before. Yuck. Why wouldn’t they migrate everyone over? Because it can’t be done. Ugh.

So I was thinking about a radically simpler solution.

Here’s what I came up with:

#1) Guy gets to website he’s never been to before. He’s never used our system before either. He wants to do something that would require some kind of ‘identify yourself!’ thing. Maybe posting to a blog, maybe editing a Wiki article.
#2) The login thingee says ’email:’ and our guy puts in his email and clicks a button or something.
#3) The system emails him a big long ugly URL. Or maybe a short-and-sweet case-sensitive one. He clicks it.
#4) New window pops up saying, “OK, your info thingee has been validated or whatever. You may close this window”.
#5) He is done. He may even stay validated for another 30 minutes (hour? 2 hour?) or so so he can repeat this several times. On several different sites.

Let’s see what happens if he does go to another site –
#1) Guy now goes to somewhere else. He tries to do something else which requires identification.
#2) Login thingee says ’email’ which he puts in – or his browser auto-fills.
#3) A window pops up saying, “OK, you’ve already been authenticated as bobo@agladsfhlkyewiutykxjcnkjwheriwuehf.fromple, click here to use that identity on this site”
#4) User clicks. Is done.

Now if our user finds that this type of thing is happening to him all the time, he may get encouraged to ‘register’ so he can just has to put in a password to be identified. This encouragement might happen around step #3 above, once the dude has used this system a few times. There, instead of the email going out, a login screen would show up. He could log in, and be so identified for so long.

There! How’s that? Simple enough for ya!? OK, that’s how it acts, here’s how it should work.

When the user clicks the Login button it gets posted to my server. If his email address has never been seen before, it just sends him an email. Maybe after asking him questions like name or something. Maybe you can choose to make a password there too. When the user clicks on the URL he was emailed, he’s proven ownership of the email address, and a cookie is set on his machine, pointing to my domain. Probably set with a time limit or something. The page somehow gets magically redirected to where he was going.

The second time this happens the system has seen your email address before – it should consider asking you, “Hey, this keeps happening to you, do you want to set a password and use that instead?” If you’ve set a password, then you get a password prompt instead. Success implies cookie and redirection to wherever you were going.

Subsequent authentication attempts will still post to my site, but then your cookie will be detected, and you’ll just get a “OK, you want to auth to this site?” thing.

At some point something complicated will have to happen to inform the original site that you are, indeed, who you say you are. Ah! When you get redirected back, the original site gets URL parameters appended saying – here’s the dude, here’s a crypto hashey thing. Ah! You specify a ‘nonce’ thingee in your form which posts to me, upon return I hash the nonce, the date/time, your site URL, and your mother’s maiden name together into a big ugly base-64 thing which you are obligated to decipher. Hell, with the date/time, you can skip the noncery I think. Oh, no, you need it so people can’t just hash up gibberish and have you believe it.

You want the system to be super-duper simple, but not start forking over the dude’s identity willy-nilly.

So – I guess when you’re signing up, you can put in things like Full Name, city, etc – and maybe set certain things as private or public…?

Anyways, this version has these advantages –

#1) No differentiation is made between a ‘consumer’ and a ‘server’ – any site which uses this auth method can implicitly sign people on.

#2) People are E-Mail addresses.

#3) Minimal to nearly no commitment required on the user’s part – you don’t have to make much of an account, or anything.

#4) Easy(ish) to implement.

With the obvious disadvantage –

#1) No longer decentralized. But we’re not talking about lots of data here, it would be possible to scale a centralized identity service up.

#2) Phishing attacks – no more or less so than openid, but you still could find yourself a victim of a phishing attack with this system.

Edit – I found the idea for this stupid thing so simple and compelling that I just built it. It’s still in the conceptual/prototype stages right now, and I wouldn’t use it to secure anything I really deeply cared about just yet, but it’s there so you can look at it. It’s very early yet. Just look and think and stuff, don’t whine yet:

Desk.nu – Your new…desk…to be…uh…working on. Or something.