FIDO2.0概述

问题和目标

今天的认证技术在互联网规模上有很多众所周知的缺点。用户的身份验证体验非常分散，令人焦虑。用户必须多次对不同实体进行身份验证，包括本地设备和各种在线服务，如电子邮件和银行。每一种体验都是不同的，有不同的故障模式。密码是目前最常用的认证方法，它有许多与力量、管理和妥协有关的问题。

越来越多的人一致认为，这个行业需要发展成一个更好的认证模式。FIDO 2规范定义了一个强大的身份验证架构，并考虑到以下目标：它必须是不受影响的。认证方法必须抵制网络钓鱼攻击。安全对服务器入室盗窃。

今天的许多密码妥协来自服务器端攻击，其中大量的密码或密码哈希被暴露出来。Machine-bound身份验证和授权。不可能从一台机器上获取身份和服务的Ticket，并在不同的机器上使用它们。这提高了恶意软件的门槛，因为恶意软件现在必须留在受害者机器上，以便使用任何捕获的Ticket。它必须提供一个加密证明，即所使用证件的性质。与密码相比，它必须提高可用性，必须允许基于客户端平台和认证的力量进行区分。

具体来说，虽然所有平台都必须能够达到有意义的强度，但应该有可能支持RP的策略需要特定客户端平台或更高的认证强度以实现场景的场景。保护用户的隐私:用户有各种在线身份。解决方案必须在这些身份之间提供隔离，不允许依赖各方或身份提供者将它们联系在一起。它必须需要一个用户手势来执行用户身份验证操作。

FIDO2.0 概述

一个核心用例是用户在移动设备(身份验证器)上显示一个手势，想要登录到一个平台设备(比如笔记本电脑、平板电脑等)。另一个核心用例是用户希望使用内置的身份验证器登录到相同的设备——即身份验证器设备和主机设备是相同的。假设登录在定义api的web页面上，以执行清晰。

为了解决这些用例，我们需要一个用于强身份验证的web API和一个强大的身份验证协议的内部设备协议，该协议规定当web API调用主机时，主机和身份验证器之间会发生什么。

有了这个背景，按照这个顺序阅读下面的规范：

FIDO Web API

定义一个web API，允许web页面通过浏览器Javascript访问强大的密码凭证。为了简化开发人员的采用，它的目标是在可能的情况下重用现有的web规范，与现有的web平台进行良好的集成；

定义如何使用WebCrypto api允许web页面通过浏览器JavaScript访问强大的凭据。它试图遵循WebCrypto规范的精神，同时也很容易为开发人员使用。因为它指定了浏览器的功能，为了让它被广泛采用，这个功能的某些方面需要在W3C中开发。

FIDO Client To Authenticator Protocol

定义了一种应用程序层协议，用于在个人设备与加密功能之间进行通信，以及希望使用这些功能进行强大用户身份验证的主机计算机。该协议可以使用不同的物理介质来运行各种传输协议。该规范定义了这种传输协议的需求，但没有详细说明应该如何设置传输层连接的细节；

描述一种设备与设备之间的通信协议，用于在个人设备和主机之间进行通信，并希望使用这些功能来实现安全功能，包括强大的用户身份验证。

这个协议的目的是在用户与一个依赖于某个平台(例如PC)的依赖方(如PC)进行交互的场景中使用，它提示用户与外部认证器(如智能手机)进行交互。为了提供用户交互的证据，实现此协议的外部验证器将有一个获得用户手势的机制。用户手势的可能例子包括:作为同意按钮、密码、PIN、生物特征或这些。在执行此协议之前，客户端/平台(被称为主机)和外部验证器(以下简称验证器)必须建立一个机密的和相互验证的数据传输通道。该规范没有指定如何建立这样一个通道的细节，也没有指定如何实现传输层安全性。

平台与认证器之间的一般协议如下:
1、平台建立与认证器的连接。
2、平台使用authenticatorGetInfo命令获取关于authenticator的信息，该命令帮助它确定认证器的功能。
3、项目如果身份验证器能够支持该操作，平台将发送一个操作命令。
4、身份验证者用响应数据或错误回答。

此文档指定外部FIDO 2.0认证器的所有三个部分：

Authenticator API-在这种抽象级别上，每个身份验证器操作的定义类似于API调用——它接受输入参数并返回输出或错误代码。注意，这个API级别是概念性的，不代表实际的API。实际的api将由每个实现平台提供。

authenticator API中的每个操作都可以独立于其他操作执行，所有操作都是异步的。身份验证器可能会对未执行的操作执行限制，以限制资源的使用——在这种情况下，验证器将会返回繁忙状态，而主机预计稍后将重试操作。
此外，该协议没有强制执行或可靠地交付请求和响应;如果需要这些属性，则必须由底层传输协议提供，或者由应用程序在更高层次上实现。注意，这个API级别是概念性的，不代表实际的API。实际的api将由每个实现平台提供。

Transport-specific Binding-请求和响应被传送到外部验证器而不是特定的传输(例如，USB,NFC，蓝牙)。对于每种传输技术，都为该协议指定了消息绑定。

Message Encoding-为了在authenticator API中调用一个方法，主机必须构造和编码请求，并将其发送给经过选择的传输协议的authenticator。然后，authenticator将处理请求并返回一个已编码的响应。