FIDO Metadata Statements（译）

2.概览

在竞争激烈的市场中，FIDO协议簇利用各种各样不同的设备使在线认证更简单 安全。这背后的大部分复杂性对依赖方的应用程序来说是隐藏的，但是为了达到 FIDO的目标，依赖方应该有多种方法来发现并校验认证器的特性。依赖方通过 FIDO联盟发布的认证器元数据声明能够获取经核实的认证器信息的子集。访问 元数据声明的URL通过元数据服务[UAFMetadataService]提供的元数据TOC（内 容列表）文件获取。
相关术语的定义请参考FIDO术语表[FIDOGlossary]。

2.1  范围
本文档描述了认证器元数据声明的格式和其中包含的信息。关于不同消息类型的 定义列表，可参考预定义值的FIDO注册表[UAFRegistry]。 关于认证器元数据分发过程和方法的描述，以及验证这些元数据的方法在 UAF 元数据服务规范[UAFMetadataService]中描述。

2.2  受众
本文档的目标受众包括：
 想要为产品生成元数据的FIDO认证器供应商。
 FIDO服务实施者，它需要利用元数据声明来校验认证器的特性和鉴证声 明、为协议消息选择合适算法、创建策略声明、或者使其他定制操作适应 认证器特性。
想要达到下列功能的FIDO依赖方：
(1)创建自定义策略声明来表明会接受哪个认证器。
(2)基于他们的特性，对核心认证器进行风险评分。
(3)校验经鉴证的认证器标识与第三方元数据相互对照。

2.3 架构

在依赖方的FIDO服务器直接使用认证器元数据声明，但是权威的声明中包含的信息会用在其他的地方。服务器如何获取元数据声明在[UAFMetadataService]中做了描述。
围绕认证器元数据声明的工作流如下：
1.认证器供应商产生一个元数据声明，描述认证器的特性。
2.作为FIDO认证过程的一部分，将元数据声明提交到FIDO联盟。FIDO联盟按照[UAFMetadataService]中描述的方式，分发该元数据。
3.FIDO依赖方配置它的注册策略，允许与特定特性匹配的认证器注册。
4.FIDO服务器发送包含策略声明的注册挑战报文。
5.FIDO UAF客户端接收到作为挑战报文一部分的策略声明。它根据自身汇报的特性查询可用的认证器，并且(根据用户输入)选择一个与策略相匹配的认证器，来进行注册。
6.客户端处理并向服务器发送注册响应报文。该报文包含认证器的AAID，也可以包含签名(可选)，使用与该认证器鉴证证书中公钥对应的私钥进行签名。
7.FIDO服务器使用认证器的AAID查询元数据声明。如果元数据声明中列有一个或多个鉴证证书，需要证明已提供鉴证签名，并且该签名是使用下列私钥之一进行签名:(a)对应于元数据声明中一个证书的私钥（b）与认证器元数据声明中列出的发行者证书相链接的证书的公钥对应的私钥。
8.FIDO服务器分户权威元数据声明，验证认证器是否满足提供的原始注册策略。这样能够阻止错误的、被篡改的或者被截获的FIDO UAF客户端注册不符合策略的认证器。
9.可选，根据依赖方的输入，FIDO服务器可能会基于认证器的元数据设定风险或可信分数，包括既定策略中不选择的元素。
10.可选，FIDO服务器可能会成为认证器从第三方发布的其他元数据数据库相互对照经鉴证的AAID。这种第三方元数据可能，例如，会通知FIDO服务器，认证器是否已经通过相关的特定市场或垂直行业的认证，或者是否满足应用程序特定的管制要求。

3. 类型

3.1CodeAccuracyDescriptor结构
CodeAccuracyDescriptor描述了口令用户验证方式相关的准确性和复杂性。
注释：
该方法的一个例子是手机sim卡解锁使用的4位pin码。
由于有足够多的证据[iphonePasscodes][MoreTopWorstPasscodes]证明用户不会随机均匀分布地选择口令，我们使用数字系统base(基数)和minLen，代替可能的数字组合。这样软件可能会考虑不同基数的多种概率分布。这实质上意味着在实际应用中口令并没有随机选出的那么安全。

dictionary CodeAccuracyDescriptor{required unsigned short base;required unsigned short minLength;unsigned short maxRetries;unsigned short blockSlowdown;}

