t3knomanser's Fustian Deposits

On the advice of Cory Doctorow over at BoingBoing, I checked out Dick Hardt's Identity 2.0 presentation. Interesting stuff, and something I've been thinking about meself- of course, I'm not getting paid to think about it, so I haven't devoted nearly as much concentrated effort to it.

All Internet security and Identity revolves around two steps- Authentication and Authorization. The first step- we must verify your identity. You approach a site like Livejournal, and you claim to be t3knomanser. You must authenticate that claim- which is handled here, and on most sites, by you providing a password that theoretically, only the real t3knomanser should know. Once you've done that, you'll attempt to post over in the community feminism, and that's where Authorization kicks in. t3knomanser isn't authorized to post there- he got himself banned for being purposefully inflammatory.

Now, there's a few issues with this, and the first one that sticks in my craw is a major issue in the Authentication process. Everywhere uses the traditional username/password combination. First off, we've got thousands of sites that we frequent. For simplicity, we tend to use the same combination on multiple sites, relying, not so much on the trust we might have in the webmasters of those sites, but more on the fact that we don't do anything important enough on the web for someone to bother. At most, it'd be frustrating to have our accounts comprimised. There's another part here though- we pick bad passwords. A password needs to memorable, I prefer them to be easy to type, though for passwords I want to be secure I tend to ignore that bit.

We put an incredible amount of trust in those silly 4-32 character strings.

Now, with an Identity 2.0 system, we introduce a single-point of access. Our credentials are stored on a remote server, we authenticate against that server, which then allows us to deliver all of our pertinent information to other sites in a single-sign-on basis. But how is that authentication being handled? This is the real issue, because we've got a single-point-of-failure.

There's no great answer, but this is one place where we can start looking at biometrics. Privacy advocates cringe the instant biometrics are brought up, and they're certainly not wonderfully secure. But biometrics in this scenario are a bit more desirable than they might otherwise be.

In a world of competing Identity companies, there's a very strong motivation to protect that data. The company that takes the best care of that data wins. Period.

To that end, the design for Identity 2.0 that wins will be the one that keeps the tightest hold on that data. For example, you go to access your favorite pr0n site. Age-check- must be 21 or over. How should this request be handled?

Well, your computer supplies an identity credential to the pr0n site. This credential includes a digitally signed user-identifier, as well as access instructions to hit your credential provider's web service. Via this web-service, the pr0n site runs a query: "Age >= 21". It is very important that the credential provider only offers these boolean checks, along with some security measures to prevent brute-force attacks to glean personal information (Age >= 21- false. Age >= 10 - true. Age >= 15 -true. Age >= 18 - true. Age >= 20 - false. Age >= 19 - false. Age then, is 18).

Now, Mr. Hardt talks about the failings of directory based services, but I personally see a value there- so long as these directories aren't closed silos. I envision the identity credential being a key to multiple directories. First, the Identity Provider has a directory containing verified information; age, sex, basic driver's lisence stuff. Each remote site builds a directory in a compatible schema, using the identity credential as a Primary Key to link that data to a specific user.

And here's the kicker- the remote site, say Amazon, notifies the Identity Provider that it's got this data, and the Identity Provider then subscribes to that data source, via a web service. The Identity Provider can then allow the user to provide authorization levels with different sites. Amazon wants to browse your eBay bidding habits to better tune their offerings to your taste- is this allowed? The whole thing becomes user centric, highly private- nobody but the user and authorized sites can access more information that the user allows.

And what keeps these companies playing above board? Competition. Never trust someone unless it's in their most selfish interests to be trustworthy. This is part of the reason that the .NET Passport flopped- despite Microsquish's strange devotion to it- there's not enough competition to ensure that Microsquish behaves itself. And the best part is, we're not just relying on an educated user base. All of the remote sites would have a stake in maintaining the trust in this system- so if an Identity Provider does anything remotely shady, what's going to happen when Amazon and eBay and Barnes and Noble decide to block Identities from that Provider? And this comeptition will be facilitated by open standards. By lowering the barrier of entry, and ensuring compatiblity between vendors, we can guarantee that anyone with a decent developer team can become an Identity Provider with custom software- the only hard part will be developing the trust of remote sites so that they accept your identities.