阅读约 5 分钟
团队共享身份：一个身份，多人共用
团队可以通过共享身份种子来共用一个 CardanoWall 身份——但这等于把完整的签名与解密权限交给每一位持有者，既无法只授予部分权限，也无法针对某个人单独撤销。
团队可以共用一个 CardanoWall 身份，但共享身份意味着共享身份种子。除此之外没有更轻量的方式。
交出种子，就是一次完整的授权。任何持有它的人都能以该身份签名记录，并解密发给该身份的封存记录。CardanoWall 可以让跨账户的协作变得顺手，却无法把一个种子拆成可部分授予、可撤销、可按人区分的权限。密码学没有这样的弹性。
所以，只有当你确实想要的就是「共享权限」时，才去用共享身份。
什么是团队共享身份？
它指的是一个被多人或多个账户共同使用的 Label 309 身份。
一个 Label 309 身份的根是单一的 32 字节身份种子。任何人只要导入这个种子，就能在任意账户、任意兼容工具中重建出相同的签名密钥和相同的接收密钥。这个身份并不绑定在某一个 CardanoWall 账户上，因为单凭种子就足以定义它。
一家新闻编辑室可能就用这种方式运行一个「Press Team」身份。资深编辑创建身份、保存种子，再通过可信渠道分享给选定的同事。每位同事把种子导入自己的账户，并用自己的通行密钥解锁。从那一刻起，他们持有的就是同一个密码学身份。
每一位种子持有者能做什么？
凡是这个身份能做的，他们都能做。种子是根，而不是某种范围受限的权限。
每一位持有者都可以：
- 以该身份签名新的 Label 309 记录
- 解密发给该身份的封存记录
- 解锁后读取收到的封存记录
- 再次导出种子并继续转发
- 把身份导入另一款兼容工具，例如开源的 CLI
- 在任何地方公布该身份的接收地址
这跟「邀请某人加入工作区、给予有限权限、再附上一个撤销按钮」完全不同。这里没有「只读」或「可发布但不可解密」之类的分级。持有种子，就持有整个身份。
什么时候适合用共享身份？
当外界应当看到一个代表「角色」而非「个人」的身份时。
合理的场景包括：
- 新闻编辑室的接收地址
- 法务部门的证据身份
- 安全披露联系点
- 审计委员会身份
- 合规团队身份
- 公司记录身份
- 小型项目的共享身份
在以上每种情形里，对外的身份代表的是一项职能或一个团队，而背后站着多个人这件事本身正是重点所在。
共享身份有哪些风险？
归属变成共享的，暴露面也随之变成共享的。
如果多个人都能以同一身份签名，外部验证方看到的永远只是一把 Ed25519 公钥。链上不会记录究竟是哪个人使用了种子。这或许正合团队心意——也可能构成实实在在的问责难题，要看具体情况。
其余风险都源自同一个根：
- 任何一名成员都可能泄露种子，无论是故意还是无意
- 一台设备被攻陷，就可能危及整个身份
- 离职成员在走之后仍可保留一份副本
- 发给该身份的每一条封存记录，所有种子持有者都能读取
- 这里没有密钥轮换机制——换密钥意味着迁移到一个新身份
共享权限行得通，但它需要配套的运营纪律。
CardanoWall 如何跨账户处理这一点？
每个账户都各自保存着该共享身份的一份加密副本。
如果两个人——就叫他们 Alice 和 Bob——都导入了同一个种子，那么每个账户都会获得各自的账户-身份关联，以及各自的加密保险库。Alice 的通行密钥解锁 Alice 的保险库，Bob 的通行密钥解锁 Bob 的保险库。同一个密码学身份只是同时出现在两个账户中，而两者之间不共享任何服务端状态。
要关联一个已存在的身份，导入者必须证明自己确实持有种子——而不只是知道公钥，因为任何人都能从个人资料或链上读到公钥。在关联建立之前，账户会用由种子派生的密钥对一次性服务端质询进行签名。这样既能阻止有人去关联一个他只知道公钥的身份，又仍然允许真正的种子持有者完成关联。
显示标签对每个账户都是私有的。Alice 可能把这个身份标注为「Press Team」，Bob 可能标注为「Intake」。这些标签存放在各自账户的加密保险库里，绝不会进入公开的身份，因此两个账户都看不到对方的标签，即便数据库被攻破也无从泄露。
计费同样按账户分开。如果 Alice 从她的账户发布，那就由 Alice 的账户付费。这里没有共享余额，因为只要任何持有种子的人都能发布，余额就无法在密码学上被强制约束。
共享身份能针对某个人单独撤销吗？
在密码学层面不能——一旦对方已经知道了种子，就更不能。
CardanoWall 可以把身份从某个账户的保险库中移除、移除某把通行密钥，或在指定账户中停用该身份。这些都是真实有效的服务层控制手段，对于你所掌控的账户而言确实有用。
但它们都触及不到那份已经存在于某人密码管理器、打印件、记忆、备份、桌面工具或第二个账户里的种子副本。对 32 字节的知晓，是无法被收回的。
所以，如果某个曾持有种子的人不应再拥有权限，诚实的做法是创建一个新身份、让旧身份退役——而不是假装旧种子还能重新变回机密。
共享身份的良好操作流程是怎样的？
把种子当作它本来的那种高价值共享机密来对待。
在任何人分享它之前，团队应当就以下事项达成一致：
- 谁有资格持有种子
- 种子如何传递（当面交接，或端到端加密）
- 权威备份副本存放在哪里
- 谁可以把身份添加到账户中
- 哪些通行密钥能解锁各账户的保险库
- 谁有权以该身份发布
- 有人离职时该怎么办
- 何时必须更换身份
- 新公钥在哪里对外公布
要在突发事件或人员变动逼着你在压力下仓促决定之前，就把这些写下来。
团队应该用一个共享身份处理所有事情吗？
通常不该。
分开使用多个身份能让工作流保持清晰，并把损害控制在一定范围内。一家公司可以用一个身份处理安全披露，另一个处理法律证据，再一个用于公开发布，还有一个用于内部审计。
这种分离限制了波及范围。如果其中一个身份被攻陷，其余身份并不会自动继承这次失陷。它还能让通讯录和白名单模式更易于理清，因为每个身份都有清晰、专一的用途。
团队人员轮换时该怎么办？
创建一个新身份。对旧种子的知晓无法撤销，因此干净利落地另起炉灶是唯一真正有效的办法。
当一个共享身份被攻陷，或者某位曾经的持有者应当失去访问权时，路径是：
- 创建一个全新的身份，并保存它的新种子
- 只把新种子分享给仍应持有它的成员
- 用新密钥更新公开资料、接收地址和联系人
- 在你掌控的账户中停用旧身份
- 停止使用旧的接收地址
- （可选）以新身份发布一条记录，声明它取代了旧身份
那些早已发给旧密钥的封存记录，仍然对所有曾持有旧种子的人保持可读——包括你正要替换掉的那个人。这是「向长期公钥加密」这一做法的固有特性，而不是你能打补丁修掉的缺陷。要围绕它来规划，不要假装旧种子可以「取消共享」。
一句话总结
团队共享身份既强大又粗放。
它们让一个团队得以在多个账户和设备上运行同一个公开的 Label 309 身份。但凡是持有种子的人，都拥有完整的签名与解密权限，而这份权限既无法只授予一部分，也无法悄无声息地撤销。
当某个角色确实需要共享权限时，就用共享身份。而当问责、隔离或轮换更为重要时，就改用各自独立的身份。