3.1.1 CodeAccuracyDescriptor结构成员
base类型为required unsigned short
编码的数字系统为基数，例如，十进制数中的10
minLength类型为required unsigned short
该编码的给定基数的最小数字位数，例如，4代表4位数
maxRetries类型为unsigned short
认证器阻止该方法前（至少阻止一段时间）的错误尝试的最大次数。0代表永远不会阻止。
blockSlowdown类型为unsigned short
强制要求的最短等待时间秒数（例如，由于强制重启或类似操作）。0代表该用户验证方法被锁定，可能会永久锁定，也可能锁定该方法直至替代的用户验证方法成功以后。所有替代的用户验证方法必须在元数据的userVerificationDetails中适当的说明。
3.2 BiometricAccuracyDescriptor结构
BiometricAccuracyDescriptor描述了生物识别用户验证方式相关的准确性和复杂性。
注释：
误识率（FAR）和误拒率（FRR）的值通常通过受试者工作特征（ROC）曲线相互依赖。
人工制品误识率（FAAR）值反映了检测外观攻击的能力，例如检测橡胶指纹外观。
这里给出的FAR，FRR和FAAR的值必须反映认证器的真实配置（与理论上的最佳情形的值截然相反）。
FAR、FRR和FAAR必须设置至少一个。如果供应商不想指定这些值，那么VerificationMethodDescriptor.baDese必须被省略。

dictionary BiometricAccuracyDescriptor{double FAR;double FRR;double EER;double FAAR;unsigned short maxReferenceDataSets;unsigned short maxRetries;unsigned short blockSlowdown;}

3.2.1 BiometricAccuracyDescriptor结构成员
FAR类型为double
对于单个参考数据的识别率[ISO19785-1]，即被接受为有效集的不匹配数据集的百分比。例如0.1%的FAR被编码为0.001。
注释
当所有参考数据集都被使用时，FAR结果是maxReferenceDataSets*FAR。误识率与安全性相关。误识率越低意味着更高的安全性。
该值只覆盖实时捕获的主体 --不是人工制品的外观。
FRR类型为double
对于单个参考数据集的误拒率，即提供的有效数据集被拒收的百分比。例如0.1%的FRR被编码为0.0001。
注释：
误拒率与便利性相关。误拒率越低意味着更高的便利性。
EER类型为double
对于单个相关数据集的等错率。
FAAR类型为double
人工制品误识率[ISO30107-1]，即被系统错误接受的人工制品百分比。例如0.1%的FAAR被编码为0.0001。
注释：
人工制品误识率与系统安全性相关，其越低意味着安全性越高。
maxReferenceDataSets类型为unsigned short
备选相关数据集的最大数量，例如，如果允许用户在基于指纹的认证器上注册3个不用的手指，该值则为3.
maxRetries类型为unsigned short
认证器阻止该方法前（至少阻止一段时间）的错误尝试的最大次数。0代表永远不会阻止。
blockSlowdown类型为unsigned short
强制要求的最短等待时间秒数(例如，由于强制重启或类似操作)。0代表该用户验证方法被锁定，可能会永久锁定，也可能锁定该方法直至替代的用户验证方法成功以后。所有替代的用户验证方法必须在元数据的userVerificationDetails中适当的说明。
3.3 PatternAccuracyDescriptor结构
PatternAccuracyDescriptor描述了图案用户验证方式相关的准确性/复杂性。
注释
这种图案方式的例子，有安卓[AndroidUnlockPattern]屏幕解锁使用的3*3的点阵。这种情况下基于用户选择4位PIN（该机制的最低要求），minComplexity是1624。

dictionary PatternAccuracyDescriptor{required unsigned long minComplexity;unsigned short maxRetries maxRetries;unsigned short blockSlowdown;}

3.3.1 PatternAccuracyDescriptor结构成员
minComplexity类型为required unsigned long
可能的图案（有最短长度）的数量，其中恰好有一个是正确的，例如，平均分配时1/probability的概率。
maxRetries类型为unsigned short
认证器阻止该方法前（至少阻止一段时间）的错误尝试的最大次数。0代表永远不会阻止。
blockSlowdown类型为unsigned short
强制要求的最短等待时间秒数(例如，由于强制重启或类似操作)。0代表fail用户验证方法被锁定，可能会永久锁定，也可能锁定该方法直至替代的用户验证方法成功以后。所有替代的用户验证方法必须在元数据的userVerificationDetails中适当的说明。

3.4 VerifucationMethodDescriptor结构
认证器实现特定的基本用户验证方法的描述符
基本用户验证方式必须从[UAFRegistry]描述的列表中的选择。
注释
实际上，上述描述的一些方法可能会组合起来。例如，基于指纹的用户验证可能与备选的口令相结合。
相关的AccuracyDescriptor的规范是可选的，但推荐使用。

dictionary VerificationMethodDescriptor{required unsigned long userVerification;CodeAccuracyDescriptor caDesc;BiometricAccuracyDescriptor baDesc;PatternAccuracyDescriptor paDesc;}

