Overview

Local ID 迁移到 did:web5 保持 method-specific identifier 不变，可以基于 did:web5 Method Local ID Extension V0.1 实现。只要在创建 did:web5 DID Document Cell 的时候，直接使用 Local ID 的 identifier 作为 did:web5 的 identifier。

TL; DR

这里是个人建议的一些决策，后文都是展开的分析

• 增加链外共识，重复生成的 DID Document Cell 以最先上链的为权威版本。
• DID Document Cell 使用 Method-Sepcific Identifier + Type ID 作为 Args。链上引用 Document Cell 必须使用 Cell Type Script Hash。比如如果 Dapp 要授权某项权限给 did:web5:xxyy，就必须在链外解析出权威版本的 DID Document Cell，并使用其 Type Script Hash 作为授权的对象，而不能在链上把 did:web5:xxyy 保存为授权对象。
• 不允许删除 DID Document Cell，停用需要使用 Tombstone 在 Cell Data 中标记为已停用。
• 增加一个 Always Success Marker Lock Script，如果 DID Document Cell 使用了该 Marker Lock Script，则 did-type-ts 必须验证：
  • 链上的更新必须能组装出对应的 PLC Operation
  • Witness 中提供的签名由上一个状态的 Rotation Keys 产生，签名输入为 PLC Operation 采样得到的 Hash。
  • did-type-ts 保证不能从其它 Lock Script 切换到 Marker Lock Script。第一次切换到其它 Lock Script 需要使用最后状态的 Rotation Key 对 Tx Hash 进行签名。
  • 注意创建 DID Document Cell 本身这一个 Tx，如果使用了 Marker Lock Script，也需要能组装出一个对应的 PLC Operation 并且签名对象是 PLC Operation Hash 。如果是其它的 Lock Script 则是对 Tx Hash 进行签名。
  • 为了避免创建 DID Document Cell 可以用来重话，最好是使用了 Marker Lock Script 也需要使用 Lock Script 对 Tx Hash 也进行签名。而后续的更新是否要支持可以选择，因为双花检验的存在，没有重放的问题。
  • PLC 的 Recovery Operation 可以选择是否支持，也可以选择先不支持，后续更新再加上。Recovery Operation 的实现方案可以参考 The DID Method Powered by CKB (RFC) Pre-1

Duplicated DID Document Cells

由于 identifier 的唯一性来自于 PLC Genesis Ops 的哈希，使用同一个 PLC Genesis Op 就可以创建相同 Identifier 的 DID Document Cell。

• 要求使用 Rotation Key 对交易签名才能创建 DID Document Cell 可以避免简单的重放攻击。在 Local ID Extension V0.1 Spec 中包含了此要求。
• Rotation Key 的拥有者可以多次创建 DID Document Cell
  • 拥有者可能是用户自己、PLC 使用历史中托管过的 PDS 运营方，也可能是前两者没有保护好 Rotation Key 导致泄漏到攻击者手上。
  • Local ID Extension V0.1 允许在 Witness 中提供 Operations History 的。从功能上来说，只要 Genesis Op 就够了。支持 History 是为了用户不拥有或者丢失了 Genesis Op 中的 Rotation Key 的场景。这也就导致了只要 PLC DID 使用历史中的任何一个 Rotation Key 就能创建拥有相同 PLC Identifier 的 Web5 DID。如果限制只使用 Genesis Op 风险会限制到 Genesis Op 中的 Rotation Keys。
  • Post-Compromise Security Issue. 简单来说就是之前使用的 Rotation Key 被攻破了，会影响现在 DID Document Cell 的安全性。
    • 没有时效性的限制，不管多久之前的 Rotation Key 只要被攻破了就能被用来创建重复 DID Document Cells。
    • PLC PDS 用户普遍会把 PDS Server 的 Rotation Key 加到 PLC DID 中，这样用户迁移到 Web5 之后，安全性也信赖于 PDS Server 能保管好 Rotation Key (甚至是历史上曾使用过的 Rotation Key)。

重复 DID Document Cells 会带来什么问题？

