1. 介绍
开放屏幕网络协议为浏览器和设备彼此发现并建立安全网络 连接提供了一组基线网络协议。此连接可用作 开放屏幕应用协议的传输层。
应用协议和网络协议是相互独立的。不过， 网络协议的设计旨在满足应用协议的要求。它可能适合，也可能不适合 使用其传输层的其他应用层协议。
网络协议的基本流程是：
-
使用 DNS-SD，使代理在局域 网中彼此发现。
-
使用带有自签名证书的 TLS 1.3 来建立 初始的、未经认证的连接。
-
使用 SPAKE2 来验证相互身份并 交换 证书。
-
使用 QUIC 作为 IP 之上的传输层。
附录 C：完整流程图中的流程图说明了整个事件序列。
随附的 解释文档提供了 有关该协议的更多背景。
1.1. 术语
开放屏幕网络 协议代理（或 OSP agent）是此协议的任何实现 （浏览器、显示器、扬声器或其他软件）。
2. 要求
2.1. 通用要求
-
开放屏幕网络协议代理必须能够 发现连接到同一 IPv4 或 IPv6 子网且可通过 IP 多播到达的另一个 OSP agent 的存在。
-
OSP agent 必须能够获取该代理的 IPv4 或 IPv6 地址、 该代理的显示名称，以及用于 与该代理建立网络传输的 IP 端口号。
2.2. 非功能性要求
-
应当能够使用适中的硬件要求实现开放屏幕网络协议， 类似于低端智能手机、 智能电视或流媒体设备中的硬件。有关代理硬件规格，请参见 设备 规格 文档。
-
发现和连接协议应尽量降低功耗， 尤其是在可能由电池供电的侦听代理上。
-
该协议应尽量减少向被动 网络观察者提供有关用户身份或代理上活动的信息，包括 演示、远程播放或媒体流内容。
-
该协议应防止主动网络攻击者冒充 显示器，并观察或篡改原本发往控制器或 接收器的数据。
-
当通告代理变为可用 或不可用时（即连接到网络或 从网络断开时），侦听代理应能够快速发现。
-
代理应能够记住用户已经认证过另一个代理。 这意味着，当代理想要连接到用户已经 认证过的代理时，不要求用户每次都介入并重新认证。
-
应尽量降低代理之间的消息延迟，以允许交互式 使用。例如，应当可以舒适地在一个代理中的表单内输入， 并让文本实时出现在演示中。面向游戏或鼠标使用的实时 延迟是理想目标，但不是要求。
3. 使用 mDNS 发现
开放屏幕网络协议代理通过通告和 侦听标识自身的信息以及 IP 服务 端点来彼此发现。通过 DNS-SD 和 mDNS 进行代理通告和发现由本 规范定义，并且所有代理都必须实现。 不过，代理可以自由实现其他发现 机制，例如通过单播 DNS 查询相同的 DNS-SD 记录。
OSP agent 必须使用 DNS-SD 服务名称
_openscreen._udp。
通告代理
是响应针对 _openscreen._udp.local 的 mDNS 查询的代理。
这样的代理应具有一个 显示
名称（非空字符串），它是对
演示显示器的人类可读描述，例如“客厅电视”。
侦听代理
是发送针对
_openscreen._udp.local 的 mDNS 查询的代理。侦听代理可以具有显示名称。
通告代理必须使用 DNS-SD 实例
名称，且该名称是
代理显示名称的前缀。如果实例名称不是完整显示名称，
它必须以 null（\000）字符结束，以便侦听代理知道
它已被截断。
通告代理必须遵循 mDNS 冲突 解决过程，以 防止多个通告代理使用相同的 DNS-SD 实例名称。
代理在向用户显示实例名称时应谨慎；有关实例名称显示的指南，请参见 § 7.4.1 实例名称和显示名称。
通告代理必须包含带有以下 键和值的 DNS TXT 记录：
- fp
-
通告代理的代理 指纹。计算 代理指纹的步骤定义如下。
- mv
-
一个无符号整数值，表示元数据已更改。 通告代理必须将其更新为更大的值。这会向 侦听代理发出信号，表示它应连接到通告代理以发现 更新后的元数据。该值应编码为 变长整数。
- at
-
一个由集合
[A-Za-z0-9+/]中的字符组成的字母数字、不可猜测令牌。
注： at 防止局域网外的各方
尝试认证；请参见
§ 7.3.3 远程主动网络攻击者。at 应
具有至少 32 位真实
熵，以使暴力攻击不切实际。
注： 如果 OSP agent 暂停其网络连接 （例如出于节能 原因），它应尝试保留缓存且有效的 mDNS 记录，以便 在网络连接恢复时保留发现状态。
此基于 QUIC 的协议的未来扩展可以使用相同的元数据 发现过程，通过一种待确定的 能力机制来表示对这些扩展的支持。如果开放屏幕 网络协议的未来版本使用 mDNS 但破坏与元数据发现过程的兼容性， 它应将 DNS-SD 服务名称更改为一个新值，以表示新的 元数据发现机制。
3.1. 计算代理指纹
代理的 代理指纹 通过遵循以下 步骤计算：
注： 得到的字符串长度为 44 字节。
3.2. 计算证书序列号
令 证书 序列号为以下 步骤的结果：
-
如果代理从未生成过代理证书：
- 令 证书序列号基值为一个 128 位 UUID。
- 令 证书序列号计数器为一个 32 位 无符号整数，初始设置为 0。
- 按如下方式生成一个 160 位值：
3.3. 计算代理主机名
每次代理更改其 DNS-SD 服务 实例名称或 证书 序列号时，它都必须按 如下方式计算 代理主机名。
-
将 encodedInstanceName 设置为以下结果：
-
将 DNS-SD 实例名称中除
[A-Za-z0-9-]之外的任何字符替换为连字符-。
-
-
将 encodedDomain 设置为以下结果：
-
将 DNS-SD 域名中除
[A-Za-z0-9-]之外的任何字符替换为连字符-。
-
-
将代理主机名 设置为字符串 base64SerialNumber +
.+ encodedInstanceName +.+ encodedDomain
TODO：添加一个附录，其中包含通告代理的元数据、DNS-SD 记录和证书 字段示例。
4. 使用 QUIC 进行传输和元数据发现
如果侦听代理想要 连接到通告代理或了解其更多元数据， 它会向其 SRV 记录中的 IP 和端口发起 QUIC 连接。在认证之前，可以交换消息 （例如进一步的元数据），但此类信息应被视为未经验证（例如 向用户表明未经认证代理的显示名称 未经验证）。
双方代理使用的连接 ID 应为零长度。如果选择了零长度 连接 ID，则代理在不建立新的 QUIC 连接的情况下， 受到限制，不能更改 IP 或端口。在这种情况下，代理必须 建立新的 QUIC 连接以更改 IP 或端口。
4.1. TLS 1.3
当 OSP agent 与另一个代理建立 QUIC 连接时， 它必须使用 TLS 1.3 来保护连接。 TLS 1.3 应使用以下 应用特定参数，以表明该连接将用于 通过 OSP 与特定 OSP agent 通信。OSP agent 可以 拒绝缺少这些参数的传入连接。
-
使用的 ALPN 必须是 "osp"。
-
server_name 扩展必须设置为代理主机名。
OSP agent 不得发送 TLS early data。
向 IANA 注册 ALPN。 [Issue #228]
4.2. 代理证书
每个 OSP agent 必须生成一个 X.509
v3 代理
证书，其中包含一个用于 TLS 1.3
证书交换的公钥。通告代理和侦听代理在建立
QUIC 连接时，都必须在 TLS 1.3 Certificate 消息中
使用代理
证书。
代理证书 必须具有以下特征：
-
256 位 ECDSA 公钥。
-
自签名。
-
支持 TLS 1.3 中定义的
ecdsa_secp256r1_sha256签名方案。 -
可用于签名。
每个代理证书都有一个唯一的证书序列号，该序列号
使用上述步骤计算。下面的值 <sn> 应替换为该
序列号。
以下 X.509 v3 字段应按如下方式设置：
| 字段 | 值 |
|---|---|
| 版本号 | 3 |
| 序列号 | <sn>（作为大端整数）
|
公钥 AlgorithmIdentifier
|
|
签名 AlgorithmIdentifier
|
|
| 颁发者名称 | CN = 来自 agent-info 消息的 model-name，
也设置在 agent-info 消息中。O = 见注释。 L = 见注释。 ST = 见注释。 C = 见注释。 |
| 主体名称 | CN = 代理
主机名 O = 见注释。 |
| 主体公钥算法 | 椭圆曲线公钥 |
| 证书密钥用途 | digitalSignature |
上面未提及的必填字段应根据 [RFC5280] 设置。
注： OSP agent 可以使用实现者或设备
型号名称作为 O 键的值，用于用户界面和调试目的。它可以使用代理
实现者或设备制造商的位置作为位置
键（L、ST 和 C）的值，用于用户界面和调试目的。
如果 OSP agent 看到一个尚未通过 § 6 身份认证验证的代理证书，它必须将该代理视为未经验证， 并在允许与该代理交换更多消息之前， 启动与该代理的认证。
如果 OSP agent 看到一个已通过认证验证的有效代理证书， 则在发送更多消息之前，不要求它 与该代理启动认证。
如果侦听代理希望从通告代理接收消息，或 通告代理希望向侦听代理发送消息，它可能希望 通过定期在连接上发送数据来保持 QUIC 连接处于活动状态。
如果 OSP agent 暂停其网络连接（例如出于节能 原因），它应尝试在网络连接恢复后恢复与先前 连接过的 OSP agent 的 QUIC 连接。
5. 使用 CBOR 和 QUIC 流传递消息
消息使用 CBOR 序列化。为了按顺序发送一组消息， 该组消息必须在一个 QUIC 流中发送。彼此独立的 消息组（组之间没有排序依赖）应在 不同的 QUIC 流中发送。为了将多个 CBOR 序列化消息放入 同一个 QUIC 流，使用以下内容。
注： Open Screen Agents 应配置 QUIC 流 限制（MAX_STREAMS）， 使其不会阻碍应用性能，同时记住音频、视频或数据流用例可能需要的并发 流数量。
对于每条消息，OSP agent 必须向单向 QUIC 流中写入 以下内容：
如果代理接收到一条其不识别类型键的消息， 它必须以应用错误码 404 关闭 QUIC 连接，并且应 在 CONNECTION_CLOSE 帧的原因短语中包含未知类型键。
6. 身份认证
每种支持的认证方法都通过特定于该方法的认证消息 实现。认证方法由消息本身明确指定。 认证状态消息对所有认证 方法通用。添加的任何新认证方法都必须定义新的认证消息。
开放屏幕网络协议代理必须实现 带预共享密钥的 § 6.1 使用 SPAKE2 进行身份认证。
在认证之前，代理会交换 auth-capabilities 消息，指定 用户输入预共享密钥（PSK）的便利程度以及支持的 PSK 输入方法。 当代理发送或接收认证请求时，PSK 输入便利程度最低的代理 会向用户呈现 PSK。如果两个代理具有相同的 PSK 输入便利程度值，则服务器向用户呈现 PSK。两个代理使用相同的预共享密钥。 向用户呈现 PSK 的代理是 PSK 呈现者， 需要用户输入 PSK 的代理是 PSK 消费者。
PSK 输入便利程度是一个 0 到 100（含）范围内的整数，其中 0 表示 用户无法在此设备上输入 PSK，100 表示 用户很容易在该设备上输入 PSK。支持的 PSK 输入方法 是数字输入和扫描 QR-code。具有非零 PSK 输入便利程度的设备必须 支持数字 PSK 输入方法。
任何认证方法都可能需要一个 auth-initiation-token，然后才会
向用户显示 PSK 或请求用户输入 PSK。对于
通告代理，
其 mDNS TXT 记录中的 at 字段必须用作发送给该代理或由该代理发送的
第一条认证消息中的
auth-initation-token。如果认证消息的
auth-initation-token 已设置且不匹配通告代理提供的 at，
代理应丢弃该认证消息。
在 auth-capabilities 消息的
psk-min-bits-of-entropy 字段中，
代理可以指定其要求的 PSK 最小熵位数，
范围为 20 到 60 位（含），默认值为 20。PSK 呈现者必须
生成一个 PSK，其熵位数至少与其在该
字段中接收到的值一样多，并且至少与其在该字段中发送的值一样多。
如果代理选择以多种方式向用户显示 PSK（例如同时显示 QR-code 和数字 PSK），它们应对应同一个 PSK。如果它们 不同，PSK 呈现者将不知道用户选择使用哪一个， 这可能导致认证失败。
附录 C：完整流程图描述了两种 PSK 编码方案，代理 可以 支持这些方案，以生成字符串或QR code供 用户显示。
6.1. 使用 SPAKE2 进行身份认证
[Meta] 跟踪 CFRG PAKE 竞赛结果 [Issue #242]
对于本节中定义的所有消息和对象，请参见 附录 A：消息中的 完整 CDDL 定义。
默认认证方法是 SPAKE2，使用以下 密码套件：
-
椭圆曲线为 edwards25519。
-
哈希函数为 SHA-256。
-
密钥派生函数为 HKDF。
-
消息认证码为 HMAC。
-
密码哈希函数为 SHA-512。
开放屏幕网络协议不会使用内存困难哈希函数来通过 SPAKE2 对 PSK 进行哈希，而是使用 SHA-512，因为 PSK 是一次性使用的，并且 不以任何形式存储。
SPAKE2 提供显式双向认证。
此认证方法假定代理共享一个低熵秘密， 例如可由用户在手机、键盘或电视遥控器上输入的数字或短密码。
SPAKE2 不是对称的，它有两个角色：Alice（A）和 Bob（B）。
此认证方法中使用的消息是：auth-spake2-handshake、 auth-spake2-confirmation 和 auth-status。[SPAKE2] 详细描述了 如何计算 auth-spake2-handshake 和 auth-spake2-confirmation。
SPAKE2 中使用的值 A 和 B 分别是客户端和服务器的
代理指纹。pw
是呈现给用户的 PSK。
PSK 呈现者或 PSK 消费者都可以发起认证（在 SPAKE2 中承担 Alice 角色）。
如果 PSK 呈现者想要发起认证，它会通过向用户呈现 PSK 并发送
auth-spake2-handshake 消息来启动
认证过程。
auth-spake2-handshake 消息的 public-value
字段必须设置为 SPAKE2 中 pA 的值，
并且 psk-status 字段必须设置为 psk-shown。
当 PSK 消费者接收到 auth-spake2-handshake 消息时，如果它尚未提示用户输入 PSK，
则提示用户输入 PSK。一旦它
收到 PSK，就会发送一条 auth-spake2-handshake 消息，其中
public-value 字段设置为 SPAKE2 中 pB 的值，
psk-status
字段设置为 psk-input。
如果 PSK 消费者想要发起认证，则 PSK 消费者向 PSK 呈现者发送一条
auth-spake2-handshake 消息，其中
psk-status
字段设置为 psk-needs-presentation，public-value 字段设置为
pA。PSK 呈现者在收到此消息后，会创建一个 PSK 并将其呈现
给用户。完成后，它会向 PSK 消费者发送一条 auth-spake2-handshake
消息，其中 psk-status 设置为 psk-input，
public-value 字段设置为 pB。
一旦代理从 auth-spake2-handshake 消息中知道
pA 和 pB，它就会计算并向
另一个代理发送 auth-spake2-confirmation，其中
confirmation-value 字段设置为 cA（对于 Alice）或 cB（对于 Bob）。
一旦代理接收到 auth-spake2-confirmation 消息，它会使用 [SPAKE2] 中的过程
验证该消息，然后以一条
auth-status 已认证消息
回复另一个代理。result 的任何值
只要不是 authenticated，就表示认证失败，代理必须
立即断开连接。
注： auth-status 消息仅为资料性消息，因为每个代理 都会通过密钥确认 验证独立计算 SPAKE2 的结果。
附录 C：完整流程图展示了代理彼此尚未 认证时的整个过程，包括发现、QUIC 连接建立、 元数据交换和认证。当代理已完成认证时， 可以省略认证阶段。
7. 安全和隐私
开放屏幕网络协议允许两个 OSP agent 彼此发现并 交换用户和应用数据。因此，应仔细审查其安全和隐私 考量。我们使用 W3C 安全和隐私问卷 评估协议本身，并讨论代理可用于满足这些 安全和隐私要求的建议缓解措施。
7.1. 威胁模型
7.1.1. 被动网络攻击者
开放屏幕网络协议应假定所有连接到同一 LAN 的各方 都能够观察 OSP agent 之间流动的所有数据。
这些各方将能够收集通过未加密 消息暴露的任何数据，例如 mDNS 记录和 QUIC 握手。
这些各方可能尝试通过观察 QUIC 连接上的数据 流，或通过观察密码学计时，来了解密码学参数。
7.1.2. 主动网络攻击者
主动攻击者（例如被攻陷的路由器）将能够操纵 代理之间交换的数据。他们可以向现有 QUIC 连接注入流量，并尝试发起新的 QUIC 连接。这些能力可 用于尝试以下事项：
-
冒充某个代理或用户已经认证的代理，试图 说服用户对其进行认证。
-
连接到代理并查询其能力。
一个特别值得关注的攻击是配置错误或被攻陷的路由器 将本地网络设备（例如 OSP agent）暴露到互联网。恶意方曾使用这种 攻击向量，通过连接到通常无法从互联网访问的本地网络服务， 控制打印机和智能电视。
7.1.3. 拒绝服务
连接到 LAN 的各方可能尝试拒绝对 OSP agent 的访问。例如， 攻击者可能尝试向某个代理打开大量 QUIC 连接， 以阻止合法连接或耗尽代理的系统资源。 他们还可能多播虚假的 DNS-SD 记录，试图 耗尽 mDNS 侦听器的缓存容量，或让侦听器打开 大量虚假的 QUIC 连接。
7.2. 开放屏幕网络协议安全和隐私考量
7.2.1. 个人身份信息和高价值 数据
以下数据无法合理地保密，应被 视为公开数据：
-
开放屏幕网络协议使用的 IP 地址和端口。
-
通过 mDNS 通告的数据，包括显示名称前缀、 证书指纹和序列号，以及元数据版本。
7.2.2. 跨源状态考量
网络协议不直接处理源状态。
7.2.3. 源对其他设备的访问
按照设计，开放屏幕网络协议允许通过使用它的 应用协议，从 Web 访问设备。通过实现该协议， 这些设备明知自己会向 Web 可用，并应据此 进行设计。
下面，我们讨论防止恶意使用这些设备的缓解步骤。
7.2.4. 私密浏览模式
建议用户代理针对同一用户代理实例中的正常浏览和 私密浏览使用不同的认证上下文（参见 § 6 身份认证）和 QUIC 连接（参见 § 4 使用 QUIC 进行传输和元数据发现）。这会使其他设备更难匹配同一用户在正常浏览和私密浏览中 发生的活动。
7.2.5. 持久状态
代理很可能持久化已成功完成 § 6 身份认证的代理身份。这可能包括这些方的公钥指纹、 元数据版本和元数据。
不过，此数据通常不会暴露给 Web，仅通过用户代理在显示选择或显示认证 过程中的原生 UI 暴露。用户代理在用户清除浏览数据时清除此数据还是 保留此数据，可以是一个实现选择。
7.2.6. 其他考量
开放屏幕网络协议不会向 Web 授予对以下内容的额外访问权限：
-
新的脚本加载机制
-
访问用户的位置
-
访问设备传感器
-
访问用户的本地计算环境
-
控制用户代理的原生 UI
-
用户代理的安全特征
7.3. 缓解策略
7.3.1. 本地被动网络攻击者
本地被动攻击者可能尝试使用开放屏幕网络协议收集有关用户活动和 设备能力的数据。解决这一问题的主要策略是数据最小化， 即在用户介入认证发生之前仅暴露不透明的公钥指纹。
被动攻击者还可能尝试计时攻击，以了解 TLS 1.3 QUIC 连接的密码学 参数。TLS 1.3 的应用配置文件要求使用恒定时间密码， TLS 1.3 实现应使用抵抗侧信道攻击的椭圆 曲线签名操作。
7.3.2. 本地主动网络攻击者
本地主动攻击者可能尝试冒充用户通常信任的演示显示器。 开放屏幕网络协议的 § 6 身份认证步骤可防止中间人 在不了解共享秘密的情况下冒充代理。不过，攻击者可能 冒充现有的受信任代理，或一个尚未认证的新发现代理， 并试图说服用户对其进行认证。（此上下文中的信任意味着用户 已完成从其代理到另一个代理的 § 6 身份认证。）
这可通过多种技术结合来解决。第一种是 检测冒充尝试。代理应检测以下 情况，并将满足任一标准的代理标记为 可疑 代理：
-
在并发通告期间，具有不同 IP 端点但公钥指纹发生冲突的代理。
-
显示名称与先前在给定公钥指纹下 通告的名称不同的不受信任代理。
-
认证挑战失败达到一定次数的不受信任代理。
-
通告的显示名称与已受信任代理的显示名称相似的不受信任代理。
第二种是在双向认证期间管理低熵秘密：
-
轮换低熵秘密，以防止暴力攻击。
-
使用递增退避来响应认证挑战，也用于 防止暴力攻击。
-
使用密码学上可靠的熵源来生成共享秘密。
主动攻击者还可能尝试通过注入或修改流量来破坏 QUIC 连接上交换的数据。这些攻击应通过 TLS 1.3 的正确实现来缓解。 有关 TLS 1.3 协议的详细安全分析，请参见 [RFC8446] 的附录 E。
7.3.3. 远程主动网络攻击者
遗憾的是，我们不能依赖网络设备来完全保护 OSP agent， 因为配置错误的防火墙或 NAT 可能会将连接到 LAN 的代理暴露给 更广泛的互联网。OSP agent 应能抵御来自任何 互联网主机的攻击。
通告代理必须在其 mDNS TXT 记录中设置 at 字段，以保护
自身免受局域网外尝试发起 § 6 身份认证的影响，这些尝试
会导致用户烦扰（显示或输入 PSK）以及针对 PSK 的潜在暴力攻击。
7.3.4. 拒绝服务
要完全防止源自用户局域网的拒绝服务攻击 将很困难。OSP agent 可以拒绝新 连接、关闭接收过多消息的连接，或限制 从特定响应者缓存的 mDNS 记录数量，以尝试在此类攻击下 允许现有活动继续进行。
7.3.5. 恶意输入
OSP agent 应能稳健地处理试图利用解析漏洞 攻陷目标设备的恶意输入。
在可能的情况下，OSP agent（包括应用级组件，如内容 和媒体渲染）应使用纵深防御技术，例如 沙盒化， 以防止漏洞获取用户数据或导致 持久利用。
7.4. 用户界面考量
本规范没有对 OSP agent 的安全 相关用户界面提出任何具体要求。不过，在设计这些用户界面时存在重要 考量，因为基于 PSK 的认证要求用户对信任哪些代理作出知情决定。
-
在代理认证另一个设备之前，该代理应明确表明来自该设备的任何数据尚未通过 认证验证。（关于这如何适用于 DNS-SD 实例名称，请参见下文。）
-
可疑代理 应与受信任且不可疑的代理不同地显示， 或根本不显示。
-
认证期间呈现 PSK 的用户界面应在 可信 UI 中完成，且难以伪造。应向用户明确哪个 物理设备正在呈现 PSK。
-
认证期间输入 PSK 的用户界面应在 可信 UI 中完成，且难以伪造。
-
应要求用户采取操作来输入 PSK，以防止 用户盲目点击通过此步骤。
-
渲染和输入 PSK 的用户界面应符合无障碍 指南。
7.4.1. 实例名称和显示名称
由于 DNS-SD 实例名称是用户在认证前看到的主要信息， 因此必须谨慎呈现这些名称。
重写措辞，不要将 DNS-SD 与 agent-info（一个应用 消息）关联。 [Issue #346]
代理必须将实例名称视为未经验证的信息，并且应检查
实例名称是否是成功 QUIC 连接后通过
agent-info 消息接收到的显示名称的前缀。一旦
代理完成此检查，它就可以将该名称显示为已验证
显示名称。
代理应仅向用户显示完整显示名称，而不是来自 DNS-SD 的截断 显示名称。截断显示名称应按上述方式验证， 然后再作为已验证显示名称完整显示。
- 截断且未经验证的 DNS-SD 实例名称，不应显示 给用户。
- 完整但未经验证的 DNS-SD 实例名称，可在 § 6 身份认证之前显示为未经验证。
- 已验证显示名称。
附录 A：消息
以下消息使用简明数据 定义语言语法定义。使用整数键时，会在该行后附加注释， 用于说明字段名称。本规范中的对象定义采用 这种不寻常的语法，以减少线上字节数，同时保留 每个键的人类可读名称。使用整数键而不是对象 数组，可便于对可选字段进行索引。
每个根消息（即可以放入 QUIC 流而无需被另一条消息包裹的消息） 都有一条注释，用于指示消息类型键。
较小的数字应保留给更频繁发送的消息， 或非常小的消息，或两者兼具的消息；较大的数字应保留给 发送频率较低或较大，或两者兼具的消息，因为较小的类型键在线上编码更小。
; type key 1001 auth-capabilities = { 0: uint ; psk-ease-of-input 1: [* psk-input-method] ; psk-input-methods 2: uint ; psk-min-bits-of-entropy } psk-input-method = &( numeric: 0 qr-code: 1 ) auth-initiation-token = { ? 0: text ; token } auth-spake2-psk-status = &( psk-needs-presentation: 0 psk-shown: 1 psk-input: 2 ) ; type key 1003 auth-spake2-confirmation = { 0: bytes .size 64 ; confirmation-value } auth-status-result = &( authenticated: 0 unknown-error: 1 timeout: 2 secret-unknown: 3 validation-took-too-long : 4 proof-invalid: 5 ) ; type key 1004 auth-status = { 0: auth-status-result ; result } ; type key 1005 auth-spake2-handshake = { 0: auth-initiation-token; initiation-token 1: auth-spake2-psk-status ; psk-status 2: bytes ; public-value }
附录 B：PSK 编码方案
以下附录描述了两种 PSK 编码方案，它们接受长度在
20 位到 80 位之间的值 P，并生成字符串或
QR code
供用户显示。
代理应使用这些编码方案，以最大化 认证步骤的互操作性；该步骤通常要求在一个 设备上显示 PSK，并由用户在另一个设备上输入它。
Base-10 数字
要将 P 编码为数字字符串，请遵循以下步骤：
-
将
P转换为 base-10 整数N。 -
如果
N少于 9 位数字：-
在
N左侧用3 - len(N) mod 3位数字补零。 -
以三位一组输出
N，组之间用短横线分隔。
-
-
如果
N多于 9 位数字：-
在
N左侧用4 - len(N) mod 4位数字补零。 -
以四位一组输出
N，组之间用短横线分隔。
-
要将字符串 N 解码为 PSK P，请遵循以下步骤：
-
移除
N中的短横线和前导零。 -
将
N解析为 base-10 十进制数，以获得P。
注： 大约在 2^30
到 2^40 之间的 P 值将产生长度在
10 到 12 位之间的值。超过 12 位的值不便输入，
且额外安全价值有限。
注： 此处不允许使用十六进制编码， 因为它会 与 base-10 数字编码产生歧义，并且并非所有设备都支持 字母数字输入。
QR Code
要将 PSK 编码为 QR code，请遵循以下步骤：
-
将
N设置为P转换为 ASCII 编码的十六进制字符串后的值。 -
使用
N的值构造一个文本 QR code。
给定 QR code，要将其解码为 PSK P，请遵循以下步骤：
-
通过解码 QR code 获得字符串
N。 -
将
N解析为十六进制数，以获得P。
附录 C：完整流程图
本节为非规范性内容。