3.4.1 VerificationMethodDescriptor结构成员
userVerification类型为required unsigned long
一个单独的USER_VERIFY常数（参考[UAFRegistry]），不是位标记的组合。该值必须为零。
caDesc类型为CodeAccuracyDescriptor
在USER_VERIFY_PASSCODE方法的情况下可能会使用。
baDesc类型为BiometricAccuracyDescriptor
在USER_VERIFY_FINGERPRINT,USER_VERIFY_VOICEPRINT,USER_VERIFY_FACEPRINT,USER_VERIFY_EYEPRINT,或者USER_VERIFY_HANDPRINT方法的情况下使用。
paDesc类型为PatternAccuracyDescriptor
在USER_VERIFY_PATTERN方法的情况下可能会使用。

3.5 verificationMethodANDCombinations类型定义

typedef VerificationMethodDescriptor[] verificationMethodANDCombinations;

verificationMethodANDCombinations必须是非空的。是一个包含作为成功用户验证的一部分而必须通过的基本用户验证方法列表的列表。
如果使用单一的用户验证方法是充足的，则该列表只包含一个条目。
如果该列表包含多个条目，那么所有被列出的用户验证方法都必须作为用户验证过程的一部分被通过。
3.6 rgbPalletteEntry结构
rgbPalletteEntry是RGB三样品元组调色板条目

dictionary rgbPalletteEntry{required unsigned short r;required unsigned short g;required unsigned short b;}

3.6.1 rgbPalletteEntry结构成员
r类型为required unsigned short
红色通道取样值
g类型为required unsigned short
绿色通道取样值
b类型为required unsigned short
蓝色通道取样值

3.7 DisplayPNGCharacteristicsDescriptor结构
DisplayPNGCharacteristicsDescriptor描述了PNG图片的特性，如PNG[PNG]规范中定义的IHDR(图片头)和PLTE(调色板表)。

dictionary DisplayPNGCharacteristicsDescriptor{required unsigned long width;required unsigned long height;required octet bitDepth;required octet colorType;required octet compression;required octet filter;required octet interface;rgbPalletteEntry[] plte;}

3.7.1 DisplayPNGCharacteristicDescriptor结构成员
width类型为required unsigned long
图片宽度
height类型为required unsigned long
图片高度
bitDepth类型为required octet
位深，每个样品或每个调色板索引的位数
colorType类型为required octet
颜色类型定义了PNG图片的类型
compression类型为required octet
用来亚索图片数据的压缩方法
filter类型为required octet
过滤方法是压缩之前应用图片数据的预处理方法。
interlace类型为required octet
交错方法是图片数据的传输顺序
plte类型为rgbPalletteEntry数组
1到256的调色板条目

3.8 EcdaaTrustAnchor结构
在ECDAA证明的情况下，必须在该字段中指定ECDAA发行人的信任锚点。

dictionary EcdaaTrustAnchor{required DOMString X;required DOMString Y;required DOMString c;required DOMString sx;required DOMString sy;required DOMString G1Curve;}

3.8.1 EcdaaTrustAnchor结构成员
X的类型为required DOMString
ECPoint2 \（X = P_2 ^ x \）的ECPoint2ToB的结果的base64url编码。有关ECPoint2ToB的定义，请参阅[FIDOEcdaaAlgorithm]
Y的类型为required DOMString
ECPoint2 \（Y = P_2 ^ y \）的ECPoint2ToB的结果的base64url编码。有关ECPoint2ToB的定义，请参阅[FIDOEcdaaAlgorithm]。
c的类型是required DOMString
对BigNumberToB（\（c \））的结果进行base64url编码。有关\（c \）的说明，请参阅[FIDOEcdaaAlgorithm]中的“发行人特定ECDAA参数”一节。有关BigNumberToB的定义，请参阅[FIDOEcdaaAlgorithm]
sx的类型是required DOMString
base64url编码BigNumberToB（\（sx \））的结果。有关\（sx \）的说明，请参阅[FIDOEcdaaAlgorithm]中的“发行人特定ECDAA参数”一节。有关BigNumberToB的定义，请参阅[FIDOEcdaaAlgorithm]。
sy的类型是required DOMString
BigNumberToB（\（sy \））的结果的base64url编码。有关\（sy \）的说明，请参阅[FIDOEcdaaAlgorithm]中的“发行人特定ECDAA参数”一节。有关BigNumberToB的定义，请参阅[FIDOEcdaaAlgorithm]。
GlCurve的类型是required DOMString
G1的Braaeto-Naehrig椭圆曲线支持“BN_P256”，“BN_P638”，“BN_ISOP256”和“BN_ISOP512”。有关详细信息，请参阅[FIDOEcdaaAlgorithm]中的“支持的ECDAA曲线”一节。

注释

