権限

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

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であり、そのキーについて等しいとされるものがkeyであり、descriptorが与えられている場合、そのエントリをnewEntryで置換し、 これらの手順を中止する。
  3. 追加： newEntryをユーザーエージェントの許可ストアに加える。

許可ストアエントリを削除するには、 PermissionDescriptor descriptorと許可 キー keyを与えて、次の手順を実行する：

  1. 削除：エントリの記述子が descriptorであり、そのキーについて等しいとされるものが keyであり、descriptorが与えられている場合、そのエントリをユーザー エージェントの許可ストアから削除する。

許可キーの型は、機能の 許可キー型によって定義される。

注記

許可キー key1と等しい許可キー key2であるかどうかを、 PermissionDescriptor descriptorが与えられた場合に判定するには、次の手順を実行する：

  1. key1がdescriptorの許可キー型でないか、 key2がdescriptorの許可キー型でない場合、false を返す。
  2. 許可キー比較 アルゴリズムを、descriptorのnameが示す機能について実行し、 key1とkey2を渡した結果を返す。

3.3 強力な機能

強力な 機能とは、ウェブプラットフォームの 機能（通常は API）であり、ユーザーが明示的な 許可を与えた後でなければ、その機能を 使用できない。いくつかの注目すべき例外（例えば、通知 API 標準）を除き、ほとんどの 強力な機能はポリシー制御 機能でもある。 ポリシー制御 機能でもある強力な機能については、[許可ポリシー]が、 文書に対して、所定の機能の使用が 許可されているかどうかを制御する。すなわち、強力な機能が ユーザーに明示的な許可を要求できるのは、文書に、 対応するポリシー制御 機能を介して許可が委任されている場合のみである（以下の例を参照）。その後の 機能へのアクセスは、ユーザーが"granted"の 許可を得ているか、または何らかの基準を満たしており、それが許可の 付与と同等であるかによって決定される。

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

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

3.3.1 側面

各強力な機能は、0 個以上の追加の アスペクトを定義できる。アスペクトは WebIDL の辞書として定義され、その 継承元は PermissionDescriptorであり、 WebIDL インターフェイスの許可記述子 型として機能する。

3.4 権限タスクソース

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

4. 強力な機能の仕様化

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

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

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

許可記述子型：

PermissionDescriptorまたはそのサブタイプの いずれか。指定されていない場合、既定値は PermissionDescriptorである。

この機能は、記述子インスタンス上に半 順序を定義できる。 descriptorAがより強い関係にある 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とオリジン embedded originを受け取り、新しい 許可キーを返す。指定されていない場合、既定値は既定の 許可キー生成アルゴリズムである。カスタムの許可キー 生成アルゴリズムを指定する機能は、必ず、許可キー 比較アルゴリズムも指定しなければならない。

既定の許可キー生成 アルゴリズムは、 オリジン originとオリジン embedded originを与えられると、次の手順を実行する：

  1. originを返す。
注記：許可の委任
許可キー比較 アルゴリズム：

2 つの許可キーを受け取り、2 つのキーが 等しいかどうかを示す真偽値を返す。指定されていない場合、既定値は既定の許可キー比較 アルゴリズムである。

既定の許可キー比較 アルゴリズムは、 許可キー key1とkey2を与えられると、 次の手順を実行する：

  1. key1が同一オリジン であるかどうかをkey2と比較して返す。
許可取り消し アルゴリズム：

引数を取らない。許可 状態または追加の許可データの結果の変化と 同期を保つ必要がある、実装の他の部分を更新する。

指定されていない場合、既定ではユーザーによる 許可の取り消しに対応する処理を実行する。

許可の有効期間：

1 つ以上の強力な 機能を定義する仕様が提案すべき 許可の有効期間は、その特定の機能に最も 適したものである。 許可の有効期間を決定するための指針を、ユーザーのプライバシーを強く 重視して以下に示す。有効期間が指定されていない場合、ユーザーエージェントが これを提供する。

