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

4.0 概要

• 有効期間が短いアクセストークン：暗号文／マニフェストへのアクセスを制御します。サーバー側セッション（ルックアップ方式）で、transferIdに紐づけなければならず（MUST）、スコープを限定しなければならず（MUST）、有効期限を設けなければなりません（MUST）。
• 有効期間が長いログイントークン：送信者の管理操作（削除／失効／監査）に使用します。クライアントに保存されます。受信者が暗号文にアクセスするために使用してはなりません（MUST NOT）。
• 鍵と認可の分離：トークンが制御するのは暗号文へのアクセスのみです。復号する能力は、URLフラグメント内のCEKから得られます（第5章を参照）。

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

• システムは、送信者の管理のために、有料ユーザーのアイデンティティモデルに対応します。
• 送信者のログインには、ワンタイムのマジックリンクを使用してもかまいません（MAY）。認証に成功すると、クライアントは有効期間が長いログイントークンを保存します。
• 受信者は、通常のダウンロードにアカウントを必要としません（UXに関するドキュメントを参照）。アクセスはリンク／トークンで制御されます。

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

責務を厳密に分離した2種類のトークンを使用します。

1. 有効期間が短いアクセストークン（セッション／ルックアップ）：暗号文のアップロード／ダウンロードとマニフェストの読み取りに使用します。transferIdに紐づけなければならず（MUST）、有効期限を設けなければならず（MUST）、操作ごとにスコープを限定しなければなりません（MUST）。
2. 有効期間が長いログイントークン：送信者の管理操作に使用します。復号する能力を付与してはなりません（MUST NOT）。

4.3 アップロードの認可

• アップロードAPIは、暗号文を受け付ける前に、トークンのスコープとtransferIdへの紐づけを検証しなければなりません（MUST）。
• チャンクのアップロードは、（transferId、fileId、chunkIndex）ごとに冪等であるべきです（SHOULD）。
• トークンが無効な場合や紐づけが一致しない場合、システムはフェールクローズとしなければなりません（MUST）。

4.4 ダウンロードの認可

• マニフェストと暗号文へのアクセスには、スコープが限定された有効なトークンが必要です（MUST）。トークンには有効期限を設けなければなりません（MUST）。
• 受信者が、他の転送を列挙したり、紐づけられたtransferId以外のチャンクにアクセスしたりできてはなりません（MUST NOT）。
• 不正利用の防止のために、再開機能を損なわない範囲でレート制限を適用してもかまいません（MAY）（第7章を参照）。

4.5 失効と早期の無効化

• 送信者は転送を失効させられなければならず（MUST）、失効によって、以降のアクセスにトークンを使えなくしなければなりません（MUST）。
• 失効時には、可能な範囲で、暗号文のクリーンアップやTTLの前倒しを実行するべきです（SHOULD）。
• 受信者向けのUXでは、失効済み／期限切れであることと、次の手順（送信者に連絡する）を明示しなければなりません（MUST）。

4.6 監査と権限の分離

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

4.7 ログと機微なデータの最小化

• ログには、URLフラグメント、CEK、導出可能な鍵素材を含めてはなりません（MUST NOT）。
• ログは、個人データを最小限にとどめ、セキュリティに関わるイベント（トークンの検証失敗、失効、レート制限）に重点を置くべきです（SHOULD）。
• エラーメッセージは、対処できる内容でなければならず、かつ秘密情報を漏らしてはなりません（MUST）。

4.8 関連するクレーム ID

• 正式な対応表は付録：クレーム IDを参照してください。