白皮书：FIDO 认证：增强无密码身份验证的信任、隐私和互操作性

编辑

来自 Amazon Web Services 的 Khaled Zaky
蒙蒂·怀斯曼，超越身份
RSA 安全部门的 Sean Miller
埃里克·勒圣 （Eric Le Saint），Visa

抽象

本文件旨在让人们全面了解验证在加强和推进数字安全形势中的作用，特别是在身份验证方面的作用。 它侧重于认证的核心功能：验证用户设备及其认证材料的来源和完整性。 讨论的重点是 FIDO 凭据如何提供比传统密码系统更安全的替代方案，以及 FIDO 认证如何增强依赖方 (RP) 和最终用户的身份验证安全性。 在本文件中，RP 是指那些提供网站、应用程序和在线服务的实体，它们需要通过确认用户或其他实体的身份来保证用户访问的安全性。 介绍了FIDO Alliance的历史进程，并通过实际类比来理解 FIDO 认证、其针对特定企业的技术解决方案以及认证过程中涉及的隐私问题。

观众

本白皮书面向首席信息安全官、安全工程师、架构师和身份工程师，为考虑在企业生态系统中采用 FIDO 的专业人士提供指导。 读者应具备对 FIDO 技术和验证含义的基本理解，并希望了解为什么要实施验证以及如何实施验证。

虽然身份验证被广泛理解，但信息技术领域的许多从业者可能不太熟悉认证。 根据 FIDO 协议中的理解，认证确认了身份验证器的一组属性或特征。 在物理世界中，我们可以依靠检查对象来检查其属性并验证其真实性。 在互联的数字世界中，物理检查是不切实际的。 用于 FIDO 身份验证的设备在使用前应仔细检查，尤其是在其来源或内容不确定的情况下。 某些交易，尤其是与政府、医疗保健或金融机构相关的交易，需要更高的保证，在这些情况下，依赖方 （RP） 确认验证者的合法性至关重要。 为了确保高确定交易的合法性，RP 可以使用鉴证来验证验证器的真实性和属性。

术语说明：“key”和“key pair”是本文中描述的几种类型的密钥的通用术语。 为了减少这种混淆，在提及用于验证用户的密钥时，将始终使用术语“passkey”。 术语“key”的其他实例的使用将由上下文或修饰符（如 Attestation Key）指定。

在传统的基于密码的系统中，可以假设用户和 RP 对密码保密。 由于此假设未始终如一地执行，因此可能会发生违规行为。 使用密钥而不是密码是一项重大改进，但某些 RP 可能需要更严格的策略来验证身份验证器及其属性的真实性。

与密码不同，通行密钥使用安全生成的密钥材料，允许访问网站和应用程序。 用户和 RP 依靠身份验证器来存储和管理此密钥材料，因此共同负责安全处理密钥。 FIDO 解决方案的所有参与者和组件，包括身份验证器、RP 和密钥提供程序（如果适用），共同确保强大的安全框架。 这与密码相反，密码的安全处理主要取决于用户的内存、行为、RP 和密码管理器（如果使用）。 RP 可以利用证明来验证密钥是否在正确实施的 FIDO 认证设备中得到安全处理。

认证为 RP 提供有关保护用户密钥的身份验证器的信息。 这为 RP 提供了一种实施 FIDO 身份验证安全策略的方法。 在以下部分中，我们将更深入地探讨证明的概念、其用途、实际场景比较以及证明解决的问题。

1.1 FIDO 证明的真实类比

将 API 与日常安全协议进行比较可提供重要的见解。 数字和物理环境都需要严格的检查和平衡，以验证身份并加强信任。 FIDO 认证反映了现实世界中熟悉的信任和验证过程。

要了解 FIDO 鉴证的关键作用，请考虑它在实际识别和验证实践中的应用。 这些类比强调了它的积分功能和功效：

