権限

強力な機能のための権限との連携

W3C作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/WD-permissions-20251006/
最新公開バージョン:
https://www.w3.org/TR/permissions/
最新エディタ草案:
https://w3c.github.io/permissions/
履歴:
https://www.w3.org/standards/history/permissions/
コミット履歴
編集者:
Marcos Cáceres (Apple Inc.)
Mike Taylor (Google LLC)
元編集者:
Mounir Lamouri (Google LLC)
Jeffrey Yasskin (Google LLC)
フィードバック:
GitHub w3c/permissions (プルリクエスト, 新しい課題, オープン課題)
ブラウザーサポート:
Chromeロゴ43
Edgeロゴ79
Firefoxロゴ46
Safariロゴ16.0
デスクトップ
Android Chromeロゴ141
Android Firefoxロゴ143
Android UCロゴ15.5
iOS Safariロゴ16.0
Samsung Internetロゴ4
モバイル
詳細情報

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

この仕様は、他の仕様がブラウザー権限と連携するために利用できる共通インフラストラクチャを定義します。これらの権限は、ユーザーがプラットフォームの「強力な機能」へのアクセスを許可または拒否する選択を表します。開発者向けに、本仕様は強力な機能の権限状態を照会し、その権限状態が変更された場合に通知を受け取るためのAPIを標準化します。

この文書のステータス

このセクションは、本書が公開された時点での文書のステータスを示します。現在のW3C 公開物と、この技術レポートの最新リビジョンは W3C 標準・草案一覧で確認できます。

本仕様は進行中の作業です。

この文書はWebアプリケーションセキュリティ作業グループによって 勧告トラックで作業草案として公開されました。

作業草案としての公開は W3Cおよびそのメンバーによる支持を意味するものではありません。

この文書はドラフトであり、随時更新・置換・廃止される可能性があります。他の文書の引用には適切ではありません。

本書は W3C 特許ポリシーの下で活動するグループによって作成されました。 W3Cは グループ成果物に関連する特許開示の公開リスト を管理しています。このページには特許開示の方法も記載されています。ある個人が「必須クレーム」を含むと考える特許について実際の知識がある場合、その情報は W3C特許ポリシー第6章に従って開示しなければなりません。

この文書は 2025年8月18日 W3Cプロセス文書に従います。

1. はじめに

このセクションは規範的ではありません。

仕様は、強力な機能として明示的に識別される機能を定義できます。これらの機能は、プライバシー、セキュリティ、およびパフォーマンスに大きな影響を与える可能性があることから「強力」とされます。そのため、ユーザーはユーザーエージェントがサイトによるこれらの機能の利用を明示的な許可があるまで拒否することを頼りにしており、通常はこの能力が一定期間のみ付与されます。サイトに強力な機能の利用を許可する明示的な許可は、主にブラウザーUIを通じて与えられ、管理されます（下図参照）。

左側: サイト example.com が通知を送信したい旨の通知プロンプト（許可・拒否ボタンあり）のモック。右側: URLバー付近でカメラ・マイクへの権限付与を求めるプロンプトのモック。
図 1 権限プロンプトタイプのスケッチ

この意味で、権限は特定の機能、特に「強力な機能」に対するユーザー同意の現在の状態を表します。最終的にはユーザーがこれらの権限を管理する権利を持ち、手動で権限を付与・拒否できます。さらに、ユーザーエージェントは、煩わしい権限プロンプトを非表示にしたり自動的に拒否したり、一定期間サイトを訪問しない場合に付与済みの権限を自動で失効させるなど、権限管理を支援します。

ユーザーが位置情報、カメラ、マイク、モーションセンサー、通知の権限のデフォルト設定・リセットを行える設定ページのモック。
図 2 サイトごとの権限設定UIのスケッチ

2. 利用例

このセクションは規範的ではありません。

この例では、Permissions API を使い、ローカルニュースをGeolocation APIで表示するか、機能追加ボタンを表示するかを決定します。

例 1: .state属性の利用 
const { state } = await navigator.permissions.query({
  name: "geolocation"
});
switch (state) {
  case "granted":
    showLocalNewsWithGeolocation();
    break;
  case "prompt":
    showButtonToEnableLocalNews();
    break;
  case "denied":
    showNationalNews();
    break;
}

この例では"geolocation"および"notifications" 強力な機能の状態を同時に確認しています:

例 2: 複数権限の状態確認 
const queryPromises = ["geolocation", "notifications"].map(
  name => navigator.permissions.query({ name })
);
for await (const status of queryPromises) {
  console.log(`${status.name}: ${status.state}`);
}

この例は利用可能なカメラの権限状態を確認しています。

例 3: 複数カメラの権限状態確認 
const devices = await navigator.mediaDevices.enumerateDevices();

// ビデオ入力のみ抽出し、クエリオブジェクトに変換
const queries = devices
  .filter(({ kind }) => kind === "videoinput")
  .map(({ deviceId }) => ({ name: "camera", deviceId }));

const promises = queries.map((queryObj) =>
  navigator.permissions.query(queryObj)
);

