FIDO Alliance – Fast Identity Online Overview/Nutshell

Session Topic: FIDO Alliance – Fast Identity On-line

Wednesday 2A

Convener:

Notes-taker(s): Brendon J Wilson

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Why is authentication important?

• Authentication is the ignition key to the cloud, applications. And like an ignition key, it needs to become a more seamless experience; currently a serious point of friction in everything you do online.
• Key problem is that world is incredibly heterogeneous (devices, platforms, operating system), and while certain systems have scaled (data, storage, compute power), authentication hasn't kept pace.
• JanRain study "47% of people would rather clean a toilet than pick another password"
• Ponemon study of data breaches re-examined the root cause of breaches, and it turns out that authentication failure was one of the major sources of data breaches.
• Ecosystems are inhibited from growth - without a simple, consistent authentication protocol, many of these new waves of applications won't be able to reach their ultimate success
• Tower of Babel: Problem is not that there aren't ways to perform strong authentication, the problem is that all the solutions are disparate. If you're a relying party, you currently have to maintain multiple pieces of authentication infrastructure, wiring to applications.
• Authentication metods aren't static in time - new methods coming around all the time, such as ARM/TrustZone, Intel IPT, Secure Element - again, reinforces the core problem for relying parties, namely the need to support multiple authentication mechanisms, with redundant infrastructure, redundant integrations into applications
• Full Ponemon study of user's desired authentication mechanisms available on noknok.com
• Authentication is only one part of the overall solution, part of a large identity stack: rIsk-based authentication stack, user provisioning, lifecycle management.
• There's a balance as well between explicit authentication / implicit authentication
• Motivations for deploying strong authentication
  • Regulatory requirements that demand the RP use a certain form of strong authentication
  • Managing business or reputation risk
  • Delivering ease of use for the experience to the end user
  • Note that authentication is a risk problem – don't always need to use the strongest risk
  • Whatever you deploy, you need to deploy authentication that is risk-appropriate, and business appropriate

What is FIDO?

• A standard to provide unified plumbing for strong authentication
• Network diagram of the typical FIDO solution - see the posted slides
• Protocol has three key pieces
  • Discovery: Figure out what capabilities are available on the user's device, and what capabilities for strong authentication are acceptable to the relying party
  • Provisioning: Local enrollment process that performs a setup of a public/private key protected by the authenticator (for example a fingerprint sensor); keys could be protected in hardware or software.
  • Authentication: Triggering authentication by providing a challenge, user authenticates locally to the device, unlocks the private key stored by the authentication device, signs the challenge
• Allows the relying party to determine which authentication method is appropriate for their requirements, as well as switch up between them as the user triggers functionality. Even "weaker" authentication methods are useful, as the RP can use to feed their risk engine, characterize the risk associated with use of a particular authenticator
• Answers to common questions:
  • How does this fit with the other components in the identity stack? Solely focused on authentication, complements other identity technologies such as SSO stacks (OAuth, OpenID, SAML)
  • How do I (the relying party) know that's really an XYZ class of device and not a software emulator? Uses a device attestation mechanism, ultimately can root this trust in hardware
  • How will this get adoption, enable solution to the true user problem? FIDO Alliance's work is not only focused on the technology, but also on bringing together the ecosystem of elements (hardware, software, browser, operating system) to enable a true solution – still early days.
  • What makes the FIDO Alliance different from other two-factor authentication approaches? Where are the boundaries of this protocol that will allow different authentication tokens, infrastructure, software vendors to interoperate and build different components of the solution. Boundaries are the protocol specification (to be published for public review later this year), the interfaces to the authenticators. Some elements of establishing trust will be managed by FIDO Alliance; whether it continues to be the anchor forevermore is an open question.
  • What is the ideal end state if FIDO is successful? Devices, software solutions that at FIDO-compliant - you use the device you have already to authenticate using its native capabilities to authenticate. Goal is unified plumbing for a variety of authentication methods, providing insulation for an RP as old authentication methods fall out of favor and new methods are invented.
  • Not all devices will necessarily support all potential modalities of authentication - doesn't make sense in the context of different devices
  • Who else has to come to the table to make this work? Browser, operating system vendors, relying parties are the people to bring together. FIDO Alliance doing the yeoman's work to bring together those players, get initial pilots with large RPs to build the momentum.
  • Where does this overlap with the efforts of federation protocols? Very complementary - essentially the first mile authentication is FIDO, second mile is federation via other protocols (OpenID, SAML, etc.)
  • What are you going to do about attestation infrastructure? FIDO Alliance is the organization will bootstrap the mechanism for verifying the genuine nature of the authenticator

Why a new organization?

• The focus is on bootstrapping a complete ecosystem - it's not just about a protocol - much broader scope than most traditional standards bodies
• As the protocols mature, there is a commitment to handing the protocols off to the IETF/W3C or similar organization - it's baked into the membership agreement
• Why does it cost to see spec? Won't cost to see implementation draft spec, we're not there yet. Initial membership fees focused on bootstrapping the organization and ecosystem.

See fidoalliance.org for more details