背景
このドキュメントでは、Google とベンダー（またはユーザーに対するアカウントの発行元）の統合で使用される共有 ID の必須プロパティについて説明します。共有 ID は、Google アカウントと発行者アカウントの間のエッジへの不透明なポインタであると考えてください。
したがって、共有 ID は、Google アカウント（または Google のストレージ内のユーザーまたは他のエンティティ）も、ベンダー/発行者アカウント（または他のエンティティ）も参照しないことに注意してください。2 つの間の関係を指します。
共有 ID プロパティ
共有 ID に必要なプロパティは、過去の経験と、共有 ID にこれらのプロパティが含まれていなかった結果として発生した技術的な問題から生まれます。
Google と外部パートナーを統合するには、使用する共有 ID に次の特性が備わっていることが重要です。
- グローバルに一意である: この共有 ID は、Google ユーザーと発行者アカウントの間のリンクを 1 つだけ指している必要があります。同じ発行者には同じ値を持つ別の共有 ID があってはなりません。
- 推測できない: これらの共有 ID には、ユーザーに代わって操作を行う権限があるため、第三者が共有 ID の値を推測できないことが重要です。
- 取り消し可能にする: ユーザーが共有 ID を取り消すことができることが重要です。この取り消しにより、共有 ID 値の今後の使用が禁止されます。このプロパティには、次のようないくつかの必然的なプロパティがあります。
- いずれのアカウントの不変プロパティにも基づかない: 共有 ID 値が発行者アカウントまたは Google アカウントの不変プロパティに基づいている場合、取り消された共有 ID が再作成されると、その共有 ID と同じ値になります（これにより取り消しが取り消されます）。そのため、電話番号や電話番号を電話番号であってはいけません。
- 単に <Google アカウント、パートナー アカウント> ではない: 取り消しを許可するには、他の値（時間など）が必要です。
- どちらの側のアカウントに対しても、複数のリンクを許可する: 共有 ID 値の作成により、1 人の Google ユーザーが複数の銀行口座にリンクしたり、複数の Google アカウントを 1 つの銀行口座（たとえば、親の銀行口座とリンクしている親口座と子口座をリンクしたりする）を不可能にしないようにすることが重要です。取り消し可能性と同様に、これにはいくつかの関係があります。
- 繰り返しになりますが、いずれかのアカウントの不変プロパティに基づかない: 1 人の Google ユーザーが複数の銀行口座をリンクしたとき（共有 ID 値が Google アカウントに基づく場合）、または複数の Google アカウントが 1 つの銀行口座にリンクされている場合（共有 ID 値が銀行口座のプロパティに基づく場合）は、共有 ID は同じ値になります。
- 長期保存: 共有 ID は安全なコンテキストでのみ有効です（Google とベンダーの統合。接続レベルとアプリケーション レベルの両方の保護（たとえば、PGP、相互 SSL など）を使用）。そのため、短いライフサイクルを必要とせずに安全を維持できます。Google では、共有 ID に有効期限がないことを推奨していますが、ベンダーが有効期限を要求する場合は、長期間（1 年以上など）にする必要があります。
推奨されるその他の共有 ID プロパティは次のとおりです。
- Base64: これにより、HTTPS を介して転送と統合の値の通信を簡単に行えるようになります。
- 最小の長さ: 競合を避けるために十分なアドレス空間を確保するために、27 桁以上（Base64 エンコード前）にすることをおすすめします。
失敗する可能性があるもの
必要なプロパティを理解しやすいように、プロパティが守られていない場合に発生する問題を説明するいくつかのケーススタディを取り上げます。
共有 ID の事例紹介
ケーススタディ 1: 電話番号のリサイクル
ユーザーの電話番号を共有 ID として使用したカード発行会社。ユーザー A が通話プランを変更したときに、電話番号をあきらめて新しい電話番号を取得しました。1 か月後、携帯電話会社が古い電話番号を再利用したところ、その電話番号の新しい所有者であるユーザー B に、購入していないものに対する請求がアカウントに発生しました。
この発行元は、多くの共有 ID プロパティ（主にプロパティ #1）に違反していました。電話番号などはユーザー間で移行されるため、特定のスナップショット間でのみ一意になります。
ケーススタディ 2: The Paste
Google またはパートナーの従業員が、誤って共有 ID を内部ツールではなくチャットに貼り付けた。追加の保護レイヤは、共有 ID の悪用を防ぎますが、念のため、Google は共有された ID を取り消し、新しい ID に置き換えることにしました。Google またはパートナーが共有 ID を取り消そうとすると、共有 ID はカード発行会社のシステムにおけるユーザーのアカウント ID であり、共有 ID がユーザーのアカウントを直接検索するために使用されます。そのため、ユーザーのアカウントを削除し、新しいアカウントを作成しない限り、共有識別子を取り消すことはできません。
ケーススタディ 3: 悪い従業員
上記の「貼り付け」のインシデントの後、Google/パートナー内の不正な行為者が、共有 ID はユーザーのアカウント ID にすぎないため、第三者のアカウント ID を自身の共有 ID 値に入れることができれば、そのユーザーのアカウントに対して購入を行える可能性があることに気づきました。プロパティ 2 の違反により、1 人のユーザーを対象としたセキュリティ ホールではなく、あらゆるユーザーのセキュリティ ホールを誤って貼り付けてしまったことになります。
ケーススタディ 4: ローテーション
上記の「貼り付け」のインシデントの後、発行元は共有識別子の形式を UUID に切り替えます。今回は、発行元の従業員が、デバッグのメールスレッドで、共有 ID の一部を平文で誤ってメールで送信しました。Google によれば、ユーザーの共有 ID を取り消して置き換えるだけで問題ありません。
ローテーションの一環として、Google は発行元に対して、データベースのクリーンアップの進行中に、不正使用されたユーザー アカウントごとに 2 つの共有 ID が短期間アクティブになることを通知します。しかし、発行元はプロパティ 4 の使用を許可しておらず、特定のユーザー アカウントに対して有効にできる共有 ID は 1 つのみという制約があることを Google に伝えます。これにより、競合状態による非常に乱雑なローテーションにつながります。