try {
  const results = await Promise.all(promises);
  // 各カメラの状態をログ出力
  results.forEach(({ state }, i) => console.log("Camera", i, state));
} catch (error) {
  console.error(error);
}

3. モデル

このセクションでは、Webプラットフォーム上で権限を使って強力な機能を利用するためのモデルを規定します。

3.1 権限

権限は、ユーザーがウェブアプリケーションに強力な機能の利用を許可するかどうかの意思決定を表します。この決定は権限の状態として表現されます。

明示的な許可は、ユーザーがウェブアプリケーションに許可を与え、強力な機能を利用できるようにすることを指します。

注: 制限と拡張性

概念的には、permission の powerful feature は、次のいずれかの 状態 になり得ます：

"denied":
ユーザーまたはユーザーエージェントが、その強力な機能へのアクセスを拒否した状態。呼び出し元はその機能を利用できません。
"granted":
ユーザーまたはユーザーエージェントが明示的な許可を与えた状態。呼び出し元は、ユーザーエージェントによる追加許可確認なしで機能を利用できる場合があります。
"prompt":
ユーザーが機能の明示的な許可を与えていない状態（"denied"と同じ）。呼び出し元が機能を利用しようとすると、ユーザーエージェントがユーザーに権限確認プロンプトを表示するか、アクセスが"denied"となります。

ユーザー意図に関する新情報を特定するために、ユーザーエージェントはユーザーの意図に関する情報を収集・解釈する場合があります。この情報は、明示的なユーザー操作、当該ユーザーや他のユーザーの集約的行動、またはこの仕様が予期しない暗黙的シグナルから得られます。

注: 暗黙的シグナルとは？

すべての権限には存続期間があり、特定の権限が"granted"であり続ける期間を示します。期間が終了するとデフォルト状態に戻ります。存続期間は、特定のRealmが破棄されるまで、トップレベルのブラウジングコンテキストが破棄されるまで、一定期間、または無限など、さまざまです。期間はエンドユーザーとユーザーエージェント間で、強力な機能の明示的な許可（通常は権限UIやユーザーエージェントのポリシー）付与時に交渉されます。

すべての権限にはデフォルト状態（通常は"prompt"）があり、ユーザーがまだ機能の明示的な許可を与えていないか、存続期間が切れてリセットされた場合の状態です。

3.2 パーミッションストア

ユーザーエージェントは単一のパーミッションストアを保持します。これはリストであり、パーミッションストアエントリの集まりです。各エントリは、そのディスクリプタとキーによって識別され、このリストに最大1回のみ現れます。

ユーザーエージェントは、任意で、各エントリをパーミッションストアから削除することができます。これは、それぞれのパーミッションの有効期間が満了した場合に限ります。

パーミッションストアエントリとは、タプルであり、PermissionDescriptorディスクリプタ、パーミッションキーキー、そして状態状態の組み合わせです。

パーミッションストアエントリを取得するためには、 PermissionDescriptor descriptor と パーミッションキー key を与えられた場合、以下を実行します：

  1. ユーザーエージェントのパーミッションストアが、エントリを含む場合、 そのディスクリプタが descriptor であり、 キーが 等しい 場合（descriptorに基づく）、そのエントリを返します。
  2. nullを返します。

パーミッションストアエントリを設定するためには、 PermissionDescriptor descriptor、パーミッションキー key、 そして状態 stateが与えられた場合、次の手順を実行します：

  1. newEntryを新規のパーミッションストアエントリとし、そのディスクリプタは descriptor、キーは key、 状態は stateであるものとします。
  2. ユーザーエージェントのパーミッションストアが、エントリを含む場合、 そのディスクリプタが descriptor であり、キーが 等しい 場合（descriptorに基づく）、そのエントリを newEntryで置き換えて、これ以降の手順を中止します。
  3. newEntryをユーザーエージェントのパーミッションストアに追加します。

パーミッションストアエントリを削除するためには、 PermissionDescriptor descriptor と パーミッションキー key が与えられた場合、次の手順を実行します：

  1. ユーザーエージェントのパーミッションストアから、 エントリ（ディスクリプタが descriptor、キーが 等しい （descriptorに基づく）もの）を削除します。

パーミッションキーは、各機能のパーミッションキー型によって型が定義されます。

注

パーミッションキー key1が、等しいかどうかを判断するには、パーミッションキー key2、および PermissionDescriptor descriptor が与えられた場合、次の手順を実行します：

  1. もしkey1が descriptor のパーミッションキー型でなければ、または key2が descriptor のパーミッションキー型でなければ、falseを返します。
  2. パーミッションキー比較アルゴリズムを、descriptorのnameで指定された機能名に対して、key1とkey2を渡して実行した結果を返します。

3.3 強力な機能

強力な機能は、ユーザーが明示的な許可を与えなければ利用できないWebプラットフォーム機能（通常はAPI）です。通知API現行標準など一部例外を除き、ほとんどの強力な機能はポリシー制御機能でもあります。ポリシー制御機能でもある強力な機能については、[Permissions-Policy]が、文書が特定の機能を利用できるかどうかを制御します。つまり、強力な機能は、対応するポリシー制御機能によって権限が委譲された場合にのみ、ユーザーから明示的な許可の要求が可能となります（下記例参照）。以降は、ユーザーが"granted"権限を持つか、権限付与と同等の条件を満たすことで機能利用が可能となります。

