OATH Token Identifier Specification
The OATH Token Identifier specification enables each authentication credential to be uniquely identified globally. Since different implementations of OATH tokens have very differing requirements (e.g. hardware token vs. embedded credential) we plan to develop a different ‘classes’ of compatible token identifier formats rather than a single format.
Requirements:
- We have identified the following key requirements for OATH token identifiers.
Should be user friendly – typically the user (end-user or helpdesk staff) needs to read the ID printed on the back of the device i.e. hardware token or in the case of software token displayed in the user interface and enter it for various lifecycle and administrative operations. - Namespace should enable unique IDs across vendors, possibly by reserving some bits/characters for a vendor code that is assigned by OATH.
- The solution should not require the Identifiers to be assigned in a sequential fashion.
- Namespace should be able to meet requirements for next 20 years. It should allow have a sufficiently big number of unique tokens.
- Namespace should be compatible with all the OATH authentication algorithms viz. HOTP, OCRA and TOTP.
- Namespace should be capable of handling large volumes anticipated with embedding (pre-provisioning) OATH credentials into mass market devices such as SIM cards, mobile phones, etc.
- Namespace should be able to support soft tokens. Soft tokens may have unique requirements because they can be generated by several different parties (enterprises) dynamically, in an environment that is not as controlled as hardware tokens.
It is challenging to support all the above requirements in a single token identifier format. For example, as hardware tokens get smaller in size, it is challenging to print any more that 12 characters on the back of the token in a reasonable font size. On the other hand if OATH credentials are pre-provisioned in mass market devices such as SIM cards you would need a larger namespace.
We struggled to come up with a single format that could support all of the above requirements and hence our approach of developing a ‘family’ of token identifier specifications.
Class A – OATH Token Identifier (for Hardware tokens)
This first class of OATH Token Identifiers has been designed primarily for identification of hardware tokens. As we discussed above, primary limitation for hardware tokens is on the length of the token identifier. This identifier is typically printed on the back of the device and the user typically needs to read the ID and enter it for various lifecycle events.
Based on discussions and feedback of OATH member companies, OATH Token Identifiers for hardware tokens should be 12 characters long and have the following format:
[MM][TT][UUUUUUUU], where:
MM OATH Manufacturer prefix (OMP) – a 2 character prefix, assigned by OATH. This prefix should be alphanumeric [A-Z,0-9].
List of currently registered manufacturer prefixes.
Register a new Manufacturer Prefix
TT Token Type (TT) , a 2 character token type, assigned by the manufacturer. This prefix should be alphanumeric [A-Z, 0-9].
UUUUUUUU Manufacturer Unique Identifier (MUI) – 8 alphanumeric characters that uniquely identify the token for a given manufacturer and token type. It is recommended that these 8 characters should be numeric [0-9] or hex [0-F].
To guarantee that these identifiers are globally unique, OATH will assign each token manufacturer a unique prefix. It will be the responsibility of the each manufacturer to ensure that for their prefix, each token is uniquely identified.
Example Token Identifiers:
AAV100000022, where AA is the Manufacturer prefix (OMP), V1 is token type (TT)
ALNG12341234, where AL is the OMP, NG is TT
VSMT00004CF1, where VS is the OMP, MT is TT
* Note that the Token Identifiers are case insensitive.
As mentioned above, this class of OATH Token Identifiers is primarily intended for hardware tokens. However, this format may also be used in other implementations – where embedded/software credentials are dynamically provisioned and the manufacturer can centrally manage the assignment of the token identifiers.
Class B – OATH Token Identifier (for Software tokens)
[This is work in progress]
Class C – OATH Token Identifier (for Embedded tokens)
[This is work in progress]