1. 身份证明文件验证： 正如个人可以出示护照或驾驶执照等官方文件来验证身份一样，验证者（例如移民官员）需要证明文件的真实性，因此需要检查相关的印章和标记。 FIDO 认证提供用户身份验证器真实性的证明，提供用于检查的语句，并提供加密签名以验证身份验证器和声明的真实性。
2. 通过身份验证获得信任： 想想信任取决于身份或权威证明的时刻。 例如，访问一个安全的设施，警卫根据您的身份证件对您进行身份验证，授权访问该设施。 FIDO 认证用于在在线注册期间确认身份验证器的来源和真实性时，可以增强对数字环境的信任。
3. 应对威胁和弱点： 在实际场景中，存在 ID 检查来对抗冒充、伪造和欺诈。 FIDO 认证可识别验证器的来源，并帮助 RP 检测来自具有已知漏洞的设备的注册，从而使他们能够确保用户仅使用安全设备。

2.1 从依赖方的角度来看

深入研究 FIDO 认证可以提供有关强化身份验证系统的关键角色的宝贵见解：

1. 有保证的 Authenticator 安全性和合规性： 对于在敏感行业（例如金融或公共领域）运营的 RP，更需要确定身份验证设备是否安全并符合特定标准。 FIDO 认证有助于确保访问服务的身份验证器不仅安全，而且遵守特定的标准和法规。
2. Authenticator 模型特异性和信任Authenticator度：FIDO 认证针对不同的验证器模型量身定制，确保在注册期间的加密证明验证所述验证器模型的真实性。 除了对认证过程的一般信任之外，这种特异性还允许 RP 确认注册请求中使用的密钥来自特定的 FIDO 身份验证器模型。 这种粒度对于 RP 至关重要，因为由于监管或安全原因，身份验证器模型的细节至关重要。
3. 通过认证签名进行验证： 当用户设置新帐户时，载入 RP 可以验证链接到新生成的密钥的“认证签名”是否确实来自真正的身份验证器模型。
4. 事件处理和响应： 如果在身份验证器中发现漏洞，则检查证明的 RP 能够发现哪些身份验证器可能受到影响，并且需要额外的身份验证因素或为受影响的用户注册新凭据。

2.2 从最终用户的角度来看

尽管最终用户可能不知道技术细节，但 FIDO 认证可以增强他们的在线安全性：

1. 增强的服务信任： 在使用服务时，尤其是在银行或政府门户等高可靠性行业，用户可以体验到更高的信心。 他们明白 RP 不仅仅是进行身份验证，而且还确保访问平台的身份验证器遵守特定标准。
2. Authenticator 合规性： FIDO 认证可确保 RP 的身份验证器合规性和安全性，使用户能够从其身份验证设备的可靠功能中受益，并与所需的 RP 相关服务配对。
3. 透明的注册和入职： 注册过程旨在实现无缝连接，但当 RP 请求证明 FIDO 身份验证器时，还包括一个额外的步骤。 在此步骤中，用户必须同意与 RP 共享认证元数据。 这可确保在简化与证明、认证路径验证和验证器合规性相关的后端验证的同时，用户了解并已批准该流程。

在本节中，我们将介绍 FIDO 证明和 FIDO 证明类型。

3.1 什么是 FIDO 鉴证？

在 FIDO 身份验证框架中，认证是在身份验证过程中验证用户身份验证器真实性的过程。 该认证可与 FIDO Alliance的元数据服务 [1] 结合使用，以获取有关认证器的更多信息，包括型号和认证级别。 可选的认证级别（称为企业认证）允许进一步验证特定验证器，请参阅第 4.5 节。

请注意，术语“证明”在 FIDO 上下文之外可能具有不同的含义。 本文仅在 FIDO Alliance范围内讨论鉴证。

在 FIDO 注册中，一个关键步骤是创建用户身份验证密钥，无论是否涉及认证，都会发生该步骤。 在此过程中，用户的验证器（如智能手机）会为每个 RP 生成唯一的加密密钥对。 私钥安全地存储在身份验证器中，而公钥与 RP 共享，从而建立安全的身份验证框架。 此外，在注册期间，身份验证器可能会提供证明，进一步保证身份验证器的完整性。