強力な機能は文字列リテラル（例: "geolocation"）で表される名前によって識別されます。

ユーザーエージェントは、ユーザーがどの強力な機能の権限を持つかを環境設定オブジェクトで追跡します。

3.3.1 側面

各強力な機能は、追加の側面を0個以上定義できます。側面はWebIDL辞書として定義され、PermissionDescriptorの継承を利用し、その機能の権限ディスクリプタ型となります。

3.4 権限タスクソース

権限タスクソースは、この仕様で権限関連のタスクを実行する際に利用されるタスクソースです。

4. 強力な機能の仕様化

適合する仕様が強力な機能を仕様化する場合、次を行う：

  1. 必須：強力な機能に名前（ASCII小文字列）を付与する。
  2. 任意：権限ディスクリプタ型（PermissionDescriptorを継承）を定義する。
  3. 任意：側面を0個以上定義する。
  4. 任意：特定の強力な機能に適さない場合、以下のアルゴリズムや型を上書きできる。
  5. 必須：強力な機能をPermissions Registryに登録する。

新たに仕様化された強力な機能をPermissions Registryに登録することで、本作業グループがフィードバックを提供し、仕様との統合が適切に行われているか確認できます。

権限ディスクリプタ型：

PermissionDescriptorまたはそのサブタイプ。未指定の場合は PermissionDescriptorとなります。

機能はディスクリプタインスタンスに部分順序を定義できます。descriptorAがstronger than（より強い）descriptorBの場合、descriptorAの 権限状態が"granted"なら、descriptorBの権限状態も"granted"とし、descriptorBの権限状態が"denied"なら、descriptorAの権限状態も "denied"でなければなりません。

権限状態の制約：
ユーザーエージェントがディスクリプタの権限状態として返せる値の制約。デフォルトはユーザーの意図以外の制約なし。
追加権限データ型：

一部の強力な機能には、PermissionState以外に追加情報が関連付けられています。各機能は追加権限データ型を定義します。

注

例えば、getUserMedia()は、ユーザーがどのカメラの利用を許可したか判定する必要があります。

DOMString nameがこれらの機能の一つの場合、nameの 追加権限データ（任意の環境設定オブジェクト settings）は次のアルゴリズムで得られる：

  1. settingsが未指定なら、現在の設定オブジェクトにする。
  2. 同じnameとsettingsで以前呼び出した結果previousResultがあり、以降ユーザー意図の新情報がなければpreviousResultを返す。
  3. UAのユーザー意図およびnameの追加権限データ制約も考慮し、nameの追加権限データ型インスタンスを返す。

指定されていれば、この機能の追加権限データアルゴリズムが利用可能です。

任意の追加権限データ制約：
ユーザーエージェントが強力な機能の 追加権限データとして返せる値の制約。デフォルトはユーザー意図以外の制約なし。
権限結果型：
PermissionStatusまたはそのサブタイプ。未指定の場合は PermissionStatusとなります。
権限クエリアルゴリズム：

権限ディスクリプタ型インスタンスと、新規または既存の権限結果型インスタンスを受け取り、クエリ結果で権限結果型インスタンスを更新する。Permissionsのquery(permissionDesc)メソッドや PermissionStatus更新手順で利用。未指定の場合はデフォルト権限クエリアルゴリズムとなる。

デフォルト権限クエリアルゴリズムは、 PermissionDescriptor permissionDescとPermissionStatus statusを受け取り、次の手順を実行：

  1. statusのstateにpermissionDescの 権限状態を設定する。
権限キー型：

機能が使用する権限キーの型。デフォルトはorigin。独自の権限キー型を指定する場合は、 権限キー生成アルゴリズムも必須です。

許可キー生成アルゴリズム:

オリジン origin と オリジン embedded origin を受け取り、新しい 許可キー を返します。指定されていない場合、これは デフォルト許可キー生成アルゴリズム になります。カスタムの 許可キー生成アルゴリズム を指定する機能は、必ず 許可キー比較アルゴリズム も指定しなければなりません。

デフォルト許可キー生成アルゴリズム は、 オリジン origin と オリジン embedded origin が与えられた場合、次の手順を実行します:

  1. origin を返す。
注記: 権限の委譲
権限キー比較アルゴリズム：

2つの権限キーを受け取り、両者が等価かどうかの真偽値を返します。未指定の場合、デフォルト権限キー比較アルゴリズムとなります。

デフォルト権限キー比較アルゴリズムは、 権限キー key1, key2を受け取り、次の手順を実行します：

  1. key1がkey2と同一オリジンならtrueを返します。
権限取り消しアルゴリズム：

引数なし。権限状態や追加権限データの変更結果と同期すべき実装の他部分を更新します。

未指定の場合、権限取り消しへの反応を実行します。

権限の存続期間：

複数の強力な機能を定義する仕様は、各機能に最適な権限の存続期間の提案が望ましいです（推奨）。期間決定の指針は下記注記参照（ユーザープライバシー重視）。未指定の場合はユーザーエージェントが期間を提供します。

