- It requires end users to have a web server with HTTPS available
- It requires an agent mediating identity
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
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"
- 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
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
- Spam bait
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
Mike Warot - July 2005