We need to take a fresh look at user identity and how electronic systems establish, validate, exchange, and trust identities as more and more transactions move to the Web, and the sensitivity of those transactions grows significantly. There are choices that need to be made about how a user is authenticated in a transaction that are separate from how the transaction itself is authenticated. We still see environments where “experts” are brought in to speak on user authentication, and they discuss PKI.  The business problem is associating the person with the electronic transaction – true user authentication.  What mechanisms can we use to associate an individual with an electronic transaction? There are many, and the required strength of the transaction is measured by the risk of the associated business process that will be performed electronically; however, PKI does not provide user authentication.

Many people do not understand how PKI works and, therefore, confuse the PKI infrastructure with user authentication.  PKI is an infrastructure of public and private keys used to validate an authentication transaction; it is not the authentication itself.  PKI was invented before the Web in the days when a person authenticated to a machine and then the machine passed the credentials and allowed verification.  A user would authenticate to a device using any number of mechanisms including username-password, card, token, or key fob, and then that device would release their certificate.  The certificate was the means by which the user’s identity was transferred to another user.  The recipient of the certificate could validate the certificate with a credentialing authority using the public key infrastructure and therefore have some level of certainty that the appropriate user was on the other end of the transaction.

When card-based PKI emerged, the certificate was retained on the card and stored in a cryptological memory repository.  The card provided the authentication mechanism; the “something I know” might be the password that releases the certificate from the card, which fulfills the “something I have”.  So the authentication is conducted with the card and the PKI certificate asserts the identity across the infrastructure according to the rules.  In browser-based certificates, the recipient assumes that the user sending the certificate authenticated to the machine that then released the certificate from the certificate store in the browser.  The authentication transaction with the machine may very well have been the Windows username and password.  The critical element of this discussion is that the certificate that is released can be released by any authentication transaction.  The key element of standards-based PKI implementations like the Federal Bridge is an agreement to a common set of standards for authentication that is asserted by the certificate and verifiable by the recipient.

There are instances when PKI can be used for authentication – it can be used to authenticate a machine to machine transaction without respect for the user. In this case, a user must still instantiate the certificate on the machine and create the trust relationship – which required a human authentication transaction of some type to receive the certificate and install it on the machine.  An example of such a transaction is provisioning a TLS connection between an application server and a Web server.