オリジンの権限存続期間が切れた場合：

  1. 権限をデフォルトの権限状態（例："prompt"）に戻す。
  2. 当該オリジンの各browsing context（存在すれば）について、グローバルタスクをキューし、権限タスクソースでbrowsing contextのグローバルオブジェクトに権限取り消しアルゴリズムを実行する。
注: 権限存続期間の決定
デフォルト権限状態：

PermissionState値。強力な機能の権限のデフォルト状態。

未指定時は権限のデフォルト状態は "prompt"。

デフォルト強力な機能は、上記すべての型・アルゴリズムがデフォルト値である強力な機能である。

5. 権限インターフェイス用アルゴリズム

5.1 現在の権限状態の読み取り

現在の権限状態を取得するには、name nameと任意の 環境設定オブジェクト settingsを受け取り、以下の手順を実行する。このアルゴリズムはPermissionState列挙値を返す。

  1. descriptorを新規作成し、PermissionDescriptor のnameをnameで初期化する。
  2. descriptorのsettings付き権限状態を返す。

descriptorの権限状態は、任意の 環境設定オブジェクト settingsを受け取り、以下のアルゴリズムを実行する。PermissionState列挙値を返す:

  1. settingsが未指定なら、現在の設定オブジェクトにする。
  2. settingsが非セキュアコンテキストなら、"denied"を返す。
  3. featureをdescriptorのnameとする。
  4. もしfeatureに対応するポリシー制御機能が存在し、settingsの関連グローバルオブジェクトが関連Documentを持つ場合、以下を実行:
    1. documentをsettingsの関連グローバルオブジェクトの 関連Documentとする。
    2. documentがfeatureの利用許可されていなければ、 "denied"を返す。
  5. key を、descriptor、settings の トップレベルオリジン および settings の オリジン で 許可キー生成を実行 した結果とする。
  6. entryをdescriptorとkeyで権限ストアエントリ取得の結果とする。
  7. entryがnullでなければ、entryのstateからPermissionState列挙値を返す。
  8. featureの権限状態を表すPermissionState列挙値を、descriptorのnameの権限状態制約も考慮して返す。

簡易表現として、DOMString nameの権限状態は、PermissionDescriptorのnameにnameを設定したものの権限状態である。

5.2 強力な機能の権限要求

descriptorに対して利用権限を要求するには、UAは以下の手順を実行する。このアルゴリズムは"granted"または"denied"を返す。

  1. current stateをdescriptorの権限状態とする。
  2. current stateが"prompt"でなければ、 current stateを返し、以降の手順を中止する。
  3. 呼び出しアルゴリズムが利用する強力な機能について、ユーザーに明示的な許可を求める。
  4. ユーザーが強力な機能利用を明示的に許可すれば、current stateを"granted"に、そうでなければ"denied"にする。ユーザー操作によってユーザー意図の新情報が得られる場合がある。
    注

    権限UIやUAがユーザー意図をどう推定するかの詳細はあえて曖昧にしている。この枠組みの中で様々なUIをUAが試せるようにしている。

  5. settings を 現在の設定オブジェクト とする。
  6. key を、descriptor、settings の トップレベルオリジン および settings の オリジン で 許可キー生成 を実行した結果とする。
  7. タスクキューで、現在の設定オブジェクトの責任イベントループ上で、権限ストアエントリ設定をdescriptor、key、current stateで実行する。
  8. current stateを返す。

簡略表記として、利用許可をリクエストする際に、DOMString nameを指定することは、 利用許可をリクエストするために、PermissionDescriptorの nameメンバーにnameを設定したものと同じ意味となります。

5.3 ユーザーへの選択プロンプト

ユーザーへの選択プロンプトは、options（descriptorに関連付け）と、任意のboolean allowMultiple（デフォルトfalse）を受け、UAは以下の手順を実行する。このアルゴリズムは"denied"またはユーザーの選択を返す。

  1. descriptorの権限状態が"denied"なら、 "denied"を返し、以降の手順を中止する。
  2. descriptorの権限状態が"granted"なら、 UAはoptionsの中からユーザーが選択した1つ（allowMultipleがtrueなら複数）の値を返し、以降の手順を中止できる。プロンプトせずに返した場合、同じ選択肢・同じdescriptorで再度プロンプトした場合も同じ選択肢を返さなければならない（ただしユーザー意図の新情報取得時を除く）。
  3. ユーザーに1つ以上のoptionsの選択か権限拒否を求め、選択を待つ:
    1. 呼び出しアルゴリズムがプロンプトに追加情報を指定した場合、それを含める。
    2. allowMultipleがfalseなら、optionsから1つのみ選択可能；trueなら複数選択可能。
  4. ユーザーが1つ以上選択したらそれを返す。選択しなければ"denied"を返す。
    注

    権限UIやUAがユーザー意図をどう推定するかの詳細はあえて曖昧にしている。この枠組みの中で様々なUI（例：プロンプトがタイムアウトして自動的に"denied"を返すなど）をUAが試せるようにしている。