除了生成用户的身份验证密钥外，FIDO 身份验证框架还包括一个可选的认证过程。 请求认证时，验证器可以通过使用认证密钥对 AAGUID（Authenticator认证全局唯一 ID）和密钥公钥进行签名来提供认证（synced passkeys目前不提供认证），从而创建签名证据，为 RP 建立信任锚点，以验证验证器属性是否满足 RP 条件（FIDO Alliance的元数据服务 [1]，有关更多信息，请参阅第 3.3 节）。 如果验证器无法提供证明，则 RP 可以使用密钥对用户进行身份验证，并可能获取验证器信息（例如 AAGUID），但可能无法获得存在所需验证器属性的可验证证据。

此认证过程有助于防范供应链攻击，例如引入替代或假冒验证器。 通过验证验证器的真实性，RP 了解验证器的属性，并评估它是否符合预期的安全标准，尤其是在注册阶段，以确保设备的合法性。

因此，FIDO 认证是框架更广泛的安全和隐私目标的关键组成部分。 它最大限度地减少了对密码的依赖，促进了基于公钥加密的强设备身份验证，并旨在提供一种标准化和可互操作的方法，以跨不同平台和设备进行身份验证。

3.2 FIDO 认证的类型

有几种类型的 FIDO 认证，它们在认证声明的签署方式上有所不同。 请注意，除 Enterprise Attestation 外，这些证明类型均不提供有关特定身份验证器的信息。 这是为了保护用户隐私。

1. 自我证明： 证明语句由用户的密钥签名。 这为认证语句提供完整性保护，不提供其他保证。
2. 基本证明： 认证声明由验证器的制造商创建并嵌入到验证器中的密钥签名。 这为认证声明和认证商的制造商提供完整性保护。 出于隐私目的，此密钥必须在多个相同的身份验证器模型中复制（当前 FIDO Alliance 要求为 >100,000 台设备）。 它不是特定身份验证器实例所独有的。
3. 认证 CA （AttCA） 或匿名 CA （AnonCA）： 这类似于基本证明，但证明语句由 TPM 证明密钥签名。 在这种情况下，TPM 是一个基于硬件的模块，可在其中执行加密操作，并在不离开模块的情况下安全地存储机密，其认证密钥的证书由管理验证器的受信任机构签名。
4. 企业认证： 这将在第 4.5 节中讨论，

应该注意的是，FIDO2 规范与 WebAuthn 规范 [2] 一起工作。 使用的证明类型是通过检查 WebAuthn 规范中定义的证明对象中的字段来确定的。 WebAuthn 规范提供的进一步定义包括许多不同类型的格式，例如：打包格式、TPM 格式和 Android 密钥格式，以及根据需要支持的自定义格式。

3.3 使用 AAGUID

Authenticator Attestation GUID 或简称 AAGUID 唯一标识验证器的品牌（制造商）和型号。 它不唯一标识特定的验证器。 当 RP 请求证明时，身份验证器会返回 AAGUID，并且 RP 可以使用它来确定身份验证器的品牌和型号是否符合其策略。 除其他用途外，AAGUID 是 FIDO （MDS） [1] 中的查找值，为 RP 提供有关验证器的详细信息。

鉴定机构对 AAGUID 的转让并未提供其完整性或真实性的证据。 RP 必须信任特定的验证器来提供真实的信息。

这一点需要强调：

• 未经认证的 AAGUID 仅供参考，并不保证其真实性。
• Attestation 提供签名，为验证者的身份提供一定程度的保证（取决于证明的类型）。

本节介绍构成 FIDO 证明的事件序列和涉及的组件。

4.1 身份验证与认证密钥

以前的文档中已经介绍了使用 FIDO 的密钥和方法进行用户身份验证，但对于用于认证的密钥和方法的使用可能不熟悉。

• 用户身份验证： 这是用户使用密钥而不是传统密码证明拥有正确系统凭据的过程，这是 FIDO 技术的常见应用。
• 证明： 这是验证者使用未分配给用户而是分配给验证者的密钥对消息进行数字签名的过程，以提供消息真实性的证明。 涉及的消息称为“证明语句”，包含有关验证器的信息。 当认证声明由认证者的认证密钥进行数字签名时，RP 可以验证认证声明的有效性。

