My 2 Cents about ID

Doc points to Passel as yet another possible solution to the big identity problem we all face. I reviewed it, and found it to be lacking for a few simple reasons.

• It requires end users to have a web server with HTTPS available
• It requires an agent mediating identity

Those two items are both deal breakers in my book. I have no "secure" web servers at work, nor elsewhere available to me at present. I'm also unwilling to install yet another layer of code between myself and the internet.

I followed the links, found other projects, including OpenID, which gets closer to home for me, but still misses the mark. I found it lacking for one very simple reason:

• It doesn't let the user authenticate outside the current browser session

We've all been taught not to trust any URL which we didn't provide ourselves. How can a reasonable paranoid end user trust that their browser isn't being spoofed with a redirected URL that looks just like their home Identity server? they can't!

All in all, I'm picky, or just good at spotting problems, or a perfectionist, or all or none of the above... he said equivically... ;-)


What do I think would make a good identity system? Here's my scenario:

• Web site needs identity
• User presents a URL pointing to their ID server
• Web site requests validation of identity, while asserting it's own identity
• ID server returns "approval pending"

At this point anywhere from a millisecond to a year passes, depending on the whims of the user.

• Independent of the above, the end user opens up a session with their ID server
• the ID server shows the pending requests for validation, along with it's own checks to make sure the requests are from valid sources
• the end user approves the validations, and optionally makes choices about the disclosure of additional data (instead of filling out yet another registration page)
• the ID server may provide a link to go to the site in question, or the user may return there as a continuation of the above session, depending on circumstances.
• the end user reloads the page on the web site, causing it to re-request validation, this time getting the proper response, and any additional data about the user
• assertion of ID has been validated, normal useage ensues
  

Why do I do it this way? Experience has shown that phishing is on the rise, and you just can't trust any parameters provided by others without some level of verification.

It's obvious to me that relying on the end user to initiate a separate sequence of events is a burden. The lowest cost method available is to simply use the browser in a separate session, probably via a BookMark. Even this step might be optimized over time by being built into the browser, if some form of federated ID becomes the defacto standard.

The benefit of this wall of separation is that even the most paranoid (experienced) end user can have a fair degree of trust in the confidentialtity of the interaction with their ID server. It is the trust and the low cost which I think makes this the model which will win in the end.

Once we have federated ID, things get really cool, really quick... here's a example:

• A read a cool item on Slashdot, which links to story I want to read elsewhere
• The Web server hosting the story requires registration or an ID
• I give it my URL
• it requests validation... and is told to try back
• I go to my ID server, and see the results of the request... they want an address, phone, etc...
• I decide to validate the request, and also to provide the other data.
  
• I then switch back to the Web site and reload, cause it to request the valition
• It accepts the validation, and the extra data
  
• I get what I want, the story in question

Now, there are subtle variations of this story, one of which would make my ID server cool which would be to be able to choose which set of addresses to provide:

• Work
• Home
• Spam bait

I'd get to decide which on a case by case basis. The other way of doing this is to have more than one ID to present... which is a tradeoff for the end user.

The cost and complexity of getting the ID servers up and running will be taken care of by us, we'll probably optimize it along these lines:

• open source
• multiple competing implementations (exploring the solution space)
• organic addition of features
• hard to set up
• easy for the end user (if we're smart)
• fading into the infrastructure over time

Well, that's the way I see this ball rolling. It looks like it'll be a fun ride.

Mike Warot - July 2005