• 只使用 DID Identifier 无法确定最新版本的 DID Document。
  • 链外可以使用额外共识，比如最先上链的 DID Document Cell 才是权威的版本。这会增加 Resolving 的成本：
    • 如果有重复的 DID Document Cell 需要向上溯源过确定谁先上的链。设计上可以通过缓存，或者在创建 DID Document Cell 通过两步提交的方式在 Cell 中包含上链时的 Block Height 和 Tx Index 来避免这个开销。
    • 在 其它数量组合为非法，即没有对应 Type ID Deletion 的操作。停用需要使用 UpdateDID 标记上 Tombstone 的讨论中，为了释放 CKByte，目前的设计在停用 DID 时，是会直接销毁 DID Document Cell 而不是使用 Tombstone。这样就不能简单的通过 Live Cell Indexer 来先查询，如果有多个 Cells 返回再处理冲突的情况。再考虑到 CKB Archive Node 的存在有的节点无法提供 Dead Cells 的查询，要正确处理重复 DID Document Cells 需要链外同步所有相关交易。
  • 链外共识无法用在链上合约。CKB 合约能访问到的信息局限于当前交易，没法判断给的 DID Document Cell 是否是最早上链的：
    • 无法判断给的 DID Document Cell 是最早上链的，因为合约无法访问当前 Live Cells Set，也无法要求交易中包含所有拥有相同 Identifier 的 Cells。
    • 由于 Hard Deletion 的存在，合约甚至需要访问 Dead Cells 才能判断，这在 CKB 中更难，需要提供 header deps + tx merkle tree proof + tx itself 才能在交易中访问。
  • 链上可以采取其它措施：
    • 使用 Registry 在链上保存 DID Identifier 到当前 DID Document Cell 的映射。Registry 就是一个链上的 Map，Key 是 DID Identifier，Value 可以是简单的 Cell Out Point，或者是 Type Script Hash (如果每个 DID Document Cell 的 Type Script 在 Identifier 的基础上还加上 Type ID 来保证 Type Script Hash 唯一性的话）。在 提到为了不可读的 DID Identifier，用链上 Map 保证唯一性是难以接受的开销。
    • 在链上使用能保证唯一性的标识。比如在 Type Script Args 里再加上 Type ID，也就是 Args = Identifier || Type ID。链外可以使用 Type Script Prefix Search 快速查询（如果不考虑 Hard Deletion 的话），链上始终是使用 DID Document Cell 的 Type Script Hash 来引用某个 DID。在生成交易的时候都需要把 DID Identifier 解析到正确的 DID Document Cell Identifier 上。
      • 链上链下实际使用了不同的 ID，对开发者和用户都是认知负担
    • 可以在创建 DID Document Cell 的时候引入 Challenge Window，如果能证明已经存在过相同 Identifier 的 Cell，那创建失败并且要受到惩罚。
    • 让任何人都可以提供交易证明 DID Document Cell A 和 B 有相同的 Identifier，并且 B 比 A 更早上链，就可以直接销毁 B 并且拿走占用的 CKByte 作为提供者的激励和对 B 的惩罚。不过这个方案会限制 DID Document Cell Lock Script 的使用，必须使用 Wrapper Script 来集成其它 Lock Script 的使用，而目前 Wallet 都不能很好的处理 Wrapper Lock Script。
    • 不在链上访问 DID Document Cell。如果只把 CKB 作为 DID Document 存储并依赖于链外索引，并且没有链上通过 Identifier 引用 DID Document 的需求，那么可以不考虑链上访问的问题。
• 重复 DID Document Cells 可以被用来攻击吗？
  • 取决于 DID Document Cells 会被怎么样使用
    • 如果只是在链外去做 Identifier 到 DID Document 的解析，通过链外共识来挑选权威版本。
    • 链上需要通过 Identifier 访问 DID Document 的话使用上文提到的方案
      • 目前没有使用场景，可能的需求有：
        • 使用 Identifier 直接持用资产。比如直接把 DID 二维码展示给付款人，付款人钱包直接使用 DID Identifier 构建 Lock Script。这个新的 Lock Script 在解锁时需要使用 Dep Cell 引用对应的 DID Document，并且验证 Witness 中包含的签名是 DID Document 中的某个 Verification Method 的 key 生成的。
        • Dapps 授权给 DID Identifier，使用 Dapps 里使用 Dep Cell 引用 DID Document 并提供对应 Verification Method 的签名。

PLC 兼容性