オリジンに対する許可の有効期間が満了した場合：

  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」である場合、 ユーザー エージェントは、allowMultiple が true なら複数、それ以外なら 1 つの options をユーザーに選択させ、 それを返して、これらの手順を中止してもよい。ユーザーエージェントがプロンプトを表示せずに返した場合、 以後のユーザーに選択を求めるプロンプトでは、 同じ選択肢の集合と同じ descriptor に対して、同じ選択肢を返さなければならない。 ただし、ユーザーエージェントがユーザーの意図に関する新たな 情報を受け取った場合を除く。
  3. ユーザーに、1 つ以上の options を選択するか許可を拒否するよう求め、その選択を 待つ：
    1. 呼び出し元のアルゴリズムがプロンプトに含める追加情報を指定した場合は、 それを含める。
    2. allowMultiple が false の場合は、選択を options 内の 1 つの 項目に制限する。それ以外の場合、ユーザーはいくつでも選択できる。
  4. ユーザーが 1 つ以上の選択肢を選択した場合は、それらを返す。それ以外の場合は、 「denied」を返す。
    注記

    これは、許可 UI の詳細およびユーザーエージェントがユーザーの意図を 推測する方法について、意図的に曖昧にしている。ユーザーエージェントは、 この枠組みの中で多様な UI を試せるべきである（例えば、許可プロンプトはタイムアウトし、 ユーザーが明示的に選択しなくても自動的に「denied」を返すことができる）。

簡略表記として、ユーザーに選択を求める 対象が、 DOMString nameに関連付けられた選択肢である場合、 これは、ユーザーに選択を求める 対象がそれらの選択肢である場合と 同じである。それらの選択肢は、PermissionDescriptorに関連付けられ、そのnameメンバーは、 nameに設定されている。

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

ユーザーエージェントが、ユーザーがもはや、 PermissionDescriptor descriptorによって記述される機能を、 許可キー keyによって記述されるコンテキストで使用するための許可を与える意思がないと認識した場合、ユーザーによる許可の取り消しに対応するため、 次の手順を実行する：

  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仕様との関係

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

本仕様と許可ポリシー仕様はいずれも "許可"を 扱うが、それぞれの仕様はプラットフォームにおいて異なる目的を果たす。それでも、 2 つの仕様は明示的に重複している。

一方で、本仕様は、ユーザーエージェントが仲介する許可 UI を通じてアクセスが管理される強力な 機能のみを 対象とする（すなわち、その機能を使用する前にユーザーが明示的な同意を与え、 ユーザーがいつでも、いかなる理由でも、その許可を拒否する能力を保持する許可）。 これらの強力な 機能は、許可レジストリに登録される。

他方、許可ポリシー仕様では、開発者が "許可 ポリシー"（HTTP ヘッダーであれ、 allow 属性であれ）を通じて、ポリシー制御機能を選択的に有効または無効にできる。その意味で、 許可ポリシーは、許可ポリシーが 本仕様とは独立して、機能がそもそも利用可能かどうかを管理するという点で、本仕様を包含する。これらの ポリシー制御機能も、許可レジストリに登録される。

許可ポリシー仕様によって無効化された強力な機能は、 本仕様では、その許可状態が常に "denied" として反映される。 これは、 現在の許可状態の読み取りが、 [HTML]の"使用を 許可されている"チェックに依存し、このチェック自体が 許可ポリシー仕様を呼び出すためである。 ここで重要なのは、両仕様間で許可 名が共有されていることである。本仕様と許可ポリシー 仕様はいずれも、許可の名前および 名前を他の仕様が定義することに依存しており、 通常、それらには同じ名前が付けられる（例えば、"geolocation"は ジオロケーションの名称である、など）。

最後に、強力な機能が "granted" になることは、いかなる 許可ポリシー仕様が提供する手段によっても不可能である。 強力な機能が"granted"になる唯一の方法は、ユーザーが 明示的な許可を与えるか、何らかのユーザーエージェントポリシーによることである。

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である。この処理が 例外を投げた場合、無効な引数エラーを返す。
  2. parametersDict.stateが、 何らかの実装定義の理由により不適切な 許可状態である場合、無効な引数エラーを返す。
    注記

    例えば、"midi"というユーザーエージェントを定義する 強力な機能が "always on"である場合、この手順で許可状態を 「denied」に設定するコマンドを拒否することを選択できる。

  3. rootDescをparametersDict.descriptorとする。
  4. typedDescriptorを、rootDescが参照するオブジェクトをIDL 値に変換したものとする。その許可記述子 型は、 Get(rootDesc, "name")の結果と一致する。この処理が 例外を投げた場合、無効な引数エラーを返す。
  5. 許可を設定する処理を、typedDescriptorと parametersDict.stateを用いて実行する。
  6. 成功を、 データnullとともに返す。

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仕様の場合も、その文字列は強力な機能を識別します。

注記：許可と許可ポリシー
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/