关于FIDO2，CTAP2和WebAuthn
在Identity Standards工作的这一周是十分荣幸的，因为我们在微软庆祝我们发布第一个WebAuthn依赖方。这一依赖方（Relying Partiy）在Xbox，Skype和Outlook.com等基础上都实现了标准化的无密码身份验证。但是什么是这次实现中难点的真实部分？他们又是怎么适配的？请继续阅读，了解W3C WebAuthn是如何与FIDO2 CATP2规范进行交互的。我们将从行业标准的角度出发，并且在最后我们将总结微软是如何让他们生效的。为了理解FIDO2认证是如何工作的，你需要了解两个不同标准体系中的两个规范相关的知识。Web身份认证（WebAuthn）的规范在W3C（浏览器支持）查阅，此外，Client-to-Authenticator（CTAP2）的规范可以参见FIDO Alliance（一个从事硬件和平台相关的人都加入进来，为了解决在线快速认证的问题）。
整体情况
CTAP2和WebAuthn定义了一个抽象层，这个抽象层可以为强认证凭据构建一个生态系统。运行给定的“客户端设备”上的任何可交互客户端都可以使用一个标准化模式与任何可交互的身份验证设备进行交互——这也许意味着平台认证设备（Platform Authenticator）可以被内置在客户端设备或者漫游认证设备（Roaming Authenticator）中，而这些设备也可以通过USB、BLE或者NFC方式连接到客户端设备。在用户必须通过使用“用户手势（User Gesture）”这一行为来同意某一操作的条件下，验证设备就可以安全地创建并本地存储强加密密钥。一旦这些客户端限定的密钥被创建，那么就可以请求认证（attestation）并将其发送给客户端以进行注册和认证（authentication）。另一方面，用户手势则由私钥执行的签名类型进行映射。
我们绘制了一个关于CTAP和WebAuthn作用机制的图（如下图所示）。浅蓝色虚线代表了面向客户端的平台API的方式是一个执行选择。
关于WebAuthn/CTAP2结合作用的几个部分的介绍：
依赖方和客户端（Relying Parties & Clients）
依赖方是那些有意使用强凭据的Web或者原生应用。在原生情况下，运行在客户端设备上的依赖方也能够通过WebAuthn客户端进行直接的WebAuhtn调用。在Web环境下，有意使用凭据的实体是不能直接与WebAuthn API进行交互的，因此必须借助浏览器作为代理来进行交互。需要注意的是：不要将FIDO依赖方和联合依赖方（Federated Relying Parties）混淆，上图中并没有单点登录（Single Sign-On）。
客户端设备（Client Device）
客户端设备是托管给拥有强认证的硬件设备，比如笔记本电脑和手机。
平台认证器（Platform Authenticator）
平台认证器通常是依托于客户端设备的，并且不能通过跨平台传输协议（如USB，NFC和BLE）来进行访问。常见的平台认证器包括笔记本电脑上的指纹读取和智能手机前置摄像头的面部识别。
漫游认证器（Roaming Authenticator）
漫游认证器可以连接到多个客户端设备，但是必须通过支持的传输协议进行交互。常见的漫游认证器包括USB安全密钥，支持BLE的智能手机APP或者支持NFC的感应卡。这些认证器可能需要支持CTAP1，CTAP2或者同时支持。
CTAP2平台/主机设备（CTAP2 Platform/Host）
CTAP2平台（在CTAP2规范也被称之为“主机”）是与认证器进行信息沟通的客户端设备的一部分。该平台负责安全地报告请求源以及调用CTAP2 Cbor API。在平台不是CTAP2识别的情况下，客户端本身就难免承载更多的负担，并且内部机理可能有着些微的不同。
许多依赖方和客户端可以再耽搁客户端设备上与多个认证器进行交互。用户可能就需要安装不同支持WebAuthn的浏览器，当然，也可能是同时拥有内置的指纹识别器，插入式的安全密钥或者支持BLE的手机APP。WebAuthn API能使客户端向认证器提出请求——为了创建一个密钥，也能使客户端获取密钥断言，反馈容量和管理PIN等。
交互部分
在使用WebAuthn和CTAP2之前，我们使用的是U2F和CTAP1。U2F是FIDO联盟的一个通用第二级因素规范（universal second factor specification）并且仍有很多认证器在使用CTAP1并管理U2F凭证，WebAuthn旨在与CTAP1认证器进行交互，且U2F仍旧可以使用，只要依赖方没有限定只能使用FIDO2功能。
FIDO2认证器已经实现的，WebAuthn依赖方可能需要的功能包括：
- 每个依赖方可以存储多个账户的密钥
- 客户端PIN
- 定位（认证器返回的位置）
- HMAC-secret（可以启用离线方案）
其他的功能看起来很酷，也许将来会用得到，但是现在并没有被应用：
- 业务审批
- 用户验证索引（允许服务器去了解本地存储的生物识别是否随着时间而产生了改变）
- 用户验证模式（依赖方可以指定可接受的误识（false acceptance）和拒识率（ false rejection rates））
未来，博客将发文来探讨这些交互项目的好处以及内部工作原理（其中一些以及在规范中提及，但并未进行任何实现）。
微软的实现方式
微软的FIDO2实现以及在市场上有很多年了：独立实现的，并且符合标准的软件和服务。截止到Windows 10 2018年10月更新的发布为止，所有的微软组建都更新到使用最新的WebAuthn RC版本——这个版本是一个稳定的版本，在规范进行最终审核之前是不会进行任何规则上的变更的。由于微软是世界上最早部署FIDO2的公司之一，一些受欢迎的非微软组件的组合（combinations）将无法实现交互——但是请给一点时间去解决。请记住，规范的普及并不会一蹴而就。作为一个有责任的企业，我们将努力实现所有组件都能以正确的扩展方式来支持规范。
下面是微软一些实现的大致布局：
微软账户
扮演着WebAuthn依赖方的角色。如果您不熟悉微软账户，其实它是Skype，Xbox，Outlook和其他微软产品的登录服务。登录行为使用JavaScript触发Edge与WebAuthn进行通信。微软账户要求认证器拥有下列功能：
密钥需本地存储在认证器，而不是存储在某个服务器上
有效的离线方案（例如：HMAC-secret）
用户能够在同一个认证器上存储多个用户账户的密钥
如有必要，认证器需要使用客户端PIN来解锁TPM
注意：这是微软现行的要求。如果需要被称为“微软兼容”的官方发布和维护的扩展列表，请参阅此文档。由于微软账户需要FIDO2 CTAP2认证器特有的功能和扩展，因此所有站点将不接受CTAP1（U2F）凭据。
微软Edge浏览器
扮演着WebAuthn客户端的角色。Edge可以处理上面提到的WebAuthn/CTAP2特性的UI，并且支持AppID扩展。Edge能够与CTAP1和CTAP2认证器进行交互，这意味着它可以更容易地进行U2F和FIDO2凭据的创建和使用。然而Edge并不使用U2F协议，所以依赖方被要求只能使用WebAuthn规范。很遗憾，目前Edge on Android不支持WebAuthn。
- 有关支持WebAuthn和CTAP的Edge权威信息可以在开发指南中找到。
Windows 10
则扮演着平台的角色。它托管着Win32 平台的WebAuthn API，这能够使得客户端可以与Windows Hello进行交互，以便提醒用户与认证器进行交互。有关Windows Hello的工作机制请参阅他们的博文。
漫游认证器
你也许注意到，以上布局中没有任何“微软”相关的漫游认证器。这是因为我们已经有了很强大的产品生态系统，专门用于强身份验证。并且我们的每个客户（无论是企业还是个人）都对安全性、易用性、分配方式和账户恢复有着不同的需求。如果您需要查看不断更新的FIDO2认证器，您可以参阅这个链接：https://fidoalliance.org/certification/fido-certified-products/。这个列表涵盖了有关内置认证器，漫游认证器甚至是经认证的芯片，且需要注意的是，这个列表仅仅是初期FIDO2涵盖面。虽然USB安全密钥是现在最常见的漫游认证器，但是未来会发生改变，我们需要关注NFC和BLE领域的大量创新，以及将FIDO2整合到智能手机App，智能卡，健身定位器以及能想到的其他地方。
虽然上图在理论上很有意思，但是它的确是一个真实的可交互布局，并且用户最终可以在更多服务中利用认证器——如果能够实现，微软对这部分的投入将会十分值得。我们这个行业仍在追求普遍的标准化的无密码身份验证，我们也在努力的朝着这一目标实现。
下一步工作
这篇概述涵盖了WebAuthn/CTAP2交互的实现，但是这只是冰山一角。在未来的博客文章中我们将深入研究交互本身的一些细节，包括：
如何存储密钥以及留存密钥的重要性
如何使得U2F/CTAP1的正常进行向后兼容
一些具体的扩展以及他们的商业价值
使用第一因素和第二因素认证WebAuthn的差异
开发人员如何成为WebAuthn和CTAP的依赖方
安全措施是如何保证它是安全的