簡易表現として、ユーザーへの選択プロンプトをDOMString nameの選択肢で行う場合は、 PermissionDescriptorのnameにnameを設定したものの選択肢で行うことと同じ。

5.4 権限の取り消しへの対応

UAが、ユーザーがdescriptor（PermissionDescriptor）で記述された機能の権限付与をもはや望まなくなったことを知った場合、権限取り消しへの反応として以下を実行する:

  1. descriptorのnameに対応する権限取り消しアルゴリズムを実行する。
  2. descriptorとkeyで権限ストアエントリ削除を実行する。

6. 権限API 

WebIDL[Exposed=(Window)]
partial interface Navigator {
  [SameObject] readonly attribute Permissions permissions;
};

[Exposed=(Worker)]
partial interface WorkerNavigator {
  [SameObject] readonly attribute Permissions permissions;
};

6.2 Permissionsインターフェイス 

WebIDL[Exposed=(Window,Worker)]
interface Permissions {
  Promise<PermissionStatus> query(object permissionDesc);
};

dictionary PermissionDescriptor {
  required DOMString name;
};

6.2.1 query()メソッド

query()メソッドが呼び出された場合、ユーザーエージェントは次の権限クエリアルゴリズムをpermissionDesc引数で実行する：

  1. thisの関連グローバルオブジェクトがWindowオブジェクトなら：
    1. 現在の設定オブジェクトの関連Documentが 完全にアクティブでなければ、Promiseをrejectし、 "InvalidStateError" DOMExceptionを返す。
  2. rootDescをpermissionDescで参照されるオブジェクトをIDL値に変換し、型をPermissionDescriptorとする。
  3. 変換時に例外が発生した場合、その例外でPromiseをrejectする。
  4. rootDesc["name"]がサポートされていなければ、Promiseをrejectし、TypeErrorを返す。
    注: なぜenumではないのか？
  5. typedDescriptorをpermissionDescで参照されるオブジェクトを、rootDescのnameの権限ディスクリプタ型に変換したものとする。
  6. 変換時に例外が発生した場合、その例外でPromiseをrejectする。
  7. promiseを新しいpromiseにする。
  8. promiseを返し、並行して以下を実行する：
    1. statusをtypedDescriptorでPermissionStatus生成したものとする。
    2. queryをstatusの[[query]]内部スロットとする。
    3. queryのnameの権限クエリアルゴリズムをqueryとstatusで実行する。
    4. グローバルタスクをキューし、権限タスクソース上でthisの関連グローバルオブジェクトにpromiseをstatusで解決する。

6.3 PermissionStatusインターフェイス 

WebIDL[Exposed=(Window,Worker)]
interface PermissionStatus : EventTarget {
  readonly attribute PermissionState state;
  readonly attribute DOMString name;
  attribute EventHandler onchange;
};

enum PermissionState {
  "granted",
  "denied",
  "prompt",
};

PermissionStatusインスタンスは、機能ごとの権限ディスクリプタ型インスタンスを保持する[[query]]内部スロットとともに生成される。

"granted"、"denied"、"prompt"列挙値は、それぞれ"granted"、"denied"、"prompt"の概念を表す。

6.3.1 インスタンスの生成

PermissionDescriptor permissionDescに対してPermissionStatus生成する手順：

  1. permissionDesc の name を name とする。
  2. name で特定される 機能が、ユーザーエージェントによってサポートされていることをアサートする。
  3. name で特定される パーミッション結果型 の新しいインスタンスを status とする：
    1. status の [[query]] 内部スロットを permissionDesc で初期化する。
    2. status の name を name で初期化する。
  4. status を返す。

6.3.2 name属性

name属性は初期化時の値を返す。

6.3.3 state属性

state属性は、現在のインスタンスにセットされた最新値を返す。

6.3.4 onchange属性

onchange属性は、対応するイベントハンドラであり、対応イベントタイプはchange。

PermissionStatusインスタンスstatusの状態が変更されたことをUAが認識した場合、非同期でPermissionStatus 更新手順を実行する：

  1. this の 関連グローバルオブジェクトが Window オブジェクトの場合：
    1. document を status の 関連グローバルオブジェクトの 関連付けられた Document とする。
    2. document が null または document が 完全にアクティブでない場合、 このアルゴリズムを終了する。
  2. query を status の [[query]] 内部スロットとする。
  3. query の name の パーミッションクエリアルゴリズムを実行し、query と status を渡す。
  4. タスクをキューに追加し、permissions task source上で イベントを発火する。 イベント名は change で、対象は status である。

6.3.5 ガベージコレクション

PermissionStatusオブジェクトは、change型のイベントリスナーを持つ場合、ガベージコレクションされてはならない。

7. 適合性

非規範的と明記されているセクションに加え、本仕様書のすべての著作ガイドライン、図、例、および注記は非規範的です。それ以外はすべて規範的です。

この文書において、MAY、MUST、MUST NOT、OPTIONAL、SHOULDのキーワードは、 BCP 14 [RFC2119] [RFC8174] に記載されている通り、すべて大文字で示されている場合にのみ、ここで示す意味で解釈されます。

