Network Computingwww.networkcomputing.com

Print this Page E-mail this URL   XML: Revenge of the Nerds, April 5, 1999   XML: An API for Every Web Site, May 3, 1999   Understanding Internet Payment Protocols, Workshops, May 3, 1999   Searching for Online Customer Service, May 31, 1999   Microsoft Won't Kill XML, June 28, 1999

Sound easy? It's not. While server certificates are common because SSL insists upon them, client certificates have languished because they're optional. It's shameful how rarely we use client certificates, given that they're standard and browsers have supported them for years. As a result, the user ID process has become convoluted, relying on constant cooperation from users and vigilance from site designers. While consumers can shop anonymously, they often choose--or are convinced via coercion or incentive--to register. We've traded a single dose of complexity during browser setup for a constant stream of user IDs, passwords and cookies.

Enterprises and ISPs typically deal with applications requiring strong authentication, such as storefront administration, by creating "out-of-band" solutions for secure access. This assumes both user population control (by forcing users to employ a particular authentication device) and responsibility for maintaining the secure out-of-band communication. Client certificates are a more elegant solution.

In addition to the standardization of the protocols provided by x.509 and SSL, vendors have offered decent tools at the higher layers. At April's Internet Security Conference in San Jose, Network Computing and CyberSafe cobbled together a demo that illustrated the use of client authentication in an e-commerce application. We used NT, IIS and Intershop to create the prototypical e-commerce site. Our demo aimed to show that strong client-side authentication is secure and reliable for practical enterprisewide deployment. We wanted all "store administrators" to authenticate via a CyberSafe-provided client certificate.

We mapped certificates to users via Microsoft's IIS. Its ASP scripting provides a Request.ClientCertificate object making it easy for any programmer to retrieve information about the certificate. On your (intranet) site, if appropriate, you could map certificates to user accounts and eliminate some coding. Supporting client certificates in your application isn't rocket science and shouldn't take much time or many tools.

Using client certificates requires a few changes in orientation from e-commerce packages. In today's status quo, we've separated user ID and the establishment of a secure communications channel. These two operations belong in one function that should occur when someone enters a site.

Soon, client-side authentication will become as commonplace for e-commerce as server-side authentication is today. And it will succeed for the same reasons server certificates have--standardized implementations and competitive service. But it will fail without the support that accompanied the introduction of SSL for e-commerce. Unless a site insists on client certificates for access, or provides an incentive for presenting one, no one will ever bother with client certificates.

Send your comments on this column to Brian Walsh at bwalsh@nwc.com.