每当一方第一次使用该信任锚时，它必须首先验证它是否通过(s,sx,sy)来正确生成。有关详细信息，请参阅[FIDOEcdaaAlgorithm]

3.9 ExtensionDescriptor结构
这个描述符包含了了认证器支持的扩展。

dictionary ExtensionDescriptor{required DOMString id;DOMString data;required boolean fail_if_unknow;}

3.9.1 ExtensionDescriptor结构成员
id的类型是required DOMString
标识这个扩展
data的类型是DOMString
包含进一步描述正确处理扩展所需的扩展和/或数据的任意数据。
此字段可以丢失或可以为空。
fail_if_unknow的类型是required boolean
指示当FIDO服务器，FIDO客户端，ASM或FIDO身份验证器要处理扩展时，是忽略未知扩展（false）还是导致错误（true）。
 值为false表示未知扩展必须被忽略
 值为true表示未知扩展必须导致错误

4. 元数据键

dictionary MetadataStatement {    AAID                                         aaid;    AAGUID                                       aaguid;    DOMString[]                                  attestationCertificateKeyIdentifiers;    required DOMString                           description;    required unsigned short                      authenticatorVersion;    DOMString                                    protocolFamily;    required Version[]                           upv;    required DOMString                           assertionScheme;    required unsigned short                      authenticationAlgorithm;    required unsigned short                      publicKeyAlgAndEncoding;    required unsigned short[]                    attestationTypes;    required VerificationMethodANDCombinations[] userVerificationDetails;    required unsigned short                      keyProtection;    boolean                                      isKeyRestricted;    boolean                                      isFreshUserVerificationRequired;    required unsigned short                      matcherProtection;    required unsigned long                       attachmentHint;    required boolean                             isSecondFactorOnly;    required unsigned short                      tcDisplay;    DOMString                                    tcDisplayContentType;    DisplayPNGCharacteristicsDescriptor[]        tcDisplayPNGCharacteristics;    required DOMString[]                         attestationRootCertificates;    EcdaaTrustAnchor[]                           ecdaaTrustAnchors;    DOMString                                    icon;    ExtensionDescriptor                          supportedExtensions[];};

aaid类型为 required AAID
认证器验证标识符。AAID 的结构定义参见[UAFProtocol]。
description类型为 required DOMString
人类可读的对认证器的简短描述。
注释
该描述应该有助于管理员配置认证器策略。该描述可能与认证器的ASM返回的描述有所不同。
authenticationVersion类型为 required unsigned short
最早的（例如，最低的）满足该元数据声明中规定要求的可信 authenticatorVersion。
向元数据 TOC对象[UAFMetadataService]中增加带有状态 UPDATE_AVAILABLE的新 StatusReport条目时，如果这次更新修复了严重的安全问题，必须也修改 authenticatorVersion。例如，之前的StatusReport条目带有状态码USER_VERIFICATION_BYPASS，ATTESTATION_KEY_COMPROMISE，USER_KEY_REMOTE_COMPROMISE，USER_KEY_PHYSICAL_COMP ROMISE，REVOKED。
如果该版本比认证器显示的固件版本高（新），建议认为风险提高。例如，如果带有状态 USER_VERIFICATION_BYPASS或者 USER_KEY_REMOTE_COMPROMISE的 StatusReport条目高于UPDATE_AVAILABLE条目，那么任何固件版本低于（旧于）元数据声明中规定的版本，即被认为是易受攻击的。
upv类型为 required Version 数组
该认证器支持的UAF协议版本。Version的结构定义参考[UAFProtocol]。
assertionScheme类型为 required DOMString
认证器支持的断言方案。必须设为FIDO UAF注册表[UAFRegistry]中预定义的枚举字符串之一。
authenticationAlgorithm类型为 required unsigned short 
认证器支持的认证算法。必须设为FIDO UAF 注册表[UAFRegistry]中预定义的UAF_ALG常数之一。
publicKeyAlgAndEncoding类型为 required unsigned short 
在注册操作期间，认证器使用的公钥格式。必须设为FIDO UAF注册表[UAFRegistry]中预定义的UAF_ALG_KEY常数之一。因为在与认证器发现 或策略相关的APIs中不提供该信息，FIDO服务器必须准备接受和处理任意或所有自身所支持的公钥算法的密钥表示。该值必须不为零。
attestationTypes类型为 required unsigned short 数组
支持的鉴证种类。（例如 TAG_ATTESTATION_BASIC_FULL）参考UAF注册表[UAFRegistry]了解更多详情。
userVerificationDetails类型为required VerificationMethodANDCombinations数组
一个备选的 VerificationMethodADNCombinations 列表。每一个这样的条目都是一个备选的用户验证方法。每一个备选的用户验证方法可能本身是多种形式的“与”组合。 所有有效的备选用户验证方法必须在此正确指定。如果该方法能够被用于以下其中一种情形，则用户验证方法被认为是有效的：
向一个用户验证方法注册新的验证参考数据。 或者
成功验证用户以后，直接解锁用户认证密钥。
keyProtection类型为 required unsigned short
16位的数字，代表FIDO注册表预定义值[UAFRegistry]中的KEY_PROTECTION常数定义的位字段。 该值必须不为0。
matcherProtection类型为 required unsigned short
16位的数字，代表FIDO注册表预定义值[UAFRegistry]中的MATCHER_PROTECTION常数定义的位字段。 该值必须不为0。
注释
如果实现了多个匹配器，那么该值必须反映所有匹配器中最弱的实现。
attachmentHint类型为 required unsigned long
32 位的数字，代表 FIDO 注册表预定义值[UAFRegistry]中的ATTACHMENT_HINT常数定义的位字段。
注释
认证器的连接状态和拓扑结构可能是瞬时的，并且不能作为权威的被依赖方 信赖，但是元数据字段应该含有认证器所有可能的拓扑结构的位标记集。例如，一个认证器是一个通过蓝牙通信的单一目的的硬件令牌，应该设为ATTACHMENT_HINT_EXTERNAL，而不是 ATTACHMENT_HINT_INTERNAL。
isSecondFactorOnly类型为 required Boolean 
指示认证器是否被设计来只能用作是第二因子，例如，需要一些其他的认证方式作为第一因子（比如，用户名+口令）。
tcDisplay类型为 required unsigned short
16位的数字，代表 FIDO 注册表预定义值[UAFRegistry]中的TRANSACTION_CONFIRMATION_DISPLAY常数定义的位字段。如果认证器不支持交易确认，该值必须设为 0。
tcDisplayContentType类型为 DOMString
交易确认显示支持的 MIME 内容类型[RFC2049]，例如text/plain 或 image/png。 如果支持交易确认，该值必须出现。例如，tcDisplay不为0。
tcDisplayPNGCharacteristics类型为 DisplayPNGCharacteristicsDescriptor 数组
 一个备选的 DisplayPNGCharacteristicsDescriptor 列表。每一个条目都是一个备选的支持图片特性，用来显示PNG 图片。如果支持交易确认，该列表必须出现，例如，tcDisplay不为0。