本仕様に適合を主張できる製品は2種類あります：ユーザーエージェントおよび その他の仕様（すなわち、本仕様の要件に準拠した方法で強力な機能を仕様化する技術報告）。

A. Permissions Policy仕様との関係

このセクションは非規範的です。

本仕様とPermissions Policy仕様はともに「権限」を扱いますが、各仕様はプラットフォーム上で異なる目的を持ちます。ただし、両者には明確な重複があります。

一方で、本仕様は強力な機能のみを対象とし、そのアクセスはユーザーエージェントを介した権限UIによって管理されます（すなわち、ユーザーの明示的な同意がなければ利用できず、ユーザーはいつでも理由を問わず権限を拒否可能）。これらの強力な機能はPermissions Registryに登録されています。

他方、Permissions Policy仕様は、開発者が「permissions policy」（HTTPヘッダーやallow属性）を使って、ポリシー制御機能の有効・無効を選択的に制御できるようにします。この意味で、Permissions Policyは本仕様を包括し、Permissions Policyが機能の利用可否を独立して管理します。これらのポリシー制御機能もPermissions Registryに登録されています。

Permissions Policy仕様によって無効化された強力な機能は、本仕様ではその権限状態が常に"denied"となります。 これは現在の権限状態の読み取りが、[HTML]の「利用許可」判定に依存しており、これがPermissions Policy仕様に委譲されるためです。両仕様で権限名を共有していることも重要です。どちらも他の仕様が権限の名前やnameを定義することに依存しており、通常同じ名称（例："geolocation"）が使われます。

最後に、強力な機能はPermissions Policy仕様のいかなる手段によっても"granted"状態になることはありません。強力な機能が"granted"となる唯一の方法は、ユーザーの明示的な許可またはUAポリシーによるものです。

B. 自動テスト

ユーザーエージェントの自動化およびアプリケーションテストのために、本書は [WebDriver] および [WebDriver-BiDi] 仕様への拡張を定義します。UAがこれらをサポートするかどうかは任意です。 

WebIDLdictionary PermissionSetParameters {
  required object descriptor;
  required PermissionState state;
};

パーミッションを設定するには、PermissionDescriptor descriptor、PermissionState state、オプションの permission key key、オプションの user agent を与えられたとき、次の手順を実行する：

  1. target key を、許可キー生成 を descriptor、現在の設定オブジェクト の トップレベルオリジン と 現在の設定オブジェクト の オリジン で実行した結果、もし key が null ならその値、そうでなければ key とする。
  2. settings list を、指定があれば user agent に属するすべての 環境設定オブジェクト の リスト、指定がなければすべてのユーザーエージェントのものとする。
  3. targets を空の リスト とする。
  4. 各 環境設定オブジェクト settings について settings list を反復する:
    1. settings key を、許可キー生成 を descriptor、settings の トップレベルオリジン および settings の オリジン で実行した結果とする。
    2. matches を、許可キー比較アルゴリズム を descriptor、settings key および key で実行した結果とする。
    3. もし matches なら、append で settings を targets に追加する。
  5. tasks を空の リスト とする。
  6. 各 環境設定オブジェクト target について targets を反復する:
    1. タスクをキューに追加 し、task を permissions task source に target の 関連設定オブジェクト の グローバルオブジェクト の ブラウジングコンテキスト に 次の手順を実行するために追加する:
      1. state を、permission state を descriptor、引数 target でこの瞬間に呼び出した結果として解釈する。
    2. append で task を tasks に追加する。
  7. tasks 内のすべてのタスクの実行が完了するまで待機し、リターンする。

B.1 [WebDriver]による自動テスト

本書は[WebDriver]仕様の拡張コマンドを以下の通り定義します。

B.1.1 権限設定

HTTPメソッド URIテンプレート
POST /session/{session id}/permissions

権限設定 拡張コマンドは、PermissionDescriptorの 権限状態をユーザーが変更したかのようにシミュレートします。

リモートエンド手順は以下の通りです：

  1. parametersDictをparameters引数をIDL値型 PermissionSetParametersに変換したものとします。例外が発生した場合、invalid argument errorを返します。
  2. parametersDict.state が実装依存で不適切な 権限状態なら、invalid argument errorを返します。
    注

    例：UAが"midi" 強力な機能を「常に有効」と定義している場合、この手順で権限状態を"denied"に設定するコマンドを拒否できます。

  3. rootDescをparametersDict.descriptorとする。
  4. typedDescriptorをrootDescをIDL値に変換したもの（権限ディスクリプタ型で、Get(rootDesc, "name")の結果に一致）とする。例外が発生した場合、invalid argument errorを返す。
  5. 権限設定をtypedDescriptorと parametersDict.stateで実行する。
  6. データnullでsuccessを返す。

B.2 [WebDriver-BiDi]による自動テスト

本書は[WebDriver-BiDi]仕様の拡張モジュールを以下の通り定義します。

B.2.1 permissionsモジュール

permissionsモジュールは、リモートエンドブラウザー権限管理用コマンドを含みます。

B.2.1.1 定義

{^remote end definition^} 

