有很多资料表明 FIDO2/CTAP2 向后兼容 U2F:
...all previously certified FIDO U2F Security Keys and YubiKeys will continue to work as a second-factor authentication login experience with web browsers and online services supporting WebAuthn. - Yubico
但在查看规范后，我很难理解它在实践中的实际工作原理。具体来说，FIDO2 的 relying party identifier 似乎不匹配。和 U2F 的 application identity .
在 U2F 中，应用程序标识 是一个 URL，例如 https://example.com。应用程序身份的 SHA-256 称为应用程序参数。 应用程序参数是在注册和身份验证期间实际发送给身份验证器的内容。
在 FIDO2 中，等效项似乎是依赖方标识符，它被定义为一个域名，例如 example.com。
依赖方标识符和应用程序身份在 FIDO2/CTAP2 和 U2F 中具有相同的目的。然而，CTAP2 身份验证器直接获取作为 UTF8 字符串的依赖方标识符，而 U2F 身份验证器仅获取应用程序身份的 SHA-256 哈希(应用程序参数)。
FIDO documentation for CTAP描述 how CTAP2 maps onto CTAP1/U2F .在其中，他们只是将依赖方标识符直接视为应用程序身份:
Let rpIdHash be a byte array of size 32 initialized with SHA-256 hash of rp.id parameter as CTAP1/U2F application parameter (32 bytes)
这似乎不一致。假设我是 example.com，我很早就采用了 U2F 第二因素身份验证。我的应用程序 ID 是 https://example.com，所以我原来的 U2F 应用程序参数是 SHA256("https://example.com") :
100680ad546ce6a577f42f52df33b4cfdca756859e664b8d7de329b150d09ce9
但如果我随后切换到使用 Webauthn，我的依赖方标识符 将只是 example.com。当它被转换为 U2F 应用程序参数时，如 section 7 of fido-client-to-authenticator-protocol-v2.0 中所述，结果值应为 SHA256("example.com"):
a379a6f6eeafb9a55e378c118034e2751e682fab9f2d30ab13d2125586ce1947
那显然不一样。在我切换到 WebAuthn 后，之前设置过 U2F key 以用于我的网站的任何人都将无法再使用它们:除非他们使用他们的 key 重新注册。当然，他们需要能够登录才能执行此操作。
深入挖掘，我注意到他们在文档中给出的示例有一个 依赖方标识符 example.com，但他们在示例中给出的散列是。 ..
1194228DA8FDBDEEFD261BD7B6595CFD70A50D70C6407BCF013DE96D4EFB17DE
这不是上述两个选项中的任一个。我仍然不清楚什么字符串散列到该值。
那么我在这里弄错了什么？使用 U2F 部署 2FA 的服务如何切换到 FIDO2/Webauthn 而无需用户重新注册他们的安全 key ？我一定是遗漏了什么。
最佳答案
WebAuthn 通过 AppID Extension documented in the W3C WebAuthn spec 支持与 U2F 的向后兼容性.依赖方 (RP) 通过此扩展将 U2F 应用程序标识 传递给浏览器。
关于webauthn - FIDO2 与 U2F/CTAP1 的兼容性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60649029/