总结：

• Passkey 对 RP 的用户进行身份验证
• 证明密钥对证明语句进行签名以验证其来源

如第 3.3 节所述，RP 只需根据元数据服务检查验证者的 AAGUID 即可获取验证器的品牌和型号，以获取此信息。 如果没有 RP 信任的密钥进行数字签名，RP 就无法证明此信息是真实的或与正在查询的身份验证器相关联。

注意：如第 3.2 节所述，有几种证明类型。 其中一种方式是“self-attestation”，它使用用户身份验证密钥对认证语句进行签名。 这在技术上并不矛盾，而是一种简化，以允许保护证明声明的完整性， 而不是 真实性。

4.2 信任认证密钥 – 信任链

认证的基础是 RP 对认证密钥的信任。 认证密钥必须由可信来源生成，并由认证器保护。 可信来源通常是认证者的制造商，但是，在“认证 CA （AttCA） 或匿名化 CA （AnonCA）”的情况下，可信代理或 认证 机构 （CA） 会断言认证者的真实性。 认证密钥的公共部分由 RP 使用可信通道获取，通常是前面提到的 FIDO MDS [1]。

4.3 FIDO 认证序列

认证使用与验证器（而不是用户）关联的密钥对。 相同品牌和型号的所有验证器都必须返回相同的证明语句，这一点很重要。 本节稍后将介绍证明的格式，但请务必了解，在高级别上，证明提供有关验证器类型的信息，并且它并不特定于单个设备。

以下步骤（1.a 或 1.b，然后是 2.）总结了 FIDO 身份验证器的认证生命周期：

1. Authenticator 制造： 有两种模式可用于配置认证密钥：案例“a”用于漫游身份验证器，例如跨多个平台使用的智能手机或 USB 安全密钥，以及案例“b”用于平台身份验证器，它们是笔记本电脑或智能手机等设备中的内置身份验证机制。

注意：FIDO 规范在架构上不需要这种两种模型的区别，但它是当今已知的实际实现，并为本文的目的提供了简化的解释。 此外，描述是泛化的，制造商可能会部署与此处描述的不同方法 – 这只是泛化。

• 漫游 Authenticator： 身份验证器制造商为特定身份验证器模型生成认证密钥对 （AK）。 制造商使用 AK 的公有密钥创建证书。 AK 证书通常放入 MDS 中。 这允许 RP 在提供 AAGUID 时从受信任的来源 MDS 检索 AK 证书。 AK 证书本身通常使用验证者的制造商颁发者密钥进行签名。 这将创建一个从验证器返回其制造商的可验证加密链。
• 平台 Authenticator： 验证器不是从其制造商处发货的，而是带有可用于 FIDO 认证的认证密钥。 相反，它依赖于平台身份验证器中的持久密钥。 这些密钥是认证服务用于生成 FIDO 认证密钥的关键加密元素。 认证服务受依赖方信任，可为平台验证器的完整性和合规性提供保证。 认证服务会创建一个认证密钥，该密钥用于对认证对象进行签名，该对象会断言认证器的属性。 RP 必须信任认证服务，就像信任漫游验证器的制造商一样。

2. 使用认证进行用户配置： 在注册（设置新账户）期间，将使用唯一的加密密钥对创建新的用户凭证（密钥），并将公钥发送到 RP。 RP 可以选择性地要求证明。 请注意，用户或验证者可能会忽略认证要求。 如果验证器拥有认证密钥并且用户允许该密钥，则用户的公钥密钥（以及认证语句）将发送到使用认证私钥签名的 RP。 这允许 RP 验证认证语句，其中包括新创建的用户的用户的公共密钥。 因此，提供用户的私有密钥来自具有已知属性的特定身份验证器的置信度/证据。

4.4 证明生命周期的一般描述