PermissionsCommand = (
  permissions.setPermission
)
B.2.1.2 型
B.2.1.2.1 permissions.PermissionDescriptor型 
permissions.PermissionDescriptor = {
  name: text,
}

permissions.PermissionDescriptor型はPermissionDescriptorを表します。

B.2.1.2.2 permissions.PermissionState型 
permissions.PermissionState = "granted" / "denied" / "prompt"

permissions.PermissionState型はPermissionStateを表します。

B.2.1.3 コマンド
B.2.1.3.1 permissions.setPermissionコマンド

権限設定 コマンドは、PermissionDescriptorの権限状態をユーザーが変更したかのようにシミュレートします。

コマンド型 
permissions.setPermission = (
  method: "permissions.setPermission",
  params: permissions.SetPermissionParameters
)

permissions.SetPermissionParameters = {
  descriptor: permissions.PermissionDescriptor,
  state: permissions.PermissionState,
  origin: text,
  ? embeddedOrigin: text,
  ? userContext: text,
}
結果型
EmptyResult

リモートエンド手順 （session、command parameters）は以下の通り：

  1. descriptorをcommand parametersのdescriptorフィールド値とする。
  2. permission nameをdescriptorのnameフィールド値（nameを表す）とする。
  3. stateをcommand parametersのstateフィールド値とする。
  4. user context idをcommand parametersのuserContextフィールド値（存在しなければdefault）とする。
  5. stateが実装依存で不適切な権限状態なら、error（error codeはinvalid argument）を返す。
  6. typedDescriptorをdescriptorをIDL値（descriptor, state）で、PermissionSetParametersのpermission nameの権限ディスクリプタ型に変換したものとする。例外が発生した場合、error（error codeはinvalid argument）を返す。
  7. origin を command parameters の origin フィールドの値とする。
  8. embedded origin を command parameters の embeddedOrigin フィールドの値（存在する場合）、存在しない場合は origin とする。
  9. key を、descriptor、origin および embedded origin で 許可キー生成 を実行した結果とする。
  10. user agent を、user context id を持つ ユーザーコンテキスト を表す ユーザーエージェント とする。
  11. パーミッションを設定するを typedDescriptor, state, key, user agent で実行する。
  12. success を data null とともに返す。

C. 権限レジストリ

このセクションは非規範的です。

C.1 目的

このW3Cレジストリは、Webプラットフォームのポリシー制御機能および強力な機能を一元的に検索する場所を提供します。変更プロセスを通して、プラットフォーム上の権限が様々な仕様間で一貫して定義されていることを保証します。

権限レジストリを標準化権限と暫定権限に分けることで、これらの機能のステータスを追跡する手段も提供します。

C.2 変更プロセス

このレジストリの追加・更新のための変更プロセスは以下の通りです：

  1. 必要に応じて、仕様書に「Permissions Policy」セクションを追加し、次の内容を含めます：
    1. ポリシー制御機能を識別する文字列（例："super-awesome"）。この文字列がリンク可能になるよう、dfn要素でラップしてください。
    2. デフォルト許可リスト値（例：'self'）。
  2. 自分の機能が強力な機能（利用に明示的な許可が必要）かどうかを判断します。該当する場合：
    1. 強力な機能を仕様化することを、Permissions仕様に準拠して記述する。
  3. 標準化権限表または暫定権限表のいずれかを修正し、必要な情報を各列に記入します。
  4. 変更を含むプルリクエストをPowerful Features Registry Repository（GitHub）へ提出してください。リポジトリ管理者が内容をレビューし、統合が適切か確認します。

C.3 標準化権限のレジストリ表

権限が標準化権限表に掲載され、標準化権限とみなされるには、以下の条件を満たす必要があります：

各権限は一意のリテラル文字列で識別されます。Permissions Policyの場合、その文字列はポリシー制御機能を識別します。同様にPermissions仕様の場合も、その文字列は強力な機能を識別します。

注: 権限とPermissions Policy
Webプラットフォーム標準化権限表
識別文字列 ポリシー制御機能か？ 強力な機能か？ 仕様 実装状況
Chromium Gecko WebKit
"geolocation" YES YES Geolocation YES YES YES
"notifications" NO YES Notifications API現行標準 YES YES YES
"push" NO YES Push API YES YES YES
"web-share" YES NO Web Share API YES YES YES

C.4 暫定権限のレジストリ表

暫定権限とは、まだ標準化権限となっていない権限です（実験的、インキュベーション中、あるいは1つのブラウザーエンジンでしか実装されていないもの）。

暫定権限表
識別文字列 ポリシー制御機能か？ 強力な機能か？ 仕様 実装状況
Chromium Gecko WebKit
"accelerometer" YES YES Device Orientation and Motion YES NO NO
"window-management" YES YES Window Management YES NO NO
"local-fonts" YES YES Local Font Access API YES NO NO

D. プライバシーの考慮事項

攻撃者は、権限状態をエンドユーザーの「フィンガープリント」作成要素として利用する可能性があります。攻撃者は、APIを実際に利用することで権限の状態を判定できますが、その場合多くはエンドユーザーにUIプロンプトが表示されます（権限が既に"granted"でない場合）。このAPIはウェブサイトに新たなフィンガープリント情報を公開するものではありませんが、攻撃者がこの情報に目立たずアクセスしやすくなる可能性があります。