attestationRootCertificates类型为 required DOMString 数组 
该数组中的每一个元素都代表一个该 AAID 有效的 PKIX[RFC5280]信任的X.509根证书。多个证书可能被相同的 AAID 的不同批次使用。数组并不代 表一个证书链，而是仅仅代表这个链的信任锚。
每一个数列元素都是 Base64 编码（[RFC4648]第 4 章）、DER 编码[ITU- X690-2008]的 PKIX 证书值。每一个元素必须是认证器鉴证专用的。
注释
这里列出的证书是信任根。它可能是认证器显示的真实证书，或者它可能是一个从供应商得到的签发机构证书，认证器真正使用的证书与其相链接。
注册断言包括鉴证证书本身和有序的证书链（见[UAFAuthnrCommands]）。
制造商鉴证根证书或与特定 AAID 相关的根证书都必须在此处规定。
当（a）一个根证书可能覆盖多个认证器类型（例如，多个 AAID）。这种情况下，在鉴证证书的 SubjectDN CommonName (oid 2.5.4.3)项中必须规定AAID。当（b）根证书仅仅覆盖单一AAID，鉴证证书的SubjectDN CommonName 项中不要求包含AAID。 在备选的基础鉴证（见[UAFProtocol]，“替代的基础鉴证”章节）的情况下，不需要或使用鉴证根证书。因此，在这种情况下该数组必须为空。
icon类型为 required DOMString
认证器的data:url[RFC2397]编码的 PNG[PNG]图标。

5. 元数据声明格式

规范
FIDO认证器元数据声明是一个包含 JSON 编码的 MetadataStatement 结构文档。

5.1 UAF例子

UAF认证器元数据声明的示例：