认证密钥通常具有关联的认证证书，该证书链接到制造商的受信任根证书。 一旦 RP 确定了已签名证明声明的真实性，RP 就可以将证明声明与 MDS 一起使用，以了解有关验证器的更多信息。 例如，RP 可能希望了解使用了什么级别的加密以及以一定的准确性利用了什么类型的激活密钥（例如，生物识别技术）等。 为了获取有关身份验证器的详细信息，标识身份验证器模型的 AAGUID 值将与新创建的公有密钥一起发送到 RP。 由于 AAGUID 表示一组特定的身份验证器实例，例如具有特定特征、特定外形规格或企业品牌的特定产品版本，因此 RP 可以使用此 AAGUID 从 MDS 查找有关身份验证器的更多信息。

如图所示，证明对象（如果提供）将指示证明语句的格式，然后包含 RP 可以检查的一些数据。 证明对象包括一个语句，该语句通常包含签名以及提供证明公有密钥的出处信息的证书或类似数据。 附录的第 9.1 节中提供了证明对象的详细信息。

RP 应首先验证认证声明的签名，验证后，再检查认证声明。 一旦 RP 确定了证明语句的格式和类型，RP 就会查看内容并将内容与其策略进行比较。

附录 9.2 中提供了 RP 直接向验证器发出请求所产生的认证响应示例。 证明响应中提供的 AAGUID 可用于从 FIDO 元数据服务获取有关验证器的其他详细信息。

4.5 企业认证

默认情况下，FIDO 允许验证器仅使用 AAGUID 提供产品信息，并提供有关其类型和功能的高级信息，从而明确禁止验证器提供唯一标识信息。 但是，企业认证消除了该限制，因为它将唯一验证器密钥对绑定到序列号或等效的唯一标识符。

4.5.1 使用案例

企业出于各种目的积极管理身份验证器，对于保护高价值资产至关重要。 虽然员工可以选择自己的身份验证器，但企业可以限制每个员工的身份验证器，并在离职或丢失时撤销它们，因为他们监督从购买到取货的整个过程。 此外，企业可以优先考虑可管理性和可追溯性以保护资源。 在发生威胁事件时，取证调查可能需要跟踪与特定身份验证器相关的活动，并关联身份验证器的使用活动模式，以发现异常或威胁来源。 严格的管理增强了他们确保事务不可否认的能力。 高风险用户可能会从企业分配专门的身份验证器，以访问受限制的敏感信息或服务。 这些验证器被分配了特定的 PIN，并通过受信任的供应链获得。

某些企业部署需要将 FIDO 身份验证器与企业认证一起使用，以识别特定的设备身份（例如设备序列号）。 企业认证验证还必须得到组织的特定依赖方的支持。 这些做法积极满足了企业特定的需求，以改进对设备预置和生命周期管理的控制。

4.5.2 流程

4.5.2.1 供应

企业认证配置与第 4.3 节中描述的过程进行了修改，以在认证语句中包含验证器唯一信息，并添加允许从验证器制造商永久“刻录”到验证器中的任何一组 RP 接收此唯一信息的任何特定 RP。 验证器仅对预置给验证器的 RP 执行企业证明。 其他 RP 仍可以执行排除唯一标识符的任何其他类型的认证。

烧录了企业认证的认证器不得在公开市场上 销售 ，只能由认证器的制造商直接提供给 RP。 想要启用企业认证验证器的 RP 将通过提供 RP ID （RPID） 列表直接从验证器的制造商处订购它们。 这些特定的 RPID 是永久刻录/写入身份验证器的 RPID。

4.5.2.2 使用 Enterprise Attestation 进行用户注册

在第 4.3 节中描述的 FIDO 用户注册期间，RP 可能会指示需要企业认证。 这将通过提供验证器的唯一标识符证明，将用户与特定验证器唯一关联。 在用户注册期间，身份验证器会验证请求的 RP（使用其 RPID）是否属于允许执行企业认证的永久预置 RPID 列表中列出的 RPID。 如果获得批准，此唯一标识符将添加到认证对象中，并由 Attestation Key 签名。 RP 应验证认证对象，以及（可选）用于对认证对象进行签名的证书链接/链。 然后，RP 可以在用户注册时验证唯一标识符是否确实由企业购买，并可能将该验证包含在其记录中。

