The concept of a single security gateway for authenticating users of e-government services might seem straightforward, but the reality of assembling such a beast can be pretty complex. Here are a few issues the e-Authentication project teams might face:
Component interoperability. A registration authority from one vendor, smart card from another vendor and certificate authority from a third company often just don’t play together. “Some of the standards were never completely agreed on by the important vendors, other standards are very complex. There are details that can go wrong,” says Daniel Blum, an analyst with The Burton Group Corp. and a Network World (U.S.) columnist.
Application integration. It’s a Catch-22: There hasn’t been great incentive to adopt public-key infrastructure because few applications have been integrated with PKI – and because PKI adoption is low, few developers have done the work required to build complex PKI support into their applications.
Policy interoperability. The whole government hasn’t agreed on a common policy classification scheme, so it might be that what the Air Force considers sensitive and what the Internal Revenue Service considers sensitive and what General Services Administration considers sensitive are three different things.
Scalability. Entities such as the Federal Bridge Certificate Authority (a trust clearinghouse that handles interoperability among federal agency PKI domains) have been running in pilot mode and therefore don’t have the infrastructure to handle millions or billions of transactions per day – which is what the infrastructure might have to deal with if the government starts enabling widespread PKI. To set up such a huge infrastructure will take lots of time and money, Blum says. “Realistically they’ll probably do something like crawl, walk, run. But right now they’re barely crawling,” he says.
Product pool. Choosing vendors with staying power is key. Many of the small companies that provide PKI products have been hammered by the poor economy.