（1）authenticatorVersion（认证器版本）是 2。
（2）基于指纹的用户验证，允许多达5个已登记的手指，错误接受率为0.002％，5次虚假试验后的速度限制尝试30秒。
（3）认证器集成在 FIDO 用户设备中。
（4）鉴别密钥在可信执行环境中保护并且仅限于签署有效的FIDO标志声明。
（5）(指纹)匹配器在可信执行环境中实现。
（6）交易确认显示在可信执行环境中实现。
（7）交易确认显示仅支持“image/png”对象的显示。
（8）显示宽 320 像素，高 480 像素。每个像素提供 16 位位深的真彩色（=Color Type 2）。Zlib压缩方式（0）。不支持过滤（例如，filter typeof= 0）并 且不支持交错（interlace method = 0）。
（9）该认证器可当作是第一因子或者第二因子，例如，isSecondFactorOnly=false。
（10）支持“UAFV1TLV”断言方案。
（11）使用 UAF_ALG_SIGN_ECDSA_SHA256_RAW鉴别算法。
（12）使用 UAF_ALG_KEY_ECC_X962_RAW公钥格式（0x100=256 十进制）。
（13）只实现了 TAG_ATTESTATION_BASIC_FULL方法（0x3E07=15879 十进制）。
（14）实现了 UAF 协议1.0 和1.1版本。

