Late Binding Token
Full Title or Meme
There are two broad classifications of Late Binding Tokens.
- User held key fobs that have very limited functionality other than to carry a private key (aka user Credential and the ability to sign or decrypt hashes.
- User held mobile devices like Smart Phones that come with a built in Trusted Execution Environment that can perform the same function.
One rather interesting cross-over use of the Smart Phone as the source of trusted authentication replacing the user held key fobs is described in this use of Android phones as the second factor. "On Chrome OS, macOS, and Windows 10 devices, we leverage the Chrome browser to communicate with your Android phone’s built-in security key over Bluetooth using FIDO’s CTAP2 protocol. On iOS devices, Google’s Smart Lock app is leveraged in place of the browser."
There are a few problems that need to be mitigated with Late Binding Tokens.
- The Relying Party must be assured that the device is legitimate and did create the message that was sent from the user to validate an interchange.
- The user would like to be able to use one token to secure message interchanges with more than one service so they don't get asked to carry multiple tokens.
- Some services want to be assured that the user was present during any interchange. This feature is not available with all tokens.
The exact form of the Late Binding Token is widely variable from Smart Cards to TPM buried inside of a Smart Phone or other computing device. Existing solutions tend to be bound only to a single service provider, they would not be considered to be Late Binding Tokens. The two most common implementations are:
- Portable key fob that can interface to a variety of devices with USB or Bluetooth protocols. Most often these use FIDO U2F or Web Authentication protocols.
- Portable devices that contain a Trusted Execution Environment within them, often in the form of a TPM.