第 4 章 認証、認可、およびアクセス制御

4.0 概要

• 有効期間が短いアクセス トークン: 暗号文/マニフェストへのアクセスをゲートします。サーバー側セッション (ルックアップ)。 transferId にバインドする必要があります。スコープを指定する必要があります。有効期限が切れなければなりません。
• 有効期間の長いログイン トークン: 送信者の管理 (削除/取り消し/監査) に使用されます。クライアントに保存されます。受信者が暗号文にアクセスするために使用してはなりません。
• キーと認可の分離: トークンは暗号文へのアクセスのみを制御します。復号化機能は、URL フラグメントの CEK から取得されます (第 5 章を参照)。

4.1 アイデンティティモデル

• このシステムは、送信者管理のための有料ユーザー ID モデルをサポートしています。
• 送信者のログインでは、ワンタイム マジック リンクを使用してもよい(MAY)。クライアントは、認証が成功した後、有効期間の長いログイン トークンを保存します。
• 受信者はデフォルトのダウンロードにアカウントを持つ必要はありません (UX ドキュメントを参照)。アクセスはリンク/トークンで制御されます。

4.2 認可モデルとトークン層

責任を厳密に分離して、2 つのトークン タイプが使用されます。

1. 有効期間が短いアクセス トークン (セッション/ルックアップ): 暗号文およびマニフェスト読み取りのアップロード/ダウンロード用。 transferId にバインドする必要があります。有効期限が切れなければなりません。操作によってスコープを設定する必要があります。
2. 有効期間の長いログイン トークン: 送信者管理アクション用。復号化機能を付与してはなりません。

4.3 アップロードの承認

• アップロード API は、暗号文を受け入れる前に、トークンのスコープと transferId バインディングを検証する必要があります。
• チャンクのアップロードは、(transferId、fileId、chunkIndex) ごとにべき等である必要があります (SHOULD)。
• 無効なトークンまたは不一致の場合、システムはフェイルクローズしなければなりません (MUST)。

4.4 ダウンロード認証

• マニフェストおよび暗号文へのアクセスには、有効なスコープ付きトークンが必要です。トークンは期限付きでなければなりません。
• 受信者は、他の転送を列挙したり、バインドされた transferId の外側のチャンクにアクセスしたりすることはできません。
• レート制限は、再開可能性を損なうことなく、悪用防止のために適用してもよい(第 7 章を参照)。

4.5 失効と早期無効化

• 送信者は転送を取り消すことができなければなりません。失効により、トークンはその後のアクセスに使用できなくなります。
• 取り消しは、可能な場合、暗号文のクリーンアップ/TTL アクセラレーションをトリガーする必要があります。
• 受信者のUXは、取り消し/期限切れのステータスと次のステップ（送信者に連絡する）を明確に示さなければなりません（MUST）。

4.6 監査と権限の分離

• 配信証拠 (ダウンロード、カウント) は、デフォルトでは送信者のみに表示されなければなりません (MUST)。
• 監査 API は送信者の認証を必要とし、受信者のアクセス トークンから分離されなければなりません。

4.7 ロギングと機密データの最小化

• ログには、URL フラグメント、CEK、または導出可能なキーマテリアルを含めてはなりません。
• ログは個人データを最小限に抑え、セキュリティ関連のイベント (トークンの失敗、失効、レート制限) に焦点を当てる必要があります。
• エラー メッセージは対処可能である必要がありますが、機密が漏洩してはなりません。

4.8 関連するクレーム ID

• See 付録: クレーム ID 権限のあるマッピングの場合。