隐私与成对标识符
Sudomimus 的设计目标之一，是阻止不同应用在用户不知情的情况下跨产品关联同一个人，并将控制权交给用户而不是应用。本页介绍实现这一目标的身份模型。
用户认证时，Sudomimus 会给应用一个按用途隔离的标识，它只对该应用（或同一个开发者旗下的一组应用）有意义。三条原则始终成立：
- 应用使用成对标识符。 应用通过扇区主体识别用户。用户可以管理自己的账户别名和扇区主体，具体见下文。
- 默认不存在跨应用关联。 两个互不相关的应用，对同一个人会拿到不同的标识。两个应用所有者即便互相比对，也无法看出他们各自的用户其实是同一个人。
- 用户可以轮换自己的标识。 身份的连续性是一种用户可以主动撤销的选择。
扇区（Sector）：隔离的基本单位
Section titled “扇区（Sector）：隔离的基本单位”每个应用都只属于一个扇区。扇区决定哪些应用可以共享同一用户标识：
flowchart TD
Account["同一个 Sudomimus 账户"]
Account --> SectorA["扇区 A"]
Account --> SectorB["扇区 B"]
SectorA --> SubjectA["扇区主体 A"]
SubjectA --> App1["应用 1"]
SubjectA --> App2["应用 2"]
SectorB --> SubjectB["不同的扇区主体 B"]
SubjectB --> App3["应用 3"]
- 在同一个扇区内，一个用户只有一个标识，因此放进同一扇区的两个应用，对该用户会看到相同的标识。这是刻意为之——它让同一个开发者可以把一组相关产品（比如一个游戏启动器和它的配套应用）作为单一身份来运营。
- 处于不同扇区的应用，对同一个用户看到的是互不相关的标识。无论怎样比对这些标识，都无法还原出背后是同一个人。
默认情况下，每个应用都会获得一个全新的独立扇区——最大化隔离。开发者如果确实希望自己的两个应用共享某用户身份，需要主动把它们放进同一个扇区；在主动开启之前，什么都不会被共享。扇区与你的应用一同存在于一个组织之内 —— 见组织与扇区。
用户实际拥有的标识
Section titled “用户实际拥有的标识”| 标识 | 谁能看到 | 可轮换 | 用途 |
|---|---|---|---|
| 账户别名（account alias） | 用户本人，在账户门户中可见。应用永远看不到。 | ✅ | 用户可以通过其他渠道将它提供给允许列表的管理者。这样运营方可以允许某位特定用户，而应用始终不会得知该别名。 |
| 扇区主体（sector subject） | 应用；它就是令牌里的 sub 声明。 |
✅ | 应用用于标识用户的键，也是开发者在规则中进行允许列表匹配的值。它按 (用户, 扇区) 唯一。 |
两者都是不透明、人类可读的令牌——扇区主体形如 sub_9SQ5535CRWNDDM2T，账户别名形如 quiet-meadow-7h2k-9m4p-3fnp-falcon。应用应当把它们当作不透明字符串：不要解析、不要假设格式。正是这一点，让格式日后可以演进而不破坏任何接入方。
轮换意味着什么
Section titled “轮换意味着什么”- 轮换账户别名会改变用户对外提供、用于允许列表的句柄。应用既没见过旧值，也看不到新值；只有通过其他渠道维护的允许列表会受到影响。
- 轮换扇区主体会改变应用对该用户看到的
sub。旧的主体不再可解析，于是应用看到的就像是一个全新的用户。这是用户的“忘掉我和这个产品之间的连续性”开关，可在账户门户中行使。
用户可以在 With 门户的外部标识视图中查看当前值，并从隐私控制执行轮换；每项永久影响都会要求明确确认。
成对标识提供的隐私边界取决于应用仍能获得的最强稳定声明。如果每个应用同时获得同一个真实邮箱，它们仍可通过邮箱进行跨应用关联，成对 sub 本身无法阻止这种关联。
因此，身份声明由用户单独控制。用户可以针对每个应用，决定 UserInfo 是否能返回自己的真实邮箱、名、姓和头像：
- 开发者按声明逐项声明应用是否请求它：关闭（off）、可选（optional）、必需（required）、仅占位资料或占位兜底。
- 用户在登录时决定是否共享可选资料，也可以随时在账户门户中撤销授权。下一次 UserInfo 请求会立即采用新的决定。
- optional / required 声明只有在用户授权后才会由 UserInfo 返回。占位策略返回按扇区生成的替代值，不会泄露真实资料。
成对标识符将标识符共享限制在同一个扇区内。按应用设置的声明策略和用户授权决定各应用能获得哪些个人资料。真实声明（例如邮箱地址）仍可用于跨扇区识别同一用户。
声明策略、同意界面和 OIDC scope 规则见身份声明与共享。