身元とメンバーシップ

bae にはどこにもアカウントシステムがありません。デバイスの身元は、そのデバイスが生成して OS のキーリングに保持する Ed25519 鍵ペアです。公開鍵そのものが身元です。誰がライブラリに属するかは、クラウドホーム内の署名済みレコードの集合であり、それを持つ誰でも検証できます。サーバーは発行しません。この仕組みは coven のもので、このページでは bae がどう使うかを説明します。

メンバーシップレコード

各所有者は、署名済みメンバーシップ項目の追記専用ストリームをクラウドホームへ書き込みます。この鍵をこのロールで追加した、この鍵を削除した、という項目です。各項目は前の項目へリンクし、各所有者は自分のストリームの先端を宣言する head に署名します。そのため、プロバイダーがレコードを落としたり並べ替えたりした場合、信じるのではなく検出されます。ライブラリが受け入れるのは、すべての所有者の検証済みストリームの和集合です。

各 pull では、各変更セットの作成者がこのレコードに照合されます。現在のメンバーによる署名か、書き込み可能なロールかを確認します。削除済みデバイス、追加されたことのない鍵、無効な署名からの変更セットは適用されません。プロバイダーはレコードを保存しますが、偽造はできません。メンバーシップを変えられるのは所有者鍵の保持者だけです。

ロール

Owner と Member はどちらもライブラリを読み書きできます。所有者はさらにデバイスを承認および削除できます。bae の最初のデバイスは owner で、そのデバイスが承認するすべてのデバイスは member として参加します。（下層の仕組みには 3 つ目のロールとして読み取り専用 follower がありますが、bae は現在割り当てません。）

参加手順

デバイスの追加は、途中に人間の明示的な確認を挟む 2 コード交換です。

1. 参加するデバイスが鍵ペアを生成し、join request を表示します。公開鍵、その短いフィンガープリント、（OAuth プロバイダーの場合）フォルダー共有先のクラウドアカウントです。
2. 所有者がリクエストをデコードし、2 つの画面が同じフィンガープリントを表示します。人間が一致を確認します。これがすり替えられた鍵を防ぐ手順です。
3. 承認は 3 つのことを同時に行います。新しいデバイスのアカウントへクラウドホームへのアクセスを与え（一般向けクラウドではフォルダー共有、S3 では埋め込み認証情報、iCloud では CloudKit 共有）、ライブラリ鍵を新しいデバイスの公開鍵へ封印し、それを追加するメンバーシップ項目に署名します。すべては invite code に詰め込まれます。
4. 参加するデバイスが招待を消費し、鍵を開封し、最新スナップショットから初期化して同期します。

招待は要求した鍵に対して封印されています。途中で取得されても、何も得られません。

失効

メンバーを削除すると、署名済み削除が追加され、ライブラリ鍵が、削除された鍵が受け取らない新世代へローテーションされます（暗号化 を参照）。アクセスを取り消せるストレージでは、アクセスも取り下げられます。削除されたデバイスにすでに同期されたものは、そのデバイスに残ります。データを送信後に取り戻すことはできません。ローテーション後のものは、そのデバイスの届かないところにあります。

復元コード

復元コードは、意図的にメンバーシップを迂回します。クラウドホームの座標とライブラリ鍵を 1 つのベアラー文字列にしたもので、生きている承認者がいなくても自分のライブラリを復元するためのものです。必要なときに生成され、Apple プラットフォームでは自動的に iCloud Keychain に保存され、ライブラリそのものと同じだけ機密です。