昨晚我盘 SIGN技术文档的时候，在"Unlinkability patterns"章节看到了一个让我踌躇不前的动词：rotate。
"rotate verifier session identifiers to reduce metadata linking"
就这一个词，为了研究透它，我在屏幕前静坐了3个小时。
在传统身份系统里，Verifier 的会话标识符从来不换。银行终端 ID、闸机设备编号、服务窗口系统标识，永远固定。这是运营管理的基础，是审计追溯的前提，是每一个系统集成商在交付文档里默认写进去的前提假设。没有人质疑它，就像没有人质疑呼吸一样。
SIGN 的文档却说：把这些标识符轮换掉。@SignOfficial
这条建议的对象不是 Issuer，不是 Holder，而是 Verifier 自己。SIGN 在要求验证方主动切断自己对持证人的追踪能力。在身份系统设计的文献里，我还没有找到任何一个同类项目把这个责任显式地压给 Verifier。这是第一个。
rotate 这个词的出现，证明SIGN 在隐私设计上到达了一个大多数同类项目从未到达的位置。它看见了 Verifier 侧的元数据风险，看见了固定标识符的追踪后果，也看见了解法。
它什么都看见了。但看见，和要求，是两码事。
文档里用的词是"design verifiers to"。不是"MUST"，不是"SHALL"，不是任何一个 RFC 2119 意义上的强制性措辞。
这意味着一个完全合规的 SIGN部署，可以完全无视这条建议，使用固定会话标识符，在技术上零违规。
SIGN 把对元数据关联风险的理解写进了文档，但没有写进规范。理解和约束之间，还有一道沟。
这道沟不是技术能力的问题。rotate 这个动词本身证明设计者知道风险在哪里，也知道解法在哪里。沟存在的原因只有一个：有人在某个决策节点，选择了"建议"而不是"约束"。
这个选择看起来温和。实际上是把全部的隐私风险，转移给了最没有动力承担它的一方：Verifier。
这道沟的代价其实是可以估算的。
一个国家级身份系统，假设日均验证事件 100 万次，分布在 5000 个 Verifier 节点。如果这 5000 个节点使用固定会话标识符，一个持证人一年内的跨机构行为记录，理论上可以被完整还原。
即使凭证本身使用了 ZK 证明、BBS+、选择性披露，所有隐私技术全部正常工作。你在凭证里藏得再好，Verifier 那边一直盯着你，照样能把你的行踪拼出来。
那些精心设计的密码学工具，最终像一件穿在人身上的透明衣服。我们以为自己被遮住了，其实什么都没遮住。
这不是边缘场景。这是在没有强制要求的情况下，每一个追求运营效率的 Verifier 的默认选择。没有人会主动给自己增加轮换标识符的运维成本，除非规范要求他必须这样做。
法律从来不相信人性，它只相信制约。
对比 GDPR 的处理方式。欧盟在数据最小化原则上用的是"MUST"，不是建议。结果是什么？企业合规部门有了可执行的基准，监管机构有了可追责的条款，用户有了可主张的权利。
再对比 Apple 的 App Tracking Transparency。苹果没有"建议"开发者不追踪用户，而是在系统层面强制弹出授权弹窗，把追踪行为从默认开启变成默认关闭。效果立竿见影。不是因为开发者变得更有道德，而是因为有约束了。默认值的翻转，比任何一份隐私承诺书都更有约束力。
SIGN 也明白这个道理。"事前切断"比"事后约束"更可靠，把隐私保护从"我承诺不这样做"变成"我在结构上做不到这样"。这个逻辑写在它的设计哲学里，写在 rotate 这个动词的选择里。$SIGN
但它仅仅把这个理解写成了建议，而不是约束。
写成建议的那一刻，它就从 Apple ATT 退回到了"我们鼓励开发者尊重用户隐私"的时代。那个时代，我们都知道后来发生了什么。
就像一个人看见了路边倒下的人，和弯下腰去扶人，是两个完全不同的节点事件。我的判断是：一个把隐私保护写进规范强制条款的系统，和一个把隐私保护写进文档建议章节的系统，在部署三年后的现实世界里，会变成两个完全不同的系统。
SIGN选择了哪条路，不在于它的设计哲学有多先进，而在于那个"MUST"有没有出现在正确的位置上。
rotate 这个词已经在那里了。不急，我先等等看迭代。#Sign地缘政治基建
你们觉得呢？SIGN该继续保留温柔的建议，还是坚定的MUST？