There is a great deal of interest when delivering digital public services to leverage a strong token, ideally one that has already been obtained by or issued to an individual, across multiple relying parties. This blog post identifies some of the challenges to overcome to enable a true bring-your-own-token experience.
At the end of the road, some specific things need to be in place in order for an RP to be able to use a token it has not issued:
- RP needs confidence in the strength/quality of the token
- RP needs confidence in the uniqueness of the token
- RP needs the ability to authenticate the token
There is more, but let us start with the three above. Please note that I am deliberately making the linking/binding of the token to a specific identity a follow-on step, and out-of-scope for this particular discussion.
However magical everything else turns out to be from the perspective of the CSP or the RP, if the User Experience (UX) of the individual in how they register the token at the RP is not friction-free, and does not scale, stop! Invest in addressing this issue before moving forward!
Moving on, confidence in the strength/quality of a token is based on an analysis of ‘acceptable’ token types, and a follow-on attestation that a particular token falls into one of the accepted token type buckets. NIST has done such an analysis in SP-800-63 , and so have other jurisdictions.
The true challenge here is related to the initial token registration at the RP which requires that the RP have confidence that the token identifier is unique, and that it has access to a mechanism that will authenticate the token.
I would argue that this is a hard problem that the community has circumvented by centralizing this capability in CSPs or Token Managers who ensure that uniqueness is managed for the tokens they issue, and offer an authentication service for their tokens. And this approach exists in both the public sector (Canada’s GCKey Infrastructure or New Zealand’s RealMe Login Infrastructure) and in the private sector.
It works, but this is not a true bring-your-own-token (BYOT) experience. It is a minimize-the-number-of-providers approach rather than a portable token approach which fosters a ‘bring a token from a provider the RP has done an integration with’ experience.
On the other hand, this is a problem that is much more tractable for a second factor, especially if that second factor token supports the Initiative for Open Authentication (OATH) HOTP per RFC 4226 or TOTP per RFC 6238. e.g. Google Authenticator
But even there, there are nuances that impact portability, because when dealing with an OATH based token you are not associating a token identifier to an account at the RP, but are instead associating an existing account identifier at the RP to the OATH token generator. (otpauth://totp/company:userid?secret=AFDFDD&issuer=company)
The potential game changer in the portable second factor token market is the FIDO Alliance’s U2F specification. The concept of the Key Handle, which is a pair-wise identifier between the U2F device and the RP which is created at registration, and the ability to convey who the vendor of the token is via the use of an attestation key-pair is brilliant.
So to answer the question, I REALLY want one! But if you place as the highest priority the ease of token registration UX at the RP and internet scalability, I do not believe that there is a portable token in the current marketplace that can be used as the first factor in an authentication. Some will consider that a provocative statement. For the record, I want to be proven wrong here.
BTW, I placed a premium on the UX given its importance for digital public services, and while ‘PKI Hardware Token’ may be a potential answer, it is not a path to internet scale success.
Question: Do you believe that the FIDO Alliance’s Universal Authentication Framework (UAF) provides a way forward for portable tokens?
- NIST SP-800-63-1 Multi-Token Assurance Level Matrix
- Public Sector Identity Assurance Guidelines and Standards
- Government of Canada GCKey
- Government of New Zealand RealMe
- Google Authenticator
- FIDO Alliance Specifications
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.