Fast Identity Online (FIDO) Alliance leadership shows commendable clarity and focus in continuing to address a narrow problem set (authentication), without becoming distracted and giving into scope and mission creep.
FIDO breaks down the authentication interaction into a person, a client (mobile device, desktop etc.) used by the person, and the digital service the person wants to interact with.
It standardizes the API between the authentication token (biometric, PIN etc.) and the client, and the API used to communicate between the client and the digital service - while leaving room for innovation and flexibility in the tokens used, and the type of services that can be offered.
The varied set of folks who have jumped on board is a testament to the focus and fine line being walked by the organization.
The challenge for FIDO (as articulated by a knowledgeable friend) is its dependency on hardware authentication token manufacturers:
These folks have not been all that successful at coming up with solutions that normal humans find easy to use and subsequently adopt - being FIDO compliant is not a motivator for non-security people.
If a hardware manufacturer does come up with a solution that is easy and is adopted by many, do they need FIDO since they already have traction?
You only have to look at Apple and Touch ID to see this question being asked and answered - Apple is silent on FIDO. In fairness, Apple may simply be behaving like Apple when it comes to technology adoption.
On the other hand, if industry leading the way is truly important, this looks to be a good opportunity for the authentication token portions of the NIST Personal Identity Verification (PIV) specifications and the FIDO specifications to play nice together.
Fear driving outcomes
When you let lawyers drive the bus of business and program outcomes, instead of making them get out and push, don't expect much progress.
Nowhere is the desire to re-invent the wheel combined with the inability to learn from the past more present than the area of identity federation and liability. As in all things, there are those rare exceptions.
++ The "mutually hold harmless" arrangement for resulting damages agreed to by the U.S Federal Public Key Infrastructure Authority and Wells Fargo.
- I believe similar language also ended up in GSA's un-successful eAuthentication initiative. The failure of that program had nothing to do with liability and its lessons have been pretty much ignored by those looking to the future.
++ The recent Virginia digital identity bill
If the identity service conforms to the rules-of-the-road as defined by a federation operator (e.g. a trust framework) they are not liable. But if they are negligent they can be liable.
A clear separation and the associated liability allocations between the issuance of the credential, which the identity service has control over, and the use of the credential by a customer which it does not.
cyberforge: random and relevant
++ NIST is soliciting comments on SP 800-63-2, Electronic Authentication Guideline. Comments are due by May 22, 2015.
++ Lovely and concise description of why the blockchain is important.
- Crunchy on the outside, chewy on the inside: "It's been a very powerful attack, because we have very strong firewalls which had been checked -- and that had been checked very recently -- and were said to be very safe, [...] So obviously it's a very knowledgeable and powerful cyberattack."