主题
数字身份与凭证
在主题维度下，数字身份与凭证主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
服务器不必看见明文，仍然控制凭证能否取得：RFC 3157
保险库看不懂信封里的文件，并不妨碍它决定物主何时能够取回信封。2001 年 8 月，RFC 3157 把这条界线带进了密码凭证的移动问题：私钥可以在服务器无法解密的状态下存放和传输，但服务器仍可决定它是否被列出、下载、替换或删除。秘密是否保密、对象是否可得、身份能否延续、后续行动是否成功，从一开始就是四项不同的证明。
报道
RIPE NCC 更换 RPKI 凭证，真正需要缩小的是可操作范围
把 API 密钥接入单点登录，可以改善身份识别、吊销和责任追踪，却不自动回答一个更重要的问题：这把凭证究竟能改哪些前缀？RIPE NCC 同一份季度计划中，一边推进 OIDC，一边因接口可编辑其全部地址空间的 ROA 而暂缓路由信标。这两项决定应放在一起审视。
互联网历史
服务器为何需要第三个随机值：RFC 3163
在 RFC 3163 的双向认证模式中，第三个随机值不是装饰。它要处理的是一次顺序上的不对称：客户端挑选自己的随机数时，已经看过服务器最初发来的挑战值。这个补充有明确边界，协议提供的保证也同样有限。
IETF
信封通过了签名验证，分离密文却在签名之外
对象库保存 COSE 信封，Blob 存储保存密文，审计台只亮起一个“验证成功”。真正决定安全性的不是这盏灯，而是验证时究竟把哪一组字节交给了签名、AEAD 与 HPKE。只要密文被分离传输，图上的嵌套关系就不再等于密码学覆盖关系。
IETF
日历把他称作所有者，但并没有把控制权交给他
一份可移植的日历记录可以把参与者标为所有者，却不等于授权此人编辑。标签描述的是活动中的角色；究竟谁能改期、增删参与者或以活动名义发出更新，仍由交换协议决定。
IETF
重定向成功了，凭据早已明文越过网络
调用链最后停在 HTTPS，接口也返回了预期结果，看上去一切安全。真正的风险发生在更早：客户端收到重定向之前，已经把 API 密钥、Cookie 或 bearer token 写进第一条明文 HTTP 请求。
IETF
证书链通过了自带锚点的验证，但依赖方还没有信任它
did:x509 可以把证书链、CA 指纹和叶证书条件严密地合在一起，却不能替接收者作出信任决定。解析成功只说明提交的材料彼此一致；哪一个 CA 能进入本地信任边界、哪一把钥匙能批准哪一种行为，仍需另一套明确的制度凭据。
互联网历史
长期证据必须比密钥活得更久：RFC 3126
RFC 3126 把旧签名视为一个证据保管问题。2001 年成立的密码学计算，若干年后未必还能自证：证书会过期，撤销记录会消失，时间戳机构的密钥会老化，hash 也会变弱。它给出的不是“永久可信”按钮，而是一条必须持续维护的证据链。
IETF
握手内容解开了，群组记忆却还没有到场
MLS 的外部接收者可以拿到与群成员完全相同的提案或提交，却仍无法证明发送者是谁。欠缺的不是另一层加密，而是把当前纪元、发送者叶节点、凭证与接收者名单连在一起的 GroupContext。
互联网历史
有效签名仍然需要一份策略：RFC 3125
RFC 3125 试图把电子签名周围的规则变成可引用、可校验、必要时可由机器处理的对象。密码学计算正确，只打开了第一道门；真正的“有效”还取决于哪一版策略、哪种承诺、哪些信任条件，以及外部制度是否承认它们。
IETF
现用密钥签下了继任者，风险正从这里开始
验签只能说明：按昨天的规则被接受的那把密钥，确实批准了这次变更。它不能回答更难的问题：这把密钥是否有权独自决定明天由谁控制同一个标识符？
IETF
AS2 名称完全匹配，签名者的授权仍是本地决定
一条异步 MDN 可以从另一条 HTTPS 连接返回，名称对调正确、签名验证成功、MIC 也与原文一致。它证明了一条很强的证据链，却仍不能替代那条没有出现在报文里的记录：谁批准这把新密钥代表这一交易伙伴？
亚太地区机构
TrueMoney 的支付轨道:哪些规模数字站得住,哪些只是营销里程碑
TrueMoney 是正大集团旗下金融科技公司 Ascend Money 的消费品牌,由 Truemoney Company PLC 承载其钱包、代理网络、二维码与跨境汇款业务。这家公司在自己的网页上宣称覆盖 5000 万用户、88000 个代理网点、累计处理 140 亿美元,但这些数字没有标注日期,且在其自有资产之间彼此矛盾。本文逐项核对哪些增长数字有注明日期、定义明确的一手来源支持,哪些只是被反复使用的营销里程碑。
IETF
Voucher 承诺再签发，不等于已经完成续期
ANIMA 最新草案允许 MASA 写下预计最晚续期日，但 YANG 定义同时明确：这个字段仅供参考，Pledge 不处理。修订 36 新写清的 RVR、域私钥、证书与政策检查，正是承诺日期不能冒充续期回执的原因。
IETF
规范把 `0x02` 和 `0x03` 留空了，生产环境没有因此自证清零
HPKE 候选替代规范只保留 Base 与 PSK，并把 RFC 9180 中 Auth、AuthPSK 的两个取值改为保留。表格完成了一次边界收缩，但应用画像、已装载二进制、存量密文和对端兼容集仍需逐项举证。
IETF
用户通过了认证，源 MAC 仍可能冒充别人
一个获准接入的远程用户，只要隧道没有另行约束二层来源，就可能在同一条合法连接里声称自己是网关、控制器或另一台主机。CONNECT-ETHERNET 把以太网带进 HTTP 的安全边界，却没有把 HTTP 身份自动升级为整个广播域的身份代理权。
IETF
服务器返回了旧对象，却没有返回审计轨迹
JMAP 实体 History 让客户端取回被替换或已删除对象的旧版本。它也明确允许合并变更、任意剪枝与不确定的完整性，因此旧快照可以帮助恢复，却不能独自证明谁在何种授权下做了什么。
IETF
一张无条件发送的信任锚清单，也是一枚客户端指纹
TLS 客户端若把完整信任锚偏好放进每一次握手，服务器也许更容易第一次就选中可用证书路径，但旁观者同样得到了一份稳定的客户端特征。正在 IETF 推进的信任锚标识草案把这种取舍写进协议：条件发送减少被动观察，却可能用重试和延迟来偿还隐私成本。
IETF
导出器生成了 128 字节，却没有把令牌持有者绑定到隧道
EAP-PPT 第 04 版删掉了一段看似“密钥材料”的输出。问题不在导出器能否生成字节，而在这些字节并不能证明终止 TLS 隧道与持有不记名令牌的是同一方。
互联网历史
密码在目录里没有可改的条目：RFC 3062
2001 年，LDAP 的常规修改操作并不能触及所有密码。RFC 3062 增加了一种独立的改密请求：它可以指向当前会话的用户，也可以携带不一定是 DN 的身份，即使密码存放在目录之外。协议对“成功”设下了严格条件，却没有声称自己看得见服务器之后的一切。