RP 用于验证唯一标识信息的实现因验证器而异。 某些身份验证器可能会使用供应商协助的方法，其中企业向制造商提供 RP ID 列表，这些 ID 会印在身份验证器中。 另一个是某些企业托管平台维护策略的位置，例如企业托管浏览器。 企业托管平台不会将允许的 RP 列表印记到身份验证器中，而是会根据策略确定是否向 RP 提供企业证明。

虽然认证为认证者提供了有价值的信任断言，但在认证期间共享的信息可能会引起隐私问题。 一些隐私注意事项包括：

• 虽然本文中描述的证明属性包括一组广泛的隐私控制，但实施者应根据区域和本地隐私策略考虑这些功能。
• 认证允许与 RP 共享信息，例如验证器的品牌和型号、固件版本或制造商详细信息。 可能会担心敏感的身份验证器特定数据可能会泄露，以及随后根据此信息对用户进行跟踪或分析。 正是出于这个原因，建议使用至少 100,000 个的认证批次，这样它就不会是一个用于识别设备的小池。
• 非企业认证可防止身份验证器中的多个密钥与不同的 RP 相关联，从而保护用户隐私。 例如，使用单个身份验证器的人员可以为 RP 1 （RP1） 创建用户身份验证密钥 （passkey1），然后为 RP 2 （RP2） 创建新的用户身份验证密钥 （passkey2）。 即使该人对两个 RP 使用相同的物理验证器并使用认证，即使 RP1 和 RP2 协作，他们也无法确定 passkey1 和 passkey2 来自同一个验证器，因此，他们无法确定交易来自同一个人。
• 企业认证添加了唯一标识信息（例如，设备序列号），允许授权的 RP 在企业内的多个预配置 RP 中跟踪特定身份验证器的使用情况。 预计此环境中的用户能够了解此属性及其为企业增加的价值。

RP 可以确定 FIDO 身份验证器的注册要求，这反映在他们对认证传送的偏好上。 一些 RP 可能不要求证明来决定是否允许注册。 其他 RP 可能具有需要证明对象才能做出风险决策的安全要求。 安全要求可能基于身份验证器的特征（例如，是否需要 PIN），也可以根据允许的身份验证器型号具体。 最后，在受保护程度更高的环境中，某些 RP 可能需要额外的企业证明，以确保企业知道、控制和信任身份验证器。

FIDO 认证是 FIDO 和 WebAuthn 标准的一个组成部分，用于验证用户身份验证器的真实性。 此过程可以抵御各种威胁，例如供应链攻击、假冒验证器和替代攻击。 对于需要更高身份验证保证的 RP，证明是获得该保证的以 FIDO 为中心的机制。 对于需要确保特定验证器真实性的 RP，证明为这些 RP 提供了保证，即他们正在处理已知且受信任的设备。

通过为用户注册的每个 RP 生成唯一的密钥对，FIDO 强调了其对用户安全的承诺，消除了潜在的跨服务漏洞。 企业认证功能为组织提供了对其员工使用的身份验证器的更好管理，对于优先考虑精确设备管理的环境至关重要。

FIDO 认证会带来某些隐私注意事项。 披露身份验证器特定信息、用户设备指纹识别和用户跟踪的可能性，都凸显了隐私感知方法的重要性。 所有利益相关者，包括 RP、制造商和用户，都必须在增强安全性和保护用户隐私之间找到路径。

FIDO 证明是适应性强的。 RP 可以自行决定请求他们所需的认证级别，从而确保量身定制的方法适用于专业服务和大型企业。

总之，FIDO 认证增强了在线身份验证。 它专注于公钥加密、唯一密钥对和特定的证明流程，通过仔细部署、对其功能的透彻理解以及对用户隐私的一贯承诺，其有效性得以最大化。

