背景
本文档介绍了在 Google 与供应商（或用户的帐号颁发者）之间的集成中使用的共享标识符的必需属性。可以将共享标识符视为指向 Google 帐号和发卡机构帐号之间边缘的不透明指针。
因此，请务必谨记，共享标识符既不是指 Google 帐号（或 Google 存储空间中的用户或其他实体），也不是指供应商/发行方帐号（或其他实体）。它指的是两者之间的联系。
共享标识符属性
共享标识符所需的属性源自过往经验和因共享标识符中缺少这些属性而遇到的技术问题。
对于 Google 与外部合作伙伴之间的集成，使用的共享标识符必须具备以下属性：
- 具有全局唯一性：此共享标识符必须恰好指向 Google 用户和发卡机构帐号之间的一项关联。同一发卡机构不得有其他具有相同值的共享标识符。
- 不可猜测：这些共享标识符携带了代表用户执行操作的权限，因此第三方无法猜测出共享标识符的值，这一点非常重要。
- 可撤消：用户必须可以撤消某个共享标识符，而且撤消之后应禁止用户日后再使用该共享标识符值。此属性具有如下几项推论属性：
- 不基于任一帐号的不可变属性：如果共享标识符值将基于发卡机构帐号或 Google 帐号的不可变属性，则重新创建已撤消的共享标识符会导致该共享标识符的值相同（从而撤消撤消），因此共享标识符的值不得是电话号码或电话号码的哈希值属性（例如，
- 不只是 <Google 帐号、合作伙伴帐号>：必须存在其他一些值（例如时间）才能允许撤消。
- 允许为任一方建立多个帐号关联：请务必注意，创建共享标识符值时，不会导致单个 Google 用户无法关联到多个银行账户，也无法将多个 Google 帐号关联到同一个银行账户（例如，父级帐号和子帐号均与父级银行账户相关联）。与可撤消性类似，这也有一些推论：
- 同样，并非基于任一帐号的不可变属性：否则，当单个 Google 用户关联多个银行账户（如果共享标识符值基于 Google 帐号）或多个 Google 帐号与单个银行账户关联（如果共享标识符值基于银行账户的属性）时，共享标识符将具有相同的值
- 长期有效：共享标识符仅在安全上下文（Google 与供应商之间的集成，它同时使用连接级和应用级保护（例如 PGP、双向 SSL 等）中）有效，因此不需要短生命周期来保持安全。Google 希望共享标识符永不过期，但如果供应商要求过期，则必须设置很长的时间（例如超过 1 年）。
下面列出了其他建议的共享标识符属性：
- Base64：这使得通过 https 轻松传输和传达集成中的值。
- 最小长度：建议至少为 27 位（在 Base64 编码之前），以确保有充足的地址空间以避免冲突。
会发生哪些错误？
为帮助读者了解所需属性，以下提供了几个案例研究，说明了不遵循这些属性时所遇到的问题。
共享标识符案例研究
案例研究 1：电话号码回收
将用户的电话号码用作其共享标识符的发卡机构。当用户 A 改变电话套餐时，他们放弃了原电话号码并获得了新号码。一个月后，该电话公司收回了旧的电话号码，该电话号码的新所有者用户 B 突然开始看到针对他们没有购买的商品的扣款。
颁发者违反了许多共享标识符属性，主要是属性 #1。电话号码等内容可能从一个用户迁移到另一个用户，因此它们仅在特定时间段内是唯一的。
案例研究 2：粘贴
Google/合作伙伴员工不小心将共享的标识符粘贴到聊天中，而不是内部工具中。多层保护可防止任何人恶意使用共享标识符，但为了安全起见，Google 希望撤消共享标识符并将其替换为新标识符。当 Google/合作伙伴尝试撤消共享标识符时，会发现共享标识符只是用户在发卡机构系统中的帐号 ID，并且共享标识符用于直接查找用户的帐号。因此，如果不删除用户的帐号并为其创建新帐号，将无法撤消共享标识符。
案例研究 3：坏员工
发生上述“粘贴”事件后，Google/合作伙伴内部的作恶方会意识到，由于共享标识符只是用户的帐号 ID，因此如果他们能够设法将其他人的帐号 ID 放入自己的共享标识符值中，就可以针对对方的帐号购物。由于违反属性 2，因此无意中针对单个用户粘贴了多个安全漏洞，这对每个用户都构成了一个安全漏洞。
案例研究 4：旋转
发生上述“粘贴”事件后，发卡机构会切换到 UUID 作为其共享标识符格式。这一次，颁发者员工在调试电子邮件会话中错误地以明文形式发出了一些共享标识符。Google 表示，不用担心，我们会撤消并替换用户的共享标识符。
在轮替过程中，Google 会告知颁发者每个被盗用的用户帐号有两个共享标识符在短时间内处于活跃状态，而数据库清理正在进行。但发卡机构不允许媒体资源 4 使用，并告知 Google 他们有一个限制条件，即对于某个特定用户帐号，只能有一个共享标识符处于有效状态。这会导致出现竞态条件非常混乱的旋转。