インタビュールーム 認可設計

★登場人物

認可の主体と対象を整理する。マルチテナント（OEM）前提で「基盤」「テナント」「エンドユーザー」を分ける。

§認可の層（L0–L4）

認証は「誰か」を1回確定すれば終わるが、認可は複数の境界で別々の判断になる。混ぜると認可ロジックが散在してドリフトする。層を分け、各層の判断を単一ポリシーに集約し、すべて署名トークン（Context）から導く。

§2つの認可：公開API と インタビュールーム

上の L0–L4 は、認証主体も保護対象も異なる2つの認可にまたがる。混同を避けるため別々に設計する。

両者の関係は 「公開API が role を決めてトークンに封入し、インタビュールームがその role を強制する」。

§設計原則

インタビュールーム認可を貫く6原則。

1. Deny by default — 明示的に許可された能力以外はすべて拒否。
2. 署名トークン由来のみ — 認可は Context（tenant/room/participant/role）からのみ導く。クライアント申告のロールを一切信用しない。← 現状最大の脆弱点の解消。
3. テナント=割当 / 基盤=強制（委譲認可）— 誰が moderator か はテナントが決める。moderator が何をできるか は基盤が強制。テナントは基盤が定義した能力を超えられない。
4. 単一ポリシー — (role, action, resource)→allow/deny を1モジュールに集約し、HTTP・チャット/データ送信・メディアトークン発行の全実行点で同じ関数を使う。
5. 能力(capability)を下地にした RBAC — 固定ロールを露出しつつ内部実装は能力の集合にする（将来テナント独自ロール＝能力の部分集合を後付け可能）。
6. 多層防御 — UI で隠すだけでなくメディアトークンとサーバー側ポリシーの両方で強制（観察者の「カメラON」はボタンを隠すだけでなく canPublish:false で物理的に不可能にする）。

§ロール × 能力マトリクス

現状コードの実態（minedia-www）

クライアント設定（env）の chat 設定・OpenTok token 発行・チャンネル振り分けを突合した現行の振る舞い。

新基盤の目標能力（あるべき姿）

移行後はこれを RoomPolicy でサーバー強制する。observer/minedia_observer の publish・moderate をメディアトークンで物理強制し、録画・招待を権限化し、両 observer の公開チャット投稿可否を設計判断として明示する。

§強制ポイント — どこで何をチェックするか

認可は5箇所で効く（独立アプリ・ActionCable 不使用）。各箇所が同じ RoomPolicy を呼ぶのが肝。

§単一ポリシー（実装イメージ）

独立インタビューアプリ（Next.js / TypeScript）側の単一ポリシー。HTTP・チャット/データ送信・メディアトークン発行の全実行点がこの can を呼ぶ。能力定義は「目標能力」のプリセット。

// RoomPolicy — インタビュールーム認可の単一ポリシー
type Role = 'moderator' | 'panelist' | 'observer' | 'minedia_observer';
type Capability =
  | 'join' | 'publish' | 'subscribe'
  | 'chat_public' | 'chat_private' | 'chat_observer' | 'chat_read_all' | 'chat_read_private'
  | 'handout_present' | 'handout_view'
  | 'recording_control' | 'moderate' | 'invite';

// recording_access（事後の録画アクセス）はここに含めない：
// 入室ロールでなく公開API側の認可ドメイン（Devise+CanCanCan / ot_archive_access 共有リンク）
const CAPABILITIES: Record<Role, Capability[]> = {
  moderator:        ['join', 'publish', 'subscribe', 'chat_public', 'chat_private', 'chat_observer',
                     'chat_read_all', 'handout_present', 'recording_control', 'moderate', 'invite'],
  panelist:         ['join', 'publish', 'subscribe', 'chat_public', 'handout_view'],
  observer:         ['join', 'subscribe', 'chat_observer', 'chat_read_private', 'handout_view'],
  // テナント横断観察は L0 例外＋監査。現状コードでは公開チャット投稿能力が追加で存在する点に注意
  minedia_observer: ['join', 'subscribe', 'chat_observer', 'chat_read_private', 'handout_view'],
};

export function can(ctx: Context, capability: Capability, resource?: { tenantId: string }): boolean {
  // L0: テナント分離（resource があれば必ず突合。minedia_observer のみ例外＋監査）
  if (resource && resource.tenantId !== ctx.tenantId && ctx.role !== 'minedia_observer') return false;
  // L2/L3: 能力
  return CAPABILITIES[ctx.role]?.includes(capability) ?? false;
}

// L4: メディアエンジン用 grant へ翻訳
export function mediaGrants(ctx: Context) {
  return {
    canPublish:   can(ctx, 'publish'),
    canSubscribe: can(ctx, 'subscribe'),
    roomAdmin:    can(ctx, 'moderate'),
  };
}

§role の責務分界 — 決定 / 封入署名 / 強制

「role を JWT に仕込むのは誰の責務か」を正確に分ける。

「2種類のクライアント」— ここが認可の急所

「クライアント申告を信用しない」の“クライアント”はエンドユーザー（ブラウザ）を指す。テナントサーバーの依頼とは別物。

「role はテナントが決めてよい」が「ブラウザが勝手に名乗るのはダメ」。Model A では、テナントの認証済み依頼を受けて基盤がトークンに封入・署名し、以後ブラウザはその署名済み role を改変できない。基盤は無検証で封入せず、role が既知の許可ロールかを検証する（未知ロールや不正値を弾く）。

role はトークン単位。scope は任意（機能制限ではない）

role は API キーに焼き込まない。role は「(参加者 × ルーム)」の属性で、参加トークン発行のたびに指定する。1 本の API キーが moderator も panelist も observer も全員分のトークンを発行する。

§テナント分離（L0）の強制メカニクス

最も重大な認可境界。漏れたら全テナントのデータ流出なので多層で守る。

§Open Questions — 要意思決定

現状整理が必要な意思決定事項。

1. minedia_observer を observer に統合するか / 統合しない場合の命名

ロール名のブランド依存（minedia 接頭辞）は OEM/ホワイトラベルでリークする。能力差は現状コードでは存在（minedia_observer のみ公開チャット投稿可）だが、目標では observer と同能力。これを踏まえ：

• 案A（リネーム）：別ロールのまま platform_observer 等へ改名。L0 例外はロール名キーで継続。
• 案B（統合）：observer 1 本に統合し、「テナント横断観察」は能力（role）でなくスコープ / Context 属性（例 cross_tenant）で表現。L0 例外をロール名照合から外せる。
• 関連論点：テナント横断観察の監査ログ必須＋テナント同意のガバナンス。L0 例外分岐は MT-ready のためコードは最初から書くが、PoC は tenant 0 のみで越境の発火経路なし。監査ログは契約予約のみ・実装は v2。

ステータス：チーム協議中。

2. 公開APIのスコープ

PoC では scope 不要（列だけ MT-ready 用に残す）。本番／MT での権限境界が未定：

• API key の scope で「割り当て可能 role の範囲」を縛るか。
• 鍵の最小権限分離（トークン発行専用キー vs 管理キー＝漏洩時の被害局所化）。
• テナント管理API（room/slot/project CRUD）の認可境界。
• recording.access（アーカイブ取得・共有）の認可主体：基盤かテナントか。録画の事後処理（文字起こし/要約）は調査ドメイン（minedia-www）。

ステータス：チーム協議中。

3. 時間窓ゲート

現状 can_enter_interview_room? の時間窓を、トークンの nbf / exp と二重化するか一本化するか。