ユーザーエージェントは、ユーザーが権限の状態（強力な機能とオリジンの関連）を確認・更新・リセットできる手段を提供するべきです。

E. セキュリティの考慮事項

現時点で文書化されたセキュリティの考慮事項はありません。読者はD. プライバシーの考慮事項セクションも参照してください。

F. IDL索引

WebIDL[Exposed=(Window)]
partial interface Navigator {
  [SameObject] readonly attribute Permissions permissions;
};

[Exposed=(Worker)]
partial interface WorkerNavigator {
  [SameObject] readonly attribute Permissions permissions;
};

[Exposed=(Window,Worker)]
interface Permissions {
  Promise<PermissionStatus> query(object permissionDesc);
};

dictionary PermissionDescriptor {
  required DOMString name;
};

[Exposed=(Window,Worker)]
interface PermissionStatus : EventTarget {
  readonly attribute PermissionState state;
  readonly attribute DOMString name;
  attribute EventHandler onchange;
};

enum PermissionState {
  "granted",
  "denied",
  "prompt",
};

dictionary PermissionSetParameters {
  required object descriptor;
  required PermissionState state;
};

G. 謝辞

このセクションは非規範的です。

編集者は、API設計や編集作業において協力してくれた Adrienne Porter Felt、Anne van Kesteren、Domenic Denicola、Jake Archibald、Wendy Seltzer に感謝します。

H. 参考文献

H.1 規範となる参考文献

[dom]
DOM現行標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://dom.spec.whatwg.org/
[ecma-262]
ECMAScript言語仕様. Ecma International. URL: https://tc39.es/ecma262/multipage/
[HTML]
HTML現行標準. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 現行標準. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra現行標準. Anne van Kesteren; Domenic Denicola. WHATWG. 現行標準. URL: https://infra.spec.whatwg.org/
[Notifications]
Notifications API現行標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://notifications.spec.whatwg.org/
[Permissions-Policy]
Permissions Policy. Ian Clelland. W3C. 2025年8月6日. W3C作業草案. URL: https://www.w3.org/TR/permissions-policy-1/
[permissions-registry]
Permissions Registry. W3C. 草案レジストリ. URL: https://w3c.github.io/permissions-registry/
[RFC2119]
RFCで要求レベルを示すキーワード. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
RFC2119キーワードにおける大文字・小文字の曖昧性. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2018年6月5日. W3C勧告. URL: https://www.w3.org/TR/webdriver1/
[WebDriver-BiDi]
WebDriver BiDi。James Graham、Alex Rudenko、Maksim Sadym。W3C。2025年10月1日。W3C作業草案。URL: https://www.w3.org/TR/webdriver-bidi/
[webdriver2]
WebDriver. Simon Stewart; David Burns. W3C. 2025年9月8日. W3C作業草案. URL: https://www.w3.org/TR/webdriver2/
[WEBIDL]
Web IDL現行標準. Edgar Chen; Timothy Gu. WHATWG. 現行標準. URL: https://webidl.spec.whatwg.org/

H.2 参考情報

[appmanifest]
Webアプリケーションマニフェスト. Marcos Caceres; Kenneth Christiansen; Diego Gonzalez-Zuniga; Daniel Murphy; Christian Liebel. W3C. 2025年9月3日. W3C作業草案. URL: https://www.w3.org/TR/appmanifest/
[Geolocation]
Geolocation. Marcos Caceres; Reilly Grant. W3C. 2025年9月23日. W3C勧告. URL: https://www.w3.org/TR/geolocation/
[GETUSERMEDIA]
Media Capture and Streams. Cullen Jennings; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet. W3C. 2025年9月25日. CRD. URL: https://www.w3.org/TR/mediacapture-streams/
[local-font-access]
Local Font Access API. W3C. 草案コミュニティグループレポート. URL: https://wicg.github.io/local-font-access/
[orientation-event]
Device Orientation and Motion. Reilly Grant; Marcos Caceres. W3C. 2025年2月12日. CRD. URL: https://www.w3.org/TR/orientation-event/
[Permissions]
Permissions. Marcos Caceres; Mike Taylor. W3C. 2025年9月26日. W3C作業草案. URL: https://www.w3.org/TR/permissions/
[push-api]
Push API。Marcos Caceres、Kagami Rosylight。W3C。2025年9月25日。W3C作業草案。URL: https://www.w3.org/TR/push-api/
[w3c-process]
W3Cプロセス文書。Elika J. Etemad (fantasai)、Florian Rivoal。W3C。2025年8月18日。URL: https://www.w3.org/policies/process/
[Web-Share]
Web Share API. Marcos Caceres; Eric Willigers; Matt Giuca. W3C. 2023年5月30日. W3C勧告. URL: https://www.w3.org/TR/web-share/
[window-management]
Window Management. Joshua Bell; Mike Wasserman. W3C. 2024年6月7日. W3C作業草案. URL: https://www.w3.org/TR/window-management/