Identity substitutes, tokens and proxies

We frequently use proxies for identity when the real thing is difficult, inconvenient, or unnecessary to validate. This applies especially in the realm of authentication, as the only true identity based authentication technologies available are biometric. Everything else is an approximation of identity validation to some acceptable degree of risk or certainty. So we often authenticate the identity of one or more things and use the result as an identity proxy or substitute.

Luckily, we don't often really need actual identity validated to authorize access or to allow a transaction to proceed. What we need is reasonable assurance that whoever is attempting the access or transaction is an authorized party. This means that identity substitutes or proxies not only suffice, they can often create a superior user experience.

To illustrate, let's follow a mythical person we'll call Adrian as he starts his day to see how identity and identity proxies are used to create his "user experiences" and enable his desired outcomes. Adrian recently received a promotion at work, and bought a brand new 2007 model luxury car to celebrate. We join him as he begins his morning trip to work...

Adrian's new car doesn't have a "car key" but rather has an RFID encrypted, rolling code "fob". In fact, his wife also has a fob for their shared car which has a different code. Adrian walks out to his car, and as his hand reaches for the door handle a proximity sensor recognizes he's trying to open the door. The car's computer has already authenticated the RFID code from the fob in his pocket, so the car beeps gently and the door opens when Adrian pulls the handle -- as though it were never locked. At the same time, the seats and mirrors are repositioned for Adrian from the settings his wife used when she drove the car last night. And the many anti-theft lock down chips that make the car impossible to hot-wire are electronically disabled.

Adrian buckles his seat belt and presses the large start/stop button on the dash. The car starts, and he pulls out to begin his drive to the office. Realizing he needs some cash, Adrian stops at an ATM on the way. He puts his ATM card and personal PIN into the ATM, enters some commands, and fresh $20 bills are dispensed along with a receipt indicating the remaining balance in his bank account.

Adrian resumes his drive, but as he passes the donut shop, decides he needs some sugar and caffeine to get his day going. He pulls in and gets out of his car -- pressing a small button in the handle as he does so. The car responds with two beeps, meaning it is "locked down tight". Adrian enters the donut shop and buys a donut and some coffee, handing one of his fresh $20 bills across the counter to pay for it. He receives his change, puts it in his pocket, and returns to his car. Again, the car authenticates his RFID fob, senses as his hand reaches for the door handle, and by the time Adrian pulls the handle the door opens like it was never locked. He enters, presses the START button and resumes his drive to the office.

Part of Adrian's route to work has him driving on a toll road. As he drives through the toll booth area, his RFID EZ-PASS is read, and a photo is taken of his license plate. The toll is automatically billed to the credit card Adrian has left on file with the toll road authority and Adrian doesn't need to even slow down.

Adrian finally arrives at the office. Entering the parking garage, he holds holds his smartcard ID badge over the sensor and the gate opens. He pulls into his parking space and leaves his car, pressing the button in the handle to lock it. As he walks into the building, Adrian again presents his ID badge at the door. It is read and he is passed through into the controlled access facility where he works.

Sitting down at his desk, Adrian turns on his laptop. When it has powered up, Adrian swipes his finger on the keyboard's fingerprint sensor, and is logged into both the computer (which will now use its Trusted Computing TPM chip to encrypt and decrypt his local files) and also onto the company network. He brings up the employee portal, clicking on the entry to his 401k account to check his account status. The company has federated identity with the 401k provider, so Adrian's user experience remains seamless.

I could go on with this example, but there is plenty here to make the points I'm after. The first point is to note that while many identity based transactions have taken place requiring both authentication and authorization, and having financial and liability consequences, rarely has Adrian's actual identity been verified. In the case of his car, a very difficult to forge RFID highly encrypted one time password token was verified. Its bearer was presumed to be Adrian and was authorized to use the vehicle.

In the case of the ATM machine, we again note that a specific token (the ATM card) was authenticated, and the bearer of that token was authorized to debit Adrian's account if they also knew the 4 digit PIN that was bound to the card and account. It was assumed that anyone possessing both the token and the shared secret was at least an authorized agent of Adrian, if not Adrian himself. Authorized enough that Adrian wouldn't mind them taking his money.

At the donut shop, Adrian presented a self-authenticating token in the form of a $20 bill. The shop attendant may have done deep authentication if that was the shop's policy, submitting the token ($20 bill) to a variety of anti-counterfeit tests to authenticate the token before allowing the transaction to occur. The token carries a third party's (the government's) promise to pay it's bearer $20 if it is authenticated.

The RFID toll road transaction authenticated the EZ-PASS token and also the vehicle that the EZ_PASS was assigned to. It did this by reading the license plate number - yet another token. The presumption here was that anyone who had been authorized to drive the vehicle, was also authorized to charge the toll to Adrian's credit card. The credit card transaction between the toll authority and the credit card company involves even more tokens and identity proxies which we won't directly consider here.

Of all the identity authentications and authorizations in this example, only the fingerprint sensor used by Adrian to log into his computer actually authenticated Adrian's identity. Every other transaction used an identity proxy to authorize and allow the transaction to occur. While those authorizations presumed they were authorizing Adrian (or in some cases a third party such as a government document, toll authority or credit card company, etc.), they all carried some degree of risk that things were being spoofed in some way and that this wasn't so. In many cases they also intentionally contemplated that Adrian might assign agency to bind him in one or more of these transactions to someone else and that this wouldn't matter to the transaction being authorized (for example handing his RFID car fob to a valet attendant to park the car.)

When we talk about identity it is important to realize when an actual identity has been authenticated and when that authentication has been approximated or inferred by authenticating something indirectly associated with an identity.

The other thing I would like to call attention to in this example is how in each case the method of authentication has been chosen to create a user experience that people will not only accept but actually seek out and embrace. The RFID tokens, the contactless smart card ID badge, newer self-authenticating hard to counterfeit forms of cash, and the fingerprint logon in this scenario combine great protection against misuse of data or equipment with tremendous ease of use. That authentication must enable the desired user experience (and not suppress it) is something that is coming to be far better understood in the last year or so as regulations force more authenticated transactions to begin extending to the public at large.

It is this combination of user experience and strength of authentication that will allow the release of value in ever more networked settings. Just driving to work Adrian was served by a network of several companies and government departments networked by technology that didn't exist a decade ago. Twenty years ago the above scenario would have sounded like science fiction, today it is reality.

Identity technology combined with the global internet and the increasing networking of business processes is about to open the door to many, many more such "user friendly" and "user productivity enhancing" scenarios than we can currently imagine. They are not very far in the future at all and understanding identity will be essential to enabling them.