Monday, June 23, 2003
More on authentication
I didn't get the chance on Sunday to complete the set of authentication ideas that I'd kicked around, so here are some others: - Cross checks with other entities. I spent a lot of time with a well-known credit checking agency (who put in an equally large amount of time and enthusiasm) to see if we could come up with something where they would provide the "challenge questions" to ascertain identity. Answering the questions online would give a probability that the person was who they said they were - beat x% (80? 90?) and you'd be allowed in. This could have given instant access to an application, provided we were sure the questions didn't cover too many publicly available data points (but they'd certainly have beaten "what's your mother's maiden name?" and "what's your date of birth?" which is all I ever seem to get asked offline. Of course, it would only work for those with credit records or who are on the electoral roll. - Dynamic government questions. Similar to the last one, but using government databases to come up with random questions - how much did you pay in your last tax bill, what was your salary in June 2002, etc. Very feasible, but probably difficult for the user (after all, do you know how much you paid in tax? And if you don't, how long would it take you to find the bit of paper where it's written?). Bound to be painful. - Mobile phone. For a while, sometime in early 2002, I floated the idea of using the mobile phone as a portable identification token. This was driven by a long held view that certificates wouldn't make it (they don't, for instance, work on digital TVs) and that the only widely available thing that had some kind of link to who you are was the phone. The idea was that when you transacted online, we'd send a text to your mobile saying "was that you who did this?", and you'd reply with a confirmation PIN. This idea went back and forth with all the mobile operators, many of whom were keen to work something out, but it was harpooned by the understanding that 70% of mobile phones are pay as you go - so they don't link to who you really are (we couldn't check, say, your address with the mobile company). To establish that link, we'd have to get people to go back to the mobile store and register their phones - something that I figured people with pay as you go wouldn't want to do. The debate came alive again when one of the operators hinted about the idea of a SIM card refresh to provide digital certificates in the phone ... but that's gone away too now. In reality we're going to need something pretty soon. I'm not convinced that Liberty or Passport hold the keys to where we need to be - they're not yet focused on the same thing as we are in government. Some people ask why we need one token for many services - and where the services are all point to point (e.g. you send your tax return to the Inland Revenue) there's some validity in questioning it. Once you move to joined up services (and we WILL), though, the need for a single ID that links multiple departmental services is going to be essential - if earning more money (or less for that matter) affects your tax credits, say, then it makes sense to handle this as a single update. And, without a single interlinked database of all government identifiers, the only practical way to do this is through a joined up system like the government gateway. Not everyone in government buys that yet, but over time I'm confident it will become more obvious, as soon as people stop trying to find reasons why not to use it and start looking for how to exploit what it already does.
Posted by Alan at Monday, June 23, 2003