EXAMPLE 1: MetadataStatement for UAF Authenticator{ "aaid": "1234#5678",  "description": "FIDO Alliance Sample UAF Authenticator",  "authenticatorVersion": 2,  "upv": [{ "major": 1, "minor": 0 }, { "major": 1, "minor": 1 }],  "assertionScheme": "UAFV1TLV",  "authenticationAlgorithm": 1,  "publicKeyAlgAndEncoding": 256,  "attestationTypes": [15879],  "userVerificationDetails": [ [ { "userVerification": 2, "baDesc":             { "FAR": 0.00002, "maxRetries": 5, "blockSlowdown": 30, "maxReferenceDataSets": 5 } } ] ],  "keyProtection": 6,  "isKeyRestricted": true,  "matcherProtection": 2,  "attachmentHint": 1,  "isSecondFactorOnly": "false",  "tcDisplay": 5,  "tcDisplayContentType": "image/png",  "tcDisplayPNGCharacteristics": [{"width": 320, "height": 480, "bitDepth": 16,        "colorType": 2, "compression": 0, "filter": 0, "interlace": 0}],  "attestationRootCertificates": ["MIICPTCCAeOgAwIBAgIJAOuexvU3Oy2wMAoGCCqGSM49BAMCMHsxIDAeBgNVBAMMF1NhbXBsZSBBdHRlc3RhdGlvbiBSb290MRYwFAYDVQQKDA1GSURPIEFsbGlhbmNlMREwDwYDVQQLDAhVQUYgVFdHLDESMBAGA1UEBwwJUGFsbyBBbHRvMQswCQYDVQQIDAJDQTELMAkGA1UEBhMCVVMwHhcNMTQwNjE4MTMzMzMyWhcNNDExMTAzMTMzMzMyWjB7MSAwHgYDVQQDDBdTYW1wbGUgQXR0ZXN0YXRpb24gUm9vdDEWMBQGA1UECgwNRklETyBBbGxpYW5jZTERMA8GA1UECwwIVUFGIFRXRywxEjAQBgNVBAcMCVBhbG8gQWx0bzELMAkGA1UECAwCQ0ExCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEH8hv2D0HXa59/BmpQ7RZehL/FMGzFd1QBg9vAUpOZ3ajnuQ94PR7aMzH33nUSBr8fHYDrqOBb58pxGqHJRyX/6NQME4wHQYDVR0OBBYEFPoHA3CLhxFbC0It7zE4w8hk5EJ/MB8GA1UdIwQYMBaAFPoHA3CLhxFbC0It7zE4w8hk5EJ/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAwRQIhAJ06QSXt9ihIbEKYKIjsPkriVdLIgtfsbDSu7ErJfzr4AiBqoYCZf0+zI55aQeAHjIzA9Xm63rruAxBZ9ps9z2XNlQ=="],  "icon": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAvCAYAAACiwJfcAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAahSURBVGhD7Zr5bxRlGMf9KzTB8AM/YEhE2W7pQZcWKKBclSpHATlELARE7kNECCA3FkWK0CKKSCFIsKBcgVCDWGNESdAYidwgggJBiRiMhFc/4wy8884zu9NdlnGTfZJP2n3nO++88933fveBBx+PqCzJkTUvBbLmpUDWvBTImpcCSZvXLCdX9R05Sk19bb5atf599fG+/erA541q47aP1LLVa9SIyVNUi8Ii8d5kGTsi30NFv7ai9n7QZPMwbdys2erU2XMqUdy8+ZcaNmGimE8yXN3RUd3a18nF0fUlovZ+0CTzWpd2Vj+eOm1bEyy6Dx4i5pUMGWveo506q227dtuWBIuffr6oWpV0FPNLhow1751Nm21LvPH3rVtWjfz66Lfql8tX7FRl9YFSXsmSseb9ceOGbYk7MNUcGPg8ZsbMe9rfQUaaV/JMX9sqdzDCSvp0kZHmTZg9x7bLHcMnThb16eJ+mVfQq8yaUZQNG64iXZ+0/kq6uOZFO0QtatdWKfXnRQ99Bj91R5OIFnk54jN0mkUiqlO3XDW+Ml+98mKB6tW7rWpZcPc+0zg4tLrYlUc86E6eGDjIMubVpcusearfgIYGRk6brhZVr/JcHzooL7550jedLExopWcApi2ZUqhu7JLvrVsQU81zkzOPeemMRYvVuQsX7PbiDQY5JvZonftK+1VY8H9utx530h0ob+jmRYqj6ouaYvEenW/WlYjp8cwbMm682tPwqW1R4tj/2SH13IRJYl4moZvXpiSqDr7dXtQHxa/PK3/+BWsK1dTgHu6V8tQJ3bwFkwpFrUOQ50s1r3levm8zZcq17+BBaw7K8lEK5qzkYeark9A8p7P3GzDK+nd3DQow+6UC8SVN82iuv38im7NtaXtV1CVq6Rgw4pksmbdi3bu2De7YfaBBxcqfvqPrUjFQNTQ22lfdUVVT68rTJKF5DnSmUjgdqg4mSS9pmsfDJR3G6ToH0iW9aV7LWLHYXKllTDt0LTAtkYIaamp1QjVv++uyGUxVdJ0DNVXSm+b1qRxpl84ddfX1Lp1O/d69tsod0vs5hGre9xu8o+fpLR1cGhNTD6Z57C9KMWXefJdOZ94bb9oqd1ROnS7qITTzHimMqivbO3g0DdVyk3WQBhBztK35YKNdOnc8O3acS6fDZFgKaXLsEJp5rdrliBqp89cJcs/m7Tvs0rkjGfN4b0kPoZn3UJuIOrnZ22yP1fmvUx+O5gSqebV1m+zSuYNVhq7TWbDiLVvljplLlop6CLXP+2qtvGLIL/1vimISdMBgzSoFZyu6Tqd+jzxgsPaV9BCqee/NjYk6v6lK9cwiUc/STtf1HDpM3b592y7h3Thx5ozK69HLpYWuAwaqS5cv26q7ceb8efVYaReP3iFU8zj1knSwZXHMmnCjY0Ogalo7UQfSCM3qQQr2H/XFP7ssXx45Yl91ByeCep4moZoH+1fG3xD4tT7x8kwyj8nwb9ev26V0B6d+7H4zKvudAH537FjqyzOHdJnHEuzmXq/WjxObvNMbv7nhywsX2aVsWtC8+48aLeapE7p5wKZi0A2AQRV5nvR4E+uJc+b61kApqInxBgmd/4V5QP/mt18HDC7sRHftmeu5lmhV0rn/ALX232bqd4BFnDx7Vi1cWS2uff0IbB47qexxmUj9QutYjupd3tYD6abWBBMrh+apNbOKrNF1+ugCa4riXGfwMPPtViavhU3YMOAAnuUb/R07L0yOSeOadE88ApsXFGff30ynhlJgM51CU6vN9EzgnpvHBFUyiVraePiwJ53DF5ZTZnomENg85kNUd2oJi2Wpr4OmmkfN4x4zHfiVFc8Dv8NzuhNqOidilGvA6DGueZwO78AAQn6ciEk6+rw5VcvjvqNDYPOoIUwaKShrxAuXLlkH4aYuGfMYDc10WF5Ta31hPJOfcUhrU/JlINi6c6elRYdBpo6++Yfjx61lGNfRm4MD5rJ1j3FoGHnjDSBNarYUgMLyMszKpb7tXpoHfPs8h3Wp1LzNfNk54XxC1wDGUmYzXYefh6z/cKtVm4EBxa9VQGDzYr3LrUMRjHEKkk7zaFKYQA2hGQU1z+85NFWpXDrkz3vx10GqxQ6BzeNboBk5n8k4nebRh+k1hWfxTF0D1EyWUs5nv+dgQqKaxzuCdE0isHl02NQ8ah0mXr12La3m0f9wik9+wLNTMY/86MPo8yi31OfxmT6PWoqG9+DZukYna56mSZt5WWSy5qVA1rwUyJqXAlnzkiai/gHSD7RkTyihogAAAABJRU5ErkJggg=="}

认证器的User Verification Methods方法示例：
（1）基于指纹的用户验证方法，具有：
能够为用户注册最多5个手指（参考数据集）的能力
每个手指的错误接受率为0.002%。FAR为0.01%。
5次不成功的尝试后指纹认证将被阻止
（2）必须设置最小长度为4位十进制数的PIN码作为替代验证方法。输入PIN后，需要重新启用指纹用户验证后才能被锁定。

EXAMPLE 2: User Verification Methods Entry[  [ { "userVerification": 2, "baDesc": { "FAR": 0.00002, "maxReferenceDataSets": 5,                            "maxRetries": 5, "blockSlowdown": 0} }],  [ { "userVerification": 4, "caDesc": { "base": 10, "minLength": 4 } } ]]

5.2 U2F例子

U2F认证器元数据声明的示例：

（1）authenticatorVersion（认证器版本）是 2。
（2）基于触摸的用户状态检查。
（3）认证器是一个可插拔的USB硬件令牌
（4）认证的Key被安全保护
（5）用户状态的检查在芯片中被实现
（6）认证器是一个纯第二因子认证器
（7）支持"U2FV1BIN"断言方案
（8）使用ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW 认证算法
（9）使用ALG_KEY_ECC_X962_RAW的公钥格式
（10）只实现了 TAG_ATTESTATION_BASIC_FULL方法（0x3E07=15879 十进制）。
（11）仅实现了U2F 1.0协议

EXAMPLE 3: MetadataStatement for U2F Authenticator{ "description": "FIDO Alliance Sample U2F Authenticator",  "attestationCertificateKeyIdentifiers": ["7c0903708b87115b0b422def3138c3c864e44573"],  "protocolFamily": "u2f",  "authenticatorVersion": 2,  "upv": [{ "major": 1, "minor": 0 }],  "assertionScheme": "U2FV1BIN",  "authenticationAlgorithm": 1,  "publicKeyAlgAndEncoding": 256,  "attestationTypes": [15879],  "userVerificationDetails": [ [ { "userVerification": 1} ] ],  "keyProtection": 10,  "matcherProtection": 4,  "attachmentHint": 2,  "isSecondFactorOnly": "true",  "tcDisplay": 0,  "attestationRootCertificates": ["MIICPTCCAeOgAwIBAgIJAOuexvU3Oy2wMAoGCCqGSM49BAMCMHsxIDAeBgNVBAMMF1NhbXBsZSBBdHRlc3RhdGlvbiBSb290MRYwFAYDVQQKDA1GSURPIEFsbGlhbmNlMREwDwYDVQQLDAhVQUYgVFdHLDESMBAGA1UEBwwJUGFsbyBBbHRvMQswCQYDVQQIDAJDQTELMAkGA1UEBhMCVVMwHhcNMTQwNjE4MTMzMzMyWhcNNDExMTAzMTMzMzMyWjB7MSAwHgYDVQQDDBdTYW1wbGUgQXR0ZXN0YXRpb24gUm9vdDEWMBQGA1UECgwNRklETyBBbGxpYW5jZTERMA8GA1UECwwIVUFGIFRXRywxEjAQBgNVBAcMCVBhbG8gQWx0bzELMAkGA1UECAwCQ0ExCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEH8hv2D0HXa59/BmpQ7RZehL/FMGzFd1QBg9vAUpOZ3ajnuQ94PR7aMzH33nUSBr8fHYDrqOBb58pxGqHJRyX/6NQME4wHQYDVR0OBBYEFPoHA3CLhxFbC0It7zE4w8hk5EJ/MB8GA1UdIwQYMBaAFPoHA3CLhxFbC0It7zE4w8hk5EJ/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAwRQIhAJ06QSXt9ihIbEKYKIjsPkriVdLIgtfsbDSu7ErJfzr4AiBqoYCZf0+zI55aQeAHjIzA9Xm63rruAxBZ9ps9z2XNlQ=="],

6. 其他的考虑

6.1  字段更新和元数据
元数据声明一旦发布以后应该是稳定的。当认证器的字段中有更新，这样的更新预计将提高认证器安全性（例如，改良误识率或误拒率）。如果有能解决严 重的安全问题（例如，之前报告的）固件的更新可用，authenticatorVersion必须更新。

注释

元数据声明假定为与拥有相同 AAID 的所有认证器相关。
注释
如果元数据声明中规定的 authenticatorVersion比认证器中显示的新（高），建 议 FIDO 服务器假定风险提高了。

规范

认证器功能的重要变化不在固件更新的范畴中。例如，如果认证供应商想要修改基于 PIN 的认证器来使用“人声识别”作为用户验证方式，那么供应商必 须为该认证器分配一个新的AAID。

规范
一个单一的认证器的实现可以报告它自己是两个使用不同 AAID 的“虚拟”认证器。这样的实现必须妥善保护 UAuth密钥以及其他敏感数据不被其他“虚 拟”认证器访问，如同一个普通认证器所做的。

注释
为一个 AAID 注册的鉴别密钥（UAuth.pub）不能被申报了不同 AAID 的认证器使用，即使运行的硬件相同（参考[UAFProtocol]的“FIDO 服务器鉴别响应 处理规则”章节）。