主题
数字身份与凭证
在主题维度下，数字身份与凭证主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
IETF
证明通过之后，谁对标签负责？
密钥透明可以证明目录给出的答案前后一致，却不能替组织决定谁有权改、谁可以查、谁必须在明天继续监测。IETF 最新审查退回的，正是这条藏在密码学成功之后的责任边界。
案例档案
签名能证明谁说了什么，却不能替资源服务器决定现在该做什么：RFC 9701
一份 JWT 内省响应可以把授权服务器、接收方和签发时刻牢牢绑定在同一组字节上。它仍只是决策输入：令牌是否适用于本次操作、证明是否抗重放、数据能否披露、请求是否执行成功，都有各自的权力边界。只有逐层保存收据，系统才能说明一次“允许”究竟来自谁，又在哪一层真正生效。
IETF
证书变小了，信任判断没有
证书变小了，信任判断没有 的情报摘要说明事态进展、可核验的公开证据、相关组织、区域背景、市场风险敞口，以及可能带来的基础设施影响。IETF情报 语境将这一信号与网络运营、服务商策略、治理决策、资本流动、客户依赖、监管压力、合作关系动向、韧性规划、采购风险和服务连续性联系起来。
IETF
证书仍覆盖这个号码，不代表这通电话值得信任
STIR 的 OCSP 扩展解决的是一个常被忽略的窄问题：证书没有被撤销时，来电号码是否仍在它的授权范围内。它给验证方增加了一张更及时的回执，却没有替运营商判断来电者是谁、意图如何，更没有替用户决定是否照办。
案例档案
算法名称没变，证据却被“规范化”掉了：RFC 9688 的参数存在性边界
一次归档迁移可以在不改动 OID、不改动密钥、也不改动界面标签的情况下，改变一份 CMS 对象的协议含义。关键不在 SHA3 这个名字，而在解码器最容易抹平的细节：参数字段究竟应当缺席、应当出现 `NULL`，还是必须携带一段精确的 customization 字节。
IETF
没有标准冲突，不等于工厂密钥有了安全评级
IESG 已确认，一份关于制造商预置密钥与信任锚的 IRTF 分类法不存在阻碍发布的标准冲突。它解决的是发布路径问题。五种制造方法谁更安全、某批设备的私钥是否真的未曾外泄，仍须另行举证。
IETF
一个收件人解开了 JWE，收件人策略却仍未完成
多收件人 JWE 可以在一条路径验证成功后交出明文。HPKE 新规范把这条成功路径说得很清楚，但“有人能解开”与“所有必须接收的人都能解开、且每条路径都符合组织政策”仍是两项不同结论。
IETF
SATP 最终回执很清晰，断开的却是可移植恢复链
一笔跨网络资产转移结束时，SATP 能留下签名完整、前后相扣的网关消息。若网关在不可逆阶段崩溃，替代进程应从哪个持久状态继续，却还不能仅凭这套共同协议回答。
案例档案
日历没有新增事件，不代表自动化失败：RFC 9671 的安全拒绝边界
RFC 9671 让 Sieve 能处理邮件中的日历附件，也让 `:updatesonly` 明确拒绝不存在的 UID。对管理者而言，真正重要的不是“是否采取动作”，而是系统能否证明为什么应当改变、为什么必须拒绝，以及最终留下了什么状态。
案例档案
state 已经前进，接收者仍然不能执行那项操作
RFC 9670 为 JMAP 共享建立了统一的数据模型，却没有把所有数据类型压成同一种权限。`shareWith` 写入成功、state 更新和 `myRights` 返回，都只能证明各自那一层；真正的访问结果仍要用接收者的实际操作来闭环。
Number Resource Society
RIPE NCC 通行密钥双因素验证：一段文档标题如何被误读为台湾机构
RIPE NCC 两步验证支持文档中的小节标题“Setting up 2FA with Passkey”曾被一条名录流水线误读为一家台湾机构。标题背后的真实情况，是一套记录完整的通行密钥注册流程：它保护的是管理 LIR Portal 与 RPKI 的 RIPE NCC Access 单点登录账户，而名录上的 TW 地区标签只是 ISO 3166-1 国家标注产生的分类痕迹，并非出版方归属。
IETF
证书已经签发，交付链仍未闭合
RFC 9538 让下游 CDN 在不接触上游长期私钥的情况下取得自己的证书密钥。这解决了证书授权，却没有替 DNS 指向、边缘部署、TLS 选择、内容正确性和用户请求签收。
案例档案
RFC 9646：HTTP 400 可以索取 CSR，却不能授予设备身份
零接触上线面板亮起红灯，因为设备收到 `400 Bad Request`。但在 RFC 9646 的流程里，这条响应可能正是服务器发出的下一步工作单：请选择这套密钥算法，生成这种格式的证书签名请求，再提交第二次调用。红色状态描述了 HTTP；它没有裁定设备是否应获得生产身份。
案例档案
RFC 9645：配置给出四条认证路径，却没有证明会话走了哪一条
一棵配置树可以同时容纳证书、裸公钥、TLS 1.2 预共享密钥和 TLS 1.3 外部 PSK。对控制平面而言，这些都是合法分支；对一次真实连接而言，只会有一条路径被执行，或者走入证据结构完全不同的会话恢复。事故复盘若只得到“已配置 TLS 身份”，拿到的仍是菜单，不是答案。
案例档案
RFC 9644 之后：谁能证明 SSH 会话实际选择了什么
一次 SSH 算法策略变更完成后，领导者真正需要的往往不是最长的合规报告，而是最短且经得起追问的一句话：这次操作是否确实使用了获准的算法、连接到预期对端，并得到预期结果？IANA 注册表、实现能力清单和已接受的配置各能回答其中一部分。RFC 9644 让这些意图更容易一致表达，却没有替运行中的会话作出结论。
案例档案
配置已恢复，密钥权力仍未恢复：RFC 9642
RFC 9642 用共同的 YANG 模型描述中央或内联密钥、证书、加密值与内建密钥。恢复工具能把树写回目标设备，却不能由此证明 KEK 依赖已经闭合、消费者选中了正确对象，或运行代码真正完成了密码操作。
案例档案
锚点来自系统，不等于来历已被证明：RFC 9641 的信任边界
设备在 operational 数据存储中呈现一个 `system` 来源的内置证书锚，说明它不是普通运维配置，却不能回答制造镜像由谁批准、锚点经何种机制写入、更新由谁授权，也不能证明某次会话真的选中了它。RFC 9641 让这些对象可见、可引用；运行时接纳仍需另一条完整证据链。
案例档案
一张凭证验证通过之后，风险究竟归谁管
W3C 新发布的可验证凭证威胁模型草案，把风险从格式本身延伸到签发、钱包软件和核验方的实际决定。它列出问题，但并不替任何部署者完成控制。
案例档案
数据分开存放，不等于无法重新拼出一个人：RFC 9614
身份记录在中继端，行为记录在网关端，两边都没有完整答案。方案评审据此写下“已实现隐私隔离”。但两套日志由同一家运营者保存，时间戳对得上，报文尺寸也对得上。没有人破解加密，也没有组件违反自己的局部职责；一个人仍被重新拼了出来。RFC 9614 要求验证的不是“分了几层”，而是谁仍能把“谁”和“做了什么”重新连起来。
IETF
更安全的口令交换失败后，回退路径又暴露了猜测
RFC 9588 关闭了一条离线猜测通道，但客户端若在失败后退回旧机制，刚刚获得的保护会在“继续登录”这一刻消失。