作者感谢以下人员（按字母顺序排列）的宝贵反馈和评论：

• FIDO 企业部署工作组成员
• Dean H. Saxe，Amazon 企业部署工作组联合主席
• Jerome Becquart，Axiad IDS， Inc.
• Johannes Stockmann，Okta 公司
• Tom De Wasch，OneSpan North America Inc. 公司
• Tom Sheffield，Target Corporation
• 约翰·丰塔纳，Yubico

9.1 证明对象

附录图 1 – 鉴证对象*
*布局，说明包含的 验证器数据 （包含 已证明的凭证数据）和 证明语句。

9.2 示例 Attestation 对象

attestationObject: {
  "fmt": "packed",
  "attStmt": {
    "alg": -7,
    "sig": "3045022100da2710ff0b5f5e5d72cda8c1e650f0b696e304942e55138672aa87a5e370a92d02205fd1a48bbda4757aac21252c7064f21130aba083151ab8ae75a26a356b675495",
    "x5c": [
      "3082026f30820213a003020102020404ae6da1300c06082a8648ce3d04030205003077310b3009060355040613025553310b3009060355040813024d413110300e06035504071307426564666f726431193017060355040a1310525341205365637572697479204c4c4331133011060355040b130a4f7065726174696f6e733119301706035504031310525341204649444f20434120526f6f743020170d3232303632333034323132315a180f32303532303632323034323132315a30818c310b3009060355040613025553310b3009060355040813024d413110300e06035504071307426564666f726431193017060355040a1310525341205365637572697479204c4c4331223020060355040b131941757468656e74696361746f72204174746573746174696f6e311f301d06035504031316525341204453313030204649444f20426174636820343059301306072a8648ce3d020106082a8648ce3d0301070342000465f2b3189a6dd2f7df9de784c1c8fd00ae804ac8de7bea042d00563dcd5d7a40948ae59d9dcf8722d8b6025ba98fbb80e6698bbe5003e4db4d80c4a50a3348e4a37330713021060b2b0601040182e51c010104041204107e3f3d3035574442bdae139312178b39301f0603551d23041830168014b851a38b84da69c9fd5b467c1f8e374ac0433419300c0603551d130101ff04023000301d0603551d0e041604142806df6c60b1656a78f97a28e168e5ec8d2937b4300c06082a8648ce3d0403020500034800304502210088122ea59cca8480ed57a0a60a2e203302b4d93713f837be7acc3a2c895c6251022010f67d709ea2dc04ca63aec8d341dc9e562909dcea3f2a4abee2bdfd21dd162d"
    ]
  },

  "authData": {
    "rpIdHash": "f95bc73828ee210f9fd3bbe72d97908013b0a3759e9aea3d0ae318766cd2e1ad",
    "flags": {
      "userPresent": true,
      "reserved1": false,
      "userVerified": true,
      "backupEligibility": false,
      "backupState": false,
      "reserved2": false,
      "attestedCredentialData": true,
      "extensionDataIncluded": false
    },

    "signCount": 4,
    "attestedCredentialData": {
      "aaguid": "7e3f3d30-3557-4442-bdae-139312178b39",
      "credentialId": "c0a3eb62197b77edd0cd1c73bffeb068dcc2595cfdf2e4dc01478bddc9cefcf52282f95bc73828ee210f9fd3bbe72d97908013b0a3759e9aea3d0ae318766cd2e1ad04000000",
      "credentialPublicKey": {
        "kty": "EC",
        "alg": "ECDSA_w_SHA256",
        "crv": "P-256",
        "x": "D3Ki/INLfrmlNogo8d1lK7kBT4Fh3wPyVt/kusDAMKY=",
        "y": "M11KJSPXRiBn1ZtAo1eynxvaUXqipZJYV0AT0gC2czo="
      }
    }
  }
},

附录图 2 – 示例 Attestation 对象

[1] FIDO Alliance 元数据服务 – https://fidoalliance.org/metadata/
[2] WebAuthn 规范 – 证明部分 – https://www.w3.org/TR/webauthn-3/#sctn-attestation