Item	Content
Workgroup	OpenID AuthZEN
Published	2025年11月8日
Authors	O. Gazitt（編集者） / Aserto
Authors	D. Brossard（編集者） / Axiomatics
Authors	A. Tulshibagwale（編集者） / SGNL

Authorization API 1.0 – draft 05

Abstract

Authorization API は、ポリシー決定点（PDP）とポリシー強制点（PEP）が、互いの内部動作を知る必要なく、認可要求と認可判断を相互にやり取りできるようにする。Authorization API は PDP によって提供され、PEP によって呼び出される。Authorization API には、特定のアクセス判断を提供する評価エンドポイントと、許可されるサブジェクト、リソース、またはアクションを発見するための検索エンドポイントが含まれる。

▲

5.1. Subject
- 5.1.1. Subject Properties
- 5.1.2. Examples (non-normative)
5.2. Resource
- 5.2.1. Resource Properties
- 5.2.2. Examples (non-normative)
5.3. Action
- 5.3.1. Action Properties
- 5.3.2. Examples (non-normative)
5.4. Context
- 5.4.1. Examples (non-normative)
5.5. Decision
- 5.5.1. Decision Context
- 5.5.2. Examples (non-normative)

- 6. Access Evaluation API

6.1. The Access Evaluation API Request
- 6.1.1. Example (non-normative)
6.2. The Access Evaluation API Response

- 7. Access Evaluations API

7.1. The Access Evaluations API Request
- 7.1.1. Default values
- 7.1.2. Evaluations options
7.2. The Access Evaluations API Response
- 7.2.1. Errors

- 8. Search APIs

8.1. Semantics
8.2. Pagination
- 8.2.1. Paginated Requests
- 8.2.2. Paginated Responses
- 8.2.3. Examples (non-normative)
8.3. The Search API Response
8.4. Subject Search API
- 8.4.1. The Subject Search API Request
- 8.4.2. Example (non-normative)
8.5. Resource Search API
- 8.5.1. The Resource Search API Request
- 8.5.2. Example (non-normative)
8.6. Action Search API
- 8.6.1. The Action Search API Request
- 8.6.2. Example (non-normative)

- 9. Policy Decision Point Metadata

9.1. Data structure
- 9.1.1. Endpoint Parameters
- 9.1.2. Capabilities Parameters
- 9.1.3. Signature Parameter
9.2. Obtaining Policy Decision Point Metadata
- 9.2.1. Policy Decision Point Metadata Request
- 9.2.2. Policy Decision Point Metadata Response
- 9.2.3. Policy Decision Point Metadata Validation

- 10. Transport

10.1. HTTPS JSON Binding
- 10.1.1. JSON Serialization
- 10.1.2. Error Responses
- 10.1.3. Request Identification
- 10.1.4. Examples (non-normative)

- 11. Security Considerations

11.1. Communication Integrity and Confidentiality
11.2. Policy Confidentiality and Sender Authentication
11.3. Sender Authentication Failure
11.4. Trust
11.5. JSON Payload Considerations
11.6. Authorization Response Integrity
11.7. Availability & Denial of Service
11.8. Differences between Unsigned and Signed Metadata
11.9. Metadata Caching

- 12. IANA Considerations

12.1. AuthZEN Policy Decision Point Metadata Registry
- 12.1.1. Registry Definition
- 12.1.2. Registration Template
- 12.1.3. Initial Registrations
12.2. Well-Known URI Registry
- 12.2.1. Registry Contents
12.3. AuthZEN Policy Decision Point Capabilities Registry
- 12.3.1. Registry Definition
- 12.3.2. Registration Template
12.4. Registration of "authzen" URN Sub-namespace

- 13. References

13.1. Normative References
13.2. Informative References
Appendix A. Terminology
Appendix B. Acknowledgements
Appendix C. Document History
Appendix D. Notices
Contributors
Authors' Addresses

1. Introduction

計算サービスは、ポリシー決定点（PDP）とポリシー強制点（PEP）を分離することで、コンポーネント内にアクセス制御を実装することがよくある。PDP と PEP は XACML（[XACML]）および NIST の ABAC SP 800-162（[NIST.SP.800-162]）で定義されている。PDP と PEP の間の通信は、認可情報を必要とする、または提供するさまざまなソフトウェアやサービスにおいて、同様のパターンに従う。本書で説明する Authorization API は、異なる提供者が、特定の PDP または PEP の実装に自らを縛ることなく、PDP および PEP の機能を提供できるようにする。

2. Model

慣例として、この API を実装するサービスをポリシー決定点（Policy Decision Point）、すなわち PDP と呼ぶ。PDP のポリシー言語、アーキテクチャ、および状態管理に関する側面は、本仕様のスコープ外である。

慣例として、Authorization API のクライアントをポリシー強制点（Policy Enforcement Point）、すなわち PEP と呼ぶ。クライアントは、認可判断の強制を超えるユースケースのために Authorization API を利用する場合がある。たとえば、Resource Search API（Section 8.5）は、サブジェクトがあるアクションを実行できるリソースを呼び出し側が発見できるようにする。一貫性のために、ユースケースにかかわらず、API のクライアントを説明するために PEP という用語を用いる。

Authorization API は、トランスポートに依存しない形で定義される。規範的な HTTPS バインディングは Transport（Section 10）で記述されている。gRPC のような他のバインディングは、本仕様の他のプロファイルで定義される場合がある。

Authorization API 自体の認証は、API の認証が他所で十分に文書化されているため、本書のスコープ外である。OAuth 2.0（[RFC6749]）のサポートが推奨される。

3. Features

Authorization API の中核機能は Access Evaluation API（Section 6）であり、PEP が、特定の要求が特定のリソースへのアクセスを許可できるかどうかを判断できるようにする。以下は非規範的な例である。

Alice は文書 #123 を閲覧できるか？
Alice は 2024年6月11日（火）16:30 に文書 #123 を閲覧できるか？
マネージャーは印刷できるか？

Access Evaluations API（Section 7）は、単一の要求で複数の評価を実行できるようにする。以下は非規範的な例である。

Alice は 2024年6月11日（火）に文書 123、234、345 を閲覧できるか？
文書 123 は Alice と Bob によって閲覧可能か？

Search APIs（Section 8）は、アクセスが許可されるリソース、サブジェクト、またはアクションのリストを提供する。以下は非規範的な例である。

Alice はどの文書を閲覧できるか？
誰が文書 123 を閲覧できるか？
Alice は 2024年6月11日（火）に文書 123 に対してどのアクションを実行できるか？

4. API Version

本書は API バージョン 1.0 を記述する。本書または他の文書の後続改訂によってこの API に対して行われる更新は、この API を拡張する場合があるが、ここで記述された API を変更してはならない。拡張には、追加の API メソッド、既存の API メソッドへの追加パラメータ、追加の認可メカニズム、または HTTPS トランスポート・バインディングにおける追加の任意ヘッダーが含まれ得る。バージョン 1.0 のエンドポイントには、エンドポイント識別子に v1 を含めるべきである（例：https://pdp.example.com/access/v1/）。

5. Information Model

要求および応答の情報モデルには、次のエンティティが含まれる：Subject、Action、Resource、Context、Decision。これらはすべて以下で定義される。

5.1. Subject

Subject は、Authorization API が呼び出される対象となるユーザーまたはマシンのプリンシパルである。Authorization API が呼び出される時点で、Subject はアクセスを要求している場合がある。

Subject はオブジェクトであり、文字列値を持つ 2 つの必須キー type と id、およびオブジェクト値を持つ任意キー properties を含む。

type:

必須。Subject の種類を指定する文字列値。

id:

必須。type にスコープされた、Subject の一意識別子を含む文字列値。

properties:

任意。Subject の追加属性を表現するために使用できるオブジェクト。

5.1.1. Subject Properties

多くの認可システムはステートレスであり、PEP が、認可ポリシーの評価に使用される関連属性をすべて渡してくることを想定する。この要件を満たすために、Subject は properties オブジェクトの下に、キーと値のペアとして追加属性を含めてもよい。プロパティには、文字列、数値、ブール値、null のような単純な値だけでなく、配列やオブジェクトのような複雑な値も含めることができる。

Subject 属性の例には、次が含まれるが、これらに限定されない。

部署、
グループメンバーシップ、
デバイス識別子、
IP アドレス。

5.1.2. Examples (non-normative)

以下は、最小限の Subject の非規範的な例である。

{
  "type": "user",
  "id": "alice@example.com"
}

Figure 1: Example Subject

以下は、文字列値の department プロパティを追加した Subject の非規範的な例である。

{
  "type": "user",
  "id": "alice@example.com",
  "properties": {
    "department": "Sales"
  }
}

Figure 2: Example Subject with Additional Property

以下は、IP アドレスおよびデバイス識別子のプロパティを追加した subject の非規範的な例である。

{
  "type": "user",
  "id": "alice@example.com",
  "properties": {
    "ip_address": "172.217.22.14",
    "device_id": "8:65:ee:17:7e:0b"
  }
}

Figure 3: Example Subject with IP Address and Device ID

5.2. Resource

Resource はアクセス要求の対象である。Subject エンティティと同様に構築されるオブジェクトである。次のキーを持つ。

type:

必須。Resource の種類を指定する文字列値。

id:

必須。type にスコープされた、Resource の一意識別子を含む文字列値。

properties:

任意。Resource の追加属性を表現するために使用できるオブジェクト。

5.2.1. Resource Properties

Subject の properties と同様に、PEP は properties フィールドで Resource の属性も提供できる。

そのような属性には、アクセス評価で使用されるリソースの属性、またはリソースに関するメタデータなどが含まれ得るが、これらに限定されない。

5.2.2. Examples (non-normative)

以下は、type と単純な id を持つ Resource の非規範的な例である。

{
  "type": "book",
  "id": "123"
}

Figure 4: Example Resource

以下は、オブジェクトそれ自体である library_record プロパティを含む Resource の非規範的な例である。

{
  "type": "book",
  "id": "123",
  "properties": {
    "library_record": {
      "title": "AuthZEN in Action",
      "isbn": "978-0593383322"
    }
  }
}

Figure 5: Example Resource with Additional Property

5.3. Action

Action は、要求者が実行しようとしているアクセスの種類である。

Action は、文字列値を持つ必須の name キーと、オブジェクト値を持つ任意の properties キーを含むオブジェクトである。

name:

必須。Action の名前を含む文字列値。

properties:

任意。Action の追加属性を表現するために使用できるオブジェクト。

5.3.1. Action Properties

Subject および Resource の properties と同様に、PEP は properties フィールドで Action の属性も提供できる。

そのような属性には、要求されているアクションのパラメータなどが含まれ得るが、これらに限定されない。

5.3.2. Examples (non-normative)

以下は、action の非規範的な例である。

{
  "name": "can_read"
}

Figure 6: Example Action

以下は、追加の properties を持つ action の非規範的な例である。

{
  "name": "extend-loan",
  "properties": {
    "period": "2W"
  }
}

Figure 7: Example Action with properties for extending a book loan.

5.4. Context

Context は、アクセス評価要求の環境を表す。

Context は、環境の属性を表現するために使用できるオブジェクトである。

コンテキスト属性の例には、次が含まれるが、これらに限定されない。

時刻、
要求を受信した場所、
PEP の能力、
要求のための JSON Schema または JSON-LD 定義。

5.5. Decision

Decision は、アクセス要求の評価結果である。PEP がその決定を強制するために必要な情報を提供する。

Decision は、boolean 値を持つ必須の decision キーと、オブジェクト値を持つ任意の context キーを含むオブジェクトである。

decision:

必須。Decision が操作を許可するか拒否するかを指定するブール値。

context:

任意。決定の強制プロセスの一部として PEP が使用できる追加情報を伝達できるオブジェクト。

本仕様では、評価が成功したと仮定すると、decision に取り得る値は 2 つのみである。

true: アクセス要求は先へ進むことが許可される。PEP が context 応答オブジェクト内の情報を理解できない場合、PEP はその決定を拒否することを選択してもよい。
false: アクセス要求は拒否され、先へ進むことを許可してはならない。

以下は、最小限の Decision の非規範的な例である。

{
  "decision": true
}

Figure 10: Example Decision

5.5.1. Decision Context

decision に加えて、応答はオブジェクトを含む context フィールドを含んでもよい。このコンテキストは、決定の強制プロセスの一部として PEP が使用できる追加情報を伝達できる。

例には次が含まれるが、これらに限定されない。

決定が行われた理由（複数可）、
アクセス決定に紐づく「Advices」および／または「Obligations」、
UI 状態をレンダリングするためのヒント、
ステップアップ認証のための指示、
環境情報、
など。

5.5.2. Examples (non-normative)

以下はすべて、可能で有効なコンテキストの非規範的な例であり、想定される利用方法を示すために提供される。context オブジェクトの実際のセマンティクスおよび形式は実装上の関心事であり、本仕様のスコープ外である。たとえば実装は、HTTP ステータスコードのような他の標準の概念に対応するキーを用いて、一般的な理由を相互運用可能な形で伝達してもよい。

5.5.2.1. Non-normative Example 1: conveying decision Reasons

PDP は、決定を説明する理由を提供してもよい。以下の非規範的な例では、実装が HTTP ステータスコードに対応し得るキーを用いて、管理者とエンドユーザーに異なる理由を伝達する場合がある。

{
  "decision": false,
  "context": {
    "reason_admin": {
      "403": "Request failed policy C076E82F"
    },
    "reason_user": {
      "403": "Insufficient privileges. Contact your administrator"
    }
  }
}

Figure 11: Non-normative Example Response with reason Context

5.5.2.2. Non-normative Example 2: conveying metadata and environmental elements

次の非規範的な例では、PDP は、ポリシーを満たさなかった環境条件を含めることで決定を正当化している。決定の応答時間に関するメタデータも提供される。

{
  "decision": false,
  "context": {
    "metadata": {
      "response_time": 60,
      "response_time_unit": "ms"
    },
    "environment": {
      "ip": "10.10.0.1",
      "datetime": "2025-06-27T18:03-07:00",
      "os": "ubuntu24.04.2LTS-AMDx64"
    }
  }
}

Figure 12: Non-normative Example Response with Environment and Metadata Context

5.5.2.3. Non-normative Example 3: requesting step-up authentication

次の非規範的な例では、PDP は、要求を承認するために見えていることを期待する必須の acr および amr アクセストークン・クレーム値を通知することで、要求している subject に対するステップアップ認証を要求している。

{
  "decision": false,
  "context": {
    "acr_values": "urn:com:example:loa:3",
    "amr_values": "mfa hwk"
  }
}

Figure 13: Non-normative Example Response with a step-up request Context

6. Access Evaluation API

Access Evaluation API は、単一のアクセス評価を実行するための、PEP と PDP の間のメッセージ交換パターンを定義する。

6.1. The Access Evaluation API Request

Access Evaluation の要求は、情報モデル（Section 5）で先に定義した 4 つのエンティティから成るオブジェクトである。

subject:

必須。Subject 型の subject（または principal）

action:

必須。Action 型の action（または verb）。

resource:

必須。Resource 型の resource。

context:

任意。Context 型の context（または environment）。

6.1.1. Example (non-normative)

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "account",
    "id": "123"
  },
  "action": {
    "name": "can_read",
    "properties": {
      "method": "GET"
    }
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

Figure 14: Example Request

6.2. The Access Evaluation API Response

Access Evaluation API の応答は、情報モデル（Section 5）で定義された Decision エンティティから成る。

7. Access Evaluations API

Access Evaluations API は、単一のメッセージ交換のスコープ内で複数のアクセス評価を評価するための、PEP と PDP の間のメッセージ交換パターン（「boxcarring」要求としても知られる）を定義する。

7.1. The Access Evaluations API Request

Access Evaluations API Request は、Section 5 で提示された情報モデルと、Access Evaluation Request（Section 6.1）で定義されたオブジェクトを基礎としている。

単一のメッセージで複数のアクセス評価要求を送信するために、PEP は要求に evaluations キーを追加してもよい。evaluations キーは配列であり、Access Evaluation Request（Section 6.1）で定義されたオブジェクトとして型付けされたオブジェクトのリストを含み、それぞれが個別の要求を指定する。

evaluations 配列が存在しない、または空である場合、Access Evaluations Request は（単一の）Access Evaluation API Request（Section 6.1）と後方互換な形で動作する。

evaluations 配列が存在し、1 つ以上のオブジェクトを含む場合、これらは PDP が評価する個別の要求を構成する。これらの要求は互いに独立しており、逐次的に実行される場合も並列に実行される場合もあり、各実装の裁量に委ねられる。

トップレベルの subject、action、resource、および context キーは、evaluations 配列内の各フィールドに対するデフォルト値を提供する。evaluations 配列が存在し、1 つ以上のオブジェクトを含み、かつ evaluations 配列内のすべてのオブジェクトがそれぞれ対応するトップレベルのキーを含む場合、トップレベルの subject、action、および resource キーは省略してもよい。この挙動は Section 7.1.1 で記述される。

以下は、デフォルト値なしで 3 つの要求を指定する非規範的な例である。

{
  "evaluations": [
    {
      "subject": {
        "type": "user",
        "id": "alice@example.com"
      },
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "boxcarring.md"
      },
      "context": {
        "time": "2024-05-31T15:22-07:00"
      }
    },
    {
      "subject": {
        "type": "user",
        "id": "alice@example.com"
      },
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "subject-search.md"
      },
      "context": {
        "time": "2024-05-31T15:22-07:00"
      }
    },
    {
      "subject": {
        "type": "user",
        "id": "alice@example.com"
      },
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "resource-search.md"
      },
      "context": {
        "time": "2024-05-31T15:22-07:00"
      }
    }
  ]
}

7.1.1. Default values

上の例は、各評価について各要求内で個別の値を指定するうえで最も柔軟性が高いが、boxcarred 要求が評価要求の 1 つ以上の値を共有することは一般的である。たとえば、評価はすべて単一の subject を参照し得るし、同じコンテキスト（環境）属性を持ち得る。

デフォルト値は、要求データの不要な重複を避ける、より簡潔な構文を提供する。

トップレベルの subject、action、resource、および context キーは、evaluations 配列内の各オブジェクトに対するデフォルト値を提供する。個々の evaluation オブジェクト内で指定されたこれらのキーは、対応するトップレベルのデフォルトを上書きする。有効な評価のために subject、action、および resource は必須であるため、evaluation オブジェクトから省略されたこれらのキーは、トップレベルのキーとして提供されなければならない。

以下は、単一の subject と context を参照する 3 つの要求を指定する非規範的な例である。

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "context": {
    "time": "2024-05-31T15:22-07:00"
  },
  "evaluations": [
    {
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "boxcarring.md"
      }
    },
    {
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "subject-search.md"
      }
    },
    {
      "action": {
        "name": "can_read"
      },
      "resource": {
        "type": "document",
        "id": "resource-search.md"
      }
    }
  ]
}

以下は、単一の subject と context を参照し、action のデフォルト値を持つ 3 つの要求を指定する非規範的な例であり、3 つ目の要求によって上書きされる。

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "context": {
    "time": "2024-05-31T15:22-07:00"
  },
  "action": {
    "name": "can_read"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "boxcarring.md"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "subject-search.md"
      }
    },
    {
      "action": {
        "name": "can_edit"
      },
      "resource": {
        "type": "document",
        "id": "resource-search.md"
      }
    }
  ]
}

7.1.2. Evaluations options

evaluations 要求ペイロードには、オブジェクト値を持つ任意の options キーが含まれる。

これは、要求をどのように実行するかに関する、PEP 提供のメタデータを提供するための汎用的なメカニズムを提供する。

そのようなオプションの 1 つは evaluation semantics を制御し、Section 7.1.2.1 で記述される。

options フィールドの非規範的な例を以下に示す。完全性のために evaluations 配列も併記する。

{
  "evaluations": [{
    "resource": {
      "type": "doc",
      "id": "1"
    },
    "subject": {
      "type": "doc",
      "id": "2"
    }
  }],
  "options": {
    "evaluations_semantic": "execute_all",
    "another_option": "value"
  }
}

7.1.2.1. Evaluations semantics

デフォルトでは、evaluations 配列内のすべての要求が実行され、同じ配列順で応答が返される。これは、単一のペイロードで複数の評価要求を boxcarring する最も一般的なユースケースである。

本仕様は 3 つの評価セマンティクスをサポートする。

すべての要求を（必要に応じて並列に）実行し、すべての結果を返す。 いかなる失敗も "decision": false で示すことができ、context に理由コードを含めてもよい。
最初の deny（または失敗）で deny する。 このセマンティクスは、PEP がいくつかの要求を特定の順序で発行したい場合に望ましいことがある。その場合、いずれかの deny（エラー、または "decision": false）が、evaluations 呼び出しを「短絡」させ、最初の deny で返す。これは本質的に、プログラミング言語における && 演算子のように動作する。
最初の permit で permit する。 これは逆の「短絡」セマンティクスであり、プログラミング言語における || 演算子のように動作する。

望ましい評価セマンティクスを選択するために、PEP は options.evaluations_semantic に、次の値のうちちょうど 1 つを渡すことができる。

execute_all
deny_on_first_deny
permit_on_first_permit

execute_all がデフォルトのセマンティクスであるため、options.evaluations_semantic フラグを持たない evaluations 要求は、このセマンティクスで実行される。

7.1.2.1.1. Example: Evaluate `read` action for three documents using all three semantics

すべての要求を実行：

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "read"
  },
  "options": {
    "evaluations_semantic": "execute_all"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "1"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "2"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "3"
      }
    }
  ]
}

Response:

{
  "evaluations": [
    {
      "decision": true
    },
    {
      "decision": false
    },
    {
      "decision": true
    }
  ]
}

最初の deny で deny：

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "read"
  },
  "options": {
    "evaluations_semantic": "deny_on_first_deny"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "1"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "2"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "3"
      }
    }
  ]
}

Response:

{
  "evaluations": [
    {
      "decision": true
    },
    {
      "decision": false,
      "context": {
        "code": "200",
        "reason": "deny_on_first_deny"
      }
    }
  ]
}

最初の permit で permit：

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "read"
  },
  "options": {
    "evaluations_semantic": "permit_on_first_permit"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "1"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "2"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "3"
      }
    }
  ]
}

Response:

{
  "evaluations": [
    {
      "decision": true
    }
  ]
}

7.2. The Access Evaluations API Response

要求フォーマットと同様に、Access Evaluations Request に対する Access Evaluations Response フォーマットは、要求内の evaluations 配列で提供されたのと同じ順序で決定を列挙する evaluations 配列を追加する。evaluations 配列の各値は、情報モデル（Section 5）で定義された Decision として型付けされる。

evaluations 配列が存在する場合、応答の decision キーは省略することが推奨される。存在する場合でも、PEP によって無視され得る。

以下は、3 つの evaluation オブジェクトを含む Access Evaluations Request に対する Access Evaluations Response の非規範的な例である。

{
  "evaluations": [
    {
      "decision": true
    },
    {
      "decision": false,
      "context": {
        "reason": "resource not found"
      }
    },
    {
      "decision": false,
      "context": {
        "reason": "Subject is a viewer of the resource"
      }
    }
  ]
}

7.2.1. Errors

エラーには 2 種類があり、それぞれ異なる方法で扱われる：1. トランスポート層のエラー、またはペイロード全体に関係するエラー。2. 個々の評価におけるエラー。

第 1 の種類のエラーはトランスポート層で処理される。たとえば HTTP バインディングでは、Transport（Section 10）で説明されているとおり、4XX および 5XX コードが、ペイロード全体に関係する一般的なエラーを示す。

第 2 の種類のエラーはペイロード層で処理される。Decision は closed（すなわち false）をデフォルトとするが、context フィールドには、その要求に固有のエラーを含めることができる。

以下は、3 つの evaluation オブジェクトを含む Access Evaluations Request に対する応答の非規範的な例であり、そのうち 2 つは、2 つの evaluation 要求に対してどのようにエラーを返せるかを示している。

{
  "evaluations": [
    {
      "decision": true
    },
    {
      "decision": false,
      "context": {
        "error": {
          "status": 404,
          "message": "Resource not found"
        }
      }
    },
    {
      "decision": false,
      "context": {
        "reason": "Subject is a viewer of the resource"
      }
    }
  ]
}

8. Search APIs

Search APIs は、特定の認可コンテキスト内で許可されるサブジェクト、リソース、またはアクションの集合を PEP が発見できるようにする。目的は、単一のアクセス要求を検証することではなく、認可されたエンティティのリストを返すことである。

検索を実行するために、PEP は情報モデル（Section 5）で定義された Subject、Resource、Action、Context エンティティを提供するが、問い合わせ対象となるエンティティの一意識別子は省略する。PDP はその後、提供された基準に従って認可されるであろう、問い合わせ対象エンティティ型に対する認可済みエンティティ集合で応答する。

8.1. Semantics

検索は、許可される決定に対応するエンティティを返すように設計されている。したがって、Search API のいかなる結果も、その後に Access Evaluation API 呼び出しで使用された場合、"decision": true の応答になるべきである。ただし、評価は実装依存であり、（時刻などの）他の変数に依存し得るため、この結果は保証されない。

加えて、検索は推移的（transitively）に実行され、中間属性および／または関係を辿ることが推奨される。たとえば、ユーザー U がグループ G のメンバーであり、グループ G が文書 D の viewer として指定されている場合、文書 D を閲覧できる user 型のすべての subject を検索すると、ユーザー U が含まれる。

8.2. Pagination

Search APIs は大きな結果セットを返し得る。これを管理するために、PDP はページネーションをサポートしてもよく、PEP が移動して総結果セットの部分集合を取得できるようにする。

ページネーションは、結果セットのアトミックなスナップショットを保証しない。したがって、ページネーション中に項目が追加または削除されると、結果はページ間で重複したり欠落したりしてもよい。

ページネーションは不透明なトークンの使用に基づく。PEP は、トークンを含まないクエリを送ることでデータの初回要求を行う。PDP が結果セットに単一の応答に収まらないほど多くの結果が含まれると判断した場合、PDP は部分的な結果セットと、PEP が次の結果ページを取得するために使用できるトークンを返す。

ページングされた応答は、空でない不透明な next_token を含む page オブジェクトを含めることで、明確に識別されなければならない。このトークンは、さらなる結果が利用可能であることを PEP に示すシグナルである。

次のページを取得するために、PEP は後続の要求で page オブジェクトを含め、その token フィールドを直前の応答の next_token 値に設定して送信する。この処理は、PDP が next_token フィールドの値が空文字列である page オブジェクトを返し、結果セットの終端を示すまで繰り返される。

要求がトークンを含む場合、すべてのエンティティ（例：subject、resource、action、context）およびページネーション・パラメータ（例：limit）は、直前の要求と同一でなければならない。いずれかのエンティティまたはパラメータが変更された場合、PDP はエラーを返すべきである。

結果セット全体を逐次的に反復したい PEP は、上で説明した中核のページネーション機構を使用するべきである。これは、検索 API をサポートするすべての PDP で一貫して動作するように設計されている。

8.2.1. Paginated Requests

Search API Request は、より大きな結果セットのどの部分集合を PEP が受け取りたいかを示す page オブジェクトを含んでもよい。

Search API Request の page オブジェクトは、次のキーから成る。

token:

任意。以前の応答の next_token から得られる不透明な文字列値。

limit:

任意。応答で返す結果の最大件数を示す、非負の整数。

properties:

任意。ソートやフィルタリングなど（ただしこれらに限定されない）、実装固有の追加のページネーション要求属性を含むオブジェクト。

token を除き、初回要求のすべての値は後続ページでも同一でなければならない。ページネーションの途中で異なる値が提供された場合、PDP はエラーを返すべきである。

追加のキーを page オブジェクトに含めてもよい。含める場合、それらは AuthZEN Policy Decision Point Capabilities Registry（Section 12.3）で参照される仕様で定義されなければならない。さらに、PDP は supported_capabilities メタデータ（Section 9.1.2）で対応する capability URN のサポートを宣言しなければならない。

8.2.2. Paginated Responses

いかなる Search API Response も page オブジェクトを含めてもよいが、応答が結果セット全体を含まない場合、このオブジェクトを含めなければならない。

page オブジェクトは次のキーを含む。

next_token:

必須。返すべき次ページの結果を示す不透明な文字列値。このページの後にこれ以上結果がない場合、その値は空文字列でなければならない。

count:

任意。この応答に含まれる結果数を示す非負の整数。Search API Response（Section 8.3）で説明されるとおり、応答の先頭に含められる場合、大きい／遅い応答を処理する際に PEP が進捗インジケータを表示できるようにする。

total:

任意。要求時点において、クエリ条件に一致する結果の総数を示す非負の整数。ページネーション中に基盤データセットが変化する場合、この値はすべてのページにわたって返される項目総数と等しいことは保証されない。

properties:

任意。追加のページネーション応答属性を含むオブジェクト。例として、推定総数や残り結果数などが含まれ得るが、これらに限定されない。

8.2.3. Examples (non-normative)

以下は、ページサイズ上限を 2 として合計 3 件の結果を取得するための、要求—応答サイクルの非規範的な例である。

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  },
  "page": {
    "limit": 2
  }
}

Figure 15: Example initial Search API Request

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI=",
    "count": 2,
    "total": 3
  },
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

Figure 16: Example initial Search API Response

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  },
  "page": {
    "token": "a3M9NDU2O3N6PTI="
  }
}

Figure 17: Example second Search API Request

{
  "page": {
    "next_token": "",
    "count": 1,
    "total": 3
  },
  "results": [
    {
      "type": "account",
      "id": "789"
    }
  ]
}

Figure 18: Example second Search API Response

8.3. The Search API Response

Search API Request に対する応答は、常に同じ構造に従う。各 Search API Response は、次のキーを持つ JSON オブジェクトである。

page:

任意。Paginated Responses（Section 8.2.2）で定義されるページネーション情報を提供するオブジェクト。大きい／遅い応答を処理する際に PEP が count 値を用いて進捗インジケータを表示できるようにするため、page オブジェクトを応答の最初のキーにすることが推奨される。

context:

任意。Access Evaluation Response（Section 6.2 を参照）における機能と同様に、PEP が使用できる追加情報を伝達できるオブジェクト。

results:

必須。情報モデル（Section 5）で定義されたエンティティを 0 個以上含む配列。検索対象の型（例：Subjects、Resources、または Actions）のエンティティのみを含まなければならない。

以下は、リソースを返す検索応答の非規範的な例である。

{
  "page": {
    "count": 2,
    "total": 102
  },
  "context": {
    "query_execution_time_ms": 42
  },
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

Figure 19: Example Resource Search API Response

8.4. Subject Search API

Subject Search API は、提供された Action（Section 5.3）、Resource（Section 5.2）、および Context（Section 5.4）に従って許可される、指定された型のすべての subject を返す。

8.4.1. The Subject Search API Request

Subject Search 要求は、次のエンティティから成るオブジェクトである。

subject:

必須。Subject 型の subject（または principal）。Subject は type を含まなければならないが、Subject の id は省略するべきであり、存在する場合は無視されなければならない。

action:

必須。Action 型の action（または verb）。

resource:

必須。Resource 型の resource。

context:

任意。要求に関するコンテキストデータ。

page:

任意。ページングされた要求のための page オブジェクト。

8.4.2. Example (non-normative)

以下のペイロードは、account 型で ID が 123 のリソースに対して can_read アクションを実行できる user 型の subject を求める要求を定義する。

{
  "subject": {
    "type": "user"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account",
    "id": "123"
  },
  "context": {
    "time": "2024-10-26T01:22-07:00"
  }
}

Figure 20: Example Subject Search API Request

以下のペイロードは、この要求に対する有効な応答を定義する。

{
  "results": [
    {
      "type": "user",
      "id": "alice@example.com"
    },
    {
      "type": "user",
      "id": "bob@example.com"
    }
  ]
}

Figure 21: Example Subject Search API Response

8.5. Resource Search API

Resource Search API は、提供された Action（Section 5.3）、Subject（Section 5.1）、および Context（Section 5.4）に従って許可される、指定された型のすべてのリソースを返す。

8.5.1. The Resource Search API Request

Resource Search 要求は、次のエンティティから成るオブジェクトである。

subject:

必須。Subject 型の subject（または principal）。

action:

必須。Action 型の action（または verb）。

resource:

必須。Resource 型の resource。Resource は type を含まなければならないが、Resource の id は省略するべきであり、存在する場合は無視されなければならない。

context:

任意。要求に関するコンテキストデータ。

page:

任意。ページングされた要求のための page オブジェクト。

8.5.2. Example (non-normative)

以下のペイロードは、user 型で ID が alice@example.com の subject が can_read アクションを実行できる account 型のリソースを求める要求を定義する。

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  }
}

Figure 22: Example Resource Search API Request

以下のペイロードは、この要求に対する有効な応答を定義する。

{
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

Figure 23: Example Resource Search API Response

8.6. Action Search API

Action Search API は、提供された Subject（Section 5.1）、Resource（Section 5.2）、および Context（Section 5.4）に従って許可される、すべての action を返す。

8.6.1. The Action Search API Request

Action Search 要求は、次のエンティティから成るオブジェクトである。

subject:

必須。Subject 型の subject（または principal）。

resource:

必須。Resource 型の resource。

context:

任意。要求に関するコンテキストデータ。

page:

任意。ページングされた要求のための page オブジェクト。

Note: Subject Search API および Resource Search API と異なり、Action Search 要求ペイロードでは action キーが省略される。

8.6.2. Example (non-normative)

以下のペイロードは、ID が 123 の user 型の subject が、午前 01:22 に、account 型で ID が 123 のリソースに対して実行し得る action を求める要求を定義する。

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "account",
    "id": "123"
  },
  "context": {
    "time": "2024-10-26T01:22-07:00"
  }
}

Figure 24: Example Action Search API Request

以下のペイロードは、この要求に対する有効な応答を定義する。

{
  "results": [
    {
      "name": "can_read"
    },
    {
      "name": "can_write"
    }
  ]
}

Figure 25: Example Action Search API Response

9. Policy Decision Point Metadata

PDP は、その構成を記述するメタデータを提供することが推奨される。

9.1. Data structure

以下の Policy Decision Point メタデータ・パラメータは本仕様で使用され、Section 12.1 で確立される IANA の「AuthZEN Policy Decision Point Metadata」レジストリに登録される。

9.1.1. Endpoint Parameters

policy_decision_point:

必須。Policy Decision Point 識別子。これは「https」スキームを使用し、クエリやフラグメント要素を持たない URL である。Policy Decision Point メタデータは、この Policy Decision Point 識別子から導出される [RFC8615] に従う「.well-known」な場所で公開され、Section 9.2 で述べるとおりである。Policy Decision Point 識別子は、Policy Decision Point の取り違え（mix-up）攻撃を防ぐために使用される。

access_evaluation_endpoint:

必須。Access Evaluation API エンドポイントの URL

access_evaluations_endpoint:

任意。Access Evaluations API エンドポイントの URL

search_subject_endpoint:

任意。subject エンティティの Search API エンドポイントの URL

search_action_endpoint:

任意。action エンティティの Search API エンドポイントの URL

search_resource_endpoint:

任意。resource エンティティの Search API エンドポイントの URL

Note: これらのパラメータのいずれかが欠けているだけで、PEP は PDP に能力がないことを判断でき、したがって関連する API について結果を返さない。

9.1.2. Capabilities Parameters

capabilities:

任意。PDP 固有の能力を参照する、登録済み IANA URN のリストを含む JSON 配列。

9.1.3. Signature Parameter

JSON 要素に加えて、メタデータ・パラメータは signed_metadata 値として提供してもよい。これは JSON Web Token [RFC7519] であり、PDP に関するメタデータ値を束（bundle）として主張する。署名付きメタデータでクレームとして使用できるメタデータ・パラメータの集合は Section 9.1.1 で定義される。署名付きメタデータは、JSON Web Signature [RFC7515] を用いてデジタル署名または MAC 化されなければならず、さらに署名付きメタデータ内のクレームに対して証明（attest）する当事者を示す iss（issuer）クレームを含まなければならない。

PEP は、この機能をサポートしない場合、署名付きメタデータを無視してもよい。PEP が署名付きメタデータをサポートする場合、署名付きメタデータで伝達されるメタデータ値は、平文の JSON 要素で伝達される対応する値よりも優先されなければならない。署名付きメタデータは、次の任意メタデータ・パラメータを用いて Policy Decision Point メタデータ JSON オブジェクトに含められる。

signed_metadata:

保護対象リソースに関するメタデータ・パラメータをクレームとして含む JWT。これは署名済み JWT 全体から成る文字列値である。signed_metadata パラメータは JWT 内のクレームとして現れるべきではない。そのようなものが発生しているメタデータは拒否することが推奨される。

9.2. Obtaining Policy Decision Point Metadata

メタデータをサポートする PDP は、AuthZEN Policy Decision Point Metadata Registry（Section 12.1）で指定されたメタデータを含む JSON 文書を、ホスト要素と（存在する場合）パスおよび／またはクエリ要素の間に well-known URI 文字列を挿入して形成される URL で利用可能にしなければならない。使用される well-known URI 文字列は /.well-known/authzen-configuration である。

.well-known の構文およびセマンティクスは [RFC8615] で定義される。使用される well-known URI のパス接尾辞は、IANA の「Well-Known URIs」レジストリ [IANA.well-known-uris] に登録されている。

複数テナントをサポートする PDP の例では、ディスカバリー・エンドポイントは次のようになる。

https://pdp.example.com/.well-known/authzen-configuration/tenant1

9.2.1. Policy Decision Point Metadata Request

Policy Decision Point メタデータ文書は、前述の URL に対する HTTP GET 要求を用いて問い合わせられなければならない。リソース識別子が https://pdp.example.com の場合、メタデータの利用者は次の要求を行う。

GET /.well-known/authzen-configuration HTTP/1.1
Host: pdp.example.com

9.2.2. Policy Decision Point Metadata Response

応答は、保護対象リソースの構成に関するメタデータ・パラメータの集合である。

成功応答は、HTTP ステータスコード 200 と application/json の Content-Type を使用しなければならない。ボディは、AuthZEN Policy Decision Point Metadata Registry（Section 12.1）で定義されたメタデータ・パラメータの集合を含む JSON オブジェクトでなければならない。

応答中のメタデータ・パラメータのうち、PEP が理解しないものは無視されなければならない。

複数の値を持つパラメータは JSON 配列で表現される。値を持たないパラメータは応答から省略されなければならない。

エラー応答は、適用可能な HTTP ステータスコード値を使用する。

以下は非規範的な応答例である。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "policy_decision_point": "https://pdp.example.com",
  "access_evaluation_endpoint": "https://pdp.example.com/access/v1/evaluation",
  "search_subject_endpoint": "https://pdp.example.com/access/v1/search/subject",
  "search_resource_endpoint": "https://pdp.example.com/access/v1/search/resource"
}

9.2.3. Policy Decision Point Metadata Validation

返された policy_decision_point 値は、メタデータ取得に使用された URL を作成するために well-known URI 文字列を挿入した Policy Decision Point 識別子の値と同一でなければならない。これらの値が同一でない場合、応答に含まれるデータは使用してはならない。

受信者は、いかなる署名付きメタデータも、発行者に属する鍵によって署名されており、その署名が有効であることを検証しなければならない。署名が検証できない、または発行者が信頼されていない場合、受信者はこれをエラー条件として扱うべきである。

10. Transport

本仕様は、準拠する PDP が実装しなければならない、JSON シリアライゼーションを用いた HTTPS バインディングを定義する。

追加のトランスポート・バインディング（例：gRPC または CoAP）は、将来プロファイルの形で定義される場合があり、PDP によって実装されてもよい。

10.1. HTTPS JSON Binding

このバインディング内のすべての API 要求は、HTTPS の POST 要求によって行われる。

要求は、値が application/json の Content-Type ヘッダーを含まなければならず、各エンドポイントの要求ボディは、Table 1 で定義される対応する要求構造に適合する JSON オブジェクトでなければならない。

成功応答は、ステータスコード 200 と application/json の Content-Type を持つ HTTPS 応答である。ボディは、Table 1 で定義される対応する応答構造に適合する JSON オブジェクトである。

要求 URL は、Policy Decision Point メタデータ（Section 9.1.1）で提供される場合、Table 1 で定義される対応するエンドポイント・パラメータの値でなければならない。パラメータが提供されない場合、URL は、PDP のベース URL（利用可能であれば Policy Decision Point メタデータの policy_decision_point 値）に、Table 1 で定義されるデフォルトパスを付加して形成するべきである。

以下の表は、このバインディングで定義される API エンドポイントの概要を示す。

API Endpoint	Default Path	Metadata Parameter	Request Schema	Response Schema
Access Evaluation	/access/v1/evaluation	access_evaluation_endpoint	Section 6.1	Section 6.2
Access Evaluations	/access/v1/evaluations	access_evaluations_endpoint	Section 7.1	Section 7.2
Subject Search	/access/v1/search/subject	search_subject_endpoint	Section 8.4.1	Section 8.3
Resource Search	/access/v1/search/resource	search_resource_endpoint	Section 8.5.1	Section 8.3
Action Search	/access/v1/search/action	search_action_endpoint	Section 8.6.1	Section 8.3

10.1.1. JSON Serialization

本節は、本書で定義される情報モデル・エンティティおよび API スキーマを、JSON 形式 [RFC8259] へシリアライズする方法を規定する。すべての要求および応答ボディのトップレベル要素は JSON オブジェクト（[RFC8259] の Section 4）でなければならない。実装は、JSON Payload Considerations（Section 11.5）におけるセキュリティ推奨事項にも従うべきである。

本仕様で定義されるデータ型は、次のとおり JSON 型へマッピングされる。

Object:

JSON オブジェクト（[RFC8259] の Section 4）として表現される。特に指定がない限り、そのメンバーの値は、他のオブジェクトや配列を含め、[RFC8259] の Section 3 で定義される任意の有効な JSON 値になり得る。

Array:

JSON 配列（[RFC8259] の Section 5）として表現される。

String:

JSON 文字列（[RFC8259] の Section 7）として表現される。

Integer:

JSON 数値（[RFC8259] の Section 6）として表現される。IEEE 754 の倍精度を超える値をエンコードしないようにするという Section 11.5 の推奨に注意すること。

Boolean:

JSON リテラル true または false（[RFC8259] の Section 3）として表現される。

情報モデルの必須属性が省略された場合、サーバーは Section 10.1.2 で定義される「Bad Request」エラーを返さなければならない。

前方互換性を確保するために、受信者は要求または応答ボディに存在する未知のフィールドを無視しなければならない。実装は、JSON オブジェクトのメンバー順序を特定の順序だと仮定してはならない。

10.1.2. Error Responses

以下のエラー応答は Authorization API のすべてのメソッドに共通である。エラー応答は、エラーを示す HTTPS ステータスコード（[RFC9110] の Section 15）によって示される。

以下のエラーは、次のステータスコードで示される。

Code	Description	HTTPS Body Content
400	Bad Request	エラーメッセージ文字列
401	Unauthorized	エラーメッセージ文字列
403	Forbidden	エラーメッセージ文字列
500	Internal Error	エラーメッセージ文字列

Note: HTTPS エラーは、要求またはその処理に関するエラー条件を示すために PDP が返すものであり、認可決定の結果とは無関係で、それとは区別される。deny となる成功要求は、200 OK ステータスコードと { "decision": false } ペイロードによって示される。

これを具体化すると：

401 の HTTPS ステータスコードは、PEP が PDP に適切に認証しなかったことを示す。たとえば、必須の Authorization ヘッダーを省略した、または無効なアクセストークンを使用した場合である。
PDP は、200 の HTTPS ステータスコードと { "decision": false } のペイロードを伴う応答を送信することで、認可要求が拒否されたことを PEP に示す。

10.1.3. Request Identification

API へのすべての要求は、それらを一意に識別するための要求識別子を持ってもよい。要求識別子の生成は PEP の責任である。存在する場合、要求識別子として HTTPS ヘッダー X-Request-ID を使用することが推奨される。このヘッダーの値は任意の文字列である。以下の非規範的な例は、このヘッダーを説明する。

POST /access/v1/evaluation HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

Figure 26: Example HTTPS request with a Request Id Header

Authorization API 要求が要求識別子を含む場合、PDP は応答に要求識別子を含めなければならない。要求識別子は、HTTPS 応答ヘッダー X-Request-ID を用いて指定することが推奨される。PEP が要求で要求識別子を指定した場合、PDP はその要求に対する応答に同一の識別子を含めなければならない。

以下は、このヘッダーを含む HTTPS 応答の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

Figure 27: Example HTTPS response with a Request Id Header

10.1.4. Examples (non-normative)

以下は、Access Evaluation Request の HTTPS バインディングの非規範的な例である。

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "todo",
    "id": "1"
  },
  "action": {
    "name": "can_read"
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

Figure 28: Example of an HTTPS Access Evaluation Request

以下は、HTTPS Access Evaluation Response の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "decision": true
}

Figure 29: Example of an HTTP Access Evaluation Response

以下は、Access Evaluations Request の HTTPS バインディングの非規範的な例である。

POST /access/v1/evaluations HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "context": {
    "time": "2024-05-31T15:22-07:00"
  },
  "action": {
    "name": "can_read"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "boxcarring.md"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "subject-search.md"
      }
    },
    {
      "action": {
        "name": "can_edit"
      },
      "resource": {
        "type": "document",
        "id": "resource-search.md"
      }
    }
  ]
}

Figure 30: Example of an HTTPS Access Evaluations Request

以下は、HTTPS Access Evaluations Response の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "evaluations": [
    {
      "decision": true
    },
    {
      "decision": false,
      "context": {
        "error": {
          "status": 404,
          "message": "Resource not found"
        }
      }
    },
    {
      "decision": false,
      "context": {
        "reason": "Subject is a viewer of the resource"
      }
    }
  ]
}

Figure 31: Example of an HTTPS Access Evaluations Response

以下は、Subject Search Request の HTTPS バインディングの非規範的な例である。

POST /access/v1/search/subject HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account",
    "id": "123"
  }
}

Figure 32: Example of an HTTPS Subject Search Request

以下は、HTTPS Subject Search Response の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI="
  },
  "results": [
    {
      "type": "user",
      "id": "alice@example.com"
    },
    {
      "type": "user",
      "id": "bob@example.com"
    }
  ]
}

Figure 33: Example of an HTTPS Subject Search Response

以下は、Resource Search Request の HTTPS バインディングの非規範的な例である。

POST /access/v1/search/resource HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  }
}

Figure 34: Example of an HTTPS Resource Search Request

以下は、HTTPS Resource Search Response の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI="
  },
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

Figure 35: Example of an HTTPS Resource Search Response

以下は、Action Search Request の HTTPS バインディングの非規範的な例である。

POST /access/v1/search/action HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "account",
    "id": "123"
  },
  "context": {
    "time": "2024-10-26T01:22-07:00"
  }
}

Figure 36: Example of an HTTPS Action Search Request

以下は、HTTPS Action Search Response の非規範的な例である。

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI="
  },
  "results": [
    {
      "name": "can_read"
    },
    {
      "name": "can_write"
    }
  ]
}

Figure 37: Example of an HTTPS Action Search Response

11. Security Considerations

11.1. Communication Integrity and Confidentiality

ABAC アーキテクチャでは、PEP-PDP 接続が最も機微なものであり、次を保証するために保護される必要がある。

完全性
機密性

その結果、PEP と PDP の間の接続は、選択したトランスポートに応じた最も適切な手段（例：HTTP REST の場合は TLS）を用いて保護されなければならない。

11.2. Policy Confidentiality and Sender Authentication

加えて、PDP は呼び出し元の PEP を認証するべきである。認証を確立する方法はいくつかある。これらの方法は本仕様のスコープ外である。含まれ得るものは次のとおりである。

相互 TLS
OAuth ベースの認証
API キー

いずれの方式の選択および強度もスコープ外である。

PEP を認証することで、PDP は一般的な攻撃（たとえば DoS — 下記参照）を回避し、かつ／または内部ポリシーの露出を避けられる。悪意あるアクターは、PDP にどのようなポリシーが設定されているかを理解しようとして、多数の要求を作り得る。PEP に認証を要求することは、そのリスクを軽減する。

11.3. Sender Authentication Failure

保護対象リソース要求が適切な認証資格情報を含まない、または保護対象リソースへのアクセスを可能にする有効な認証方式の証明を持たない場合、リソースサーバーは 401 HTTP ステータスコードで応答しなければならず、HTTP の「WWW-Authenticate」応答ヘッダーフィールドを含めるべきである。また、他の条件に対する応答でもそれを含めてもよい。「WWW-Authenticate」ヘッダーフィールドは HTTP/1.1 [RFC2617] で定義されるフレームワークを使用し、期待される認証方式と、それに対して権限を持つ realm を示す。

以下は非規範的な応答例である。

http HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="https://as.example.com"

11.4. Trust

ABAC では、PEP と PDP の間の信頼について議論されることがある：PDP は、PEP が正しい値を送っていることをどのように信頼できるのか？このモデルのアーキテクチャは、PDP が PEP を信頼しなければならないことを前提とする。なぜなら、PEP は最終的に、PDP が生成した決定を強制する責任を負うからである。

11.5. JSON Payload Considerations

JSON ペイロードの解釈を曖昧さなくするため、実装は I-JSON プロファイル（[RFC7493]）に整合する方法で JSON ペイロードを処理および生成するべきである。特に、実装は次を確実にするべきである。

JSON テキストは UTF-8 としてエンコードされ、文字列は、対になっていないサロゲート（unpaired surrogates）などの無効な Unicode シーケンスを含まない（[RFC7493] の Section 2.1）。
数値は IEEE 754 の倍精度がサポートする大きさや精度を超えない（[RFC7493] の Section 2.2）。
JSON オブジェクト内のメンバー名は、エスケープ文字の処理後に一意である（[RFC7493] の Section 2.3）。

存在しないプロパティと、null 値で存在するプロパティの曖昧さを避けるため、値が null のプロパティは JSON オブジェクトから省略するべきである。

11.6. Authorization Response Integrity

PDP は、PEP が受け取るデータの完全性を検証できるように、認可応答に署名することを選択してもよい。この実践は、認可プロセスにおける信頼を維持するうえで価値がある。

PEP は、署名されている場合、認可決定の署名を検証することで、認可応答が改ざんされていないことを確認できる。これにより応答の正確性と完全性が確保される。

TLS は、直接のポイント・ツー・ポイント接続における転送中データを効果的に保護するが、プロキシやゲートウェイなどの中間者が存在する場合、PEP と PDP の間の接続経路全体にわたるデータ完全性を保証するものではない。

デジタル署名は、この文脈で重要な利点を提供する。デジタル署名は否認防止（non-repudiation）を提供し、応答が確かに PDP から発生したことを検証できる。さらに、デジタル署名は認可応答の完全性を保証し、その内容が転送中に変更されていないことを確認する。

11.7. Availability & Denial of Service

PDP は、要求ペイロードサイズ、要求数、無効な JSON、ネストした JSON 攻撃、またはメモリ消費に関連する一般的な攻撃を避けるために、合理的な保護を適用するべきである。レート制限は、そのような問題に対処する 1 つの方法である。

11.8. Differences between Unsigned and Signed Metadata

未署名メタデータは、ホストされるサイトにおける TLS の使用により完全性保護される。これは、そのセキュリティが Internet Public Key Infrastructure（PKI）[RFC9525] に依存することを意味する。署名付きメタデータは、発行者によって適用される JWS 署名によって追加的に完全性保護され、Internet PKI に依存しない。未署名メタデータを使用する場合、メタデータを発行する当事者は PDP 自身である。一方、署名付きメタデータを使用する場合、メタデータを発行する当事者は、署名付きメタデータ内の iss（issuer）クレームによって表現される。署名付きメタデータを使用する場合、アプリケーションは署名を行った発行者に基づいて信頼判断を行える — これは未署名メタデータでは利用できない情報である。これらの信頼判断がどのように行われるかは、本仕様のスコープ外である。

11.9. Metadata Caching

Policy Decision Point メタデータは、Section 9.2.1 で規定されるとおり HTTP GET 要求を使用して取得される。通常の HTTP キャッシュ動作が適用され、GET は最新のコピーではなくキャッシュされたコピーを取得する場合がある。実装は、[RFC7234] で定義される max-age を伴う Cache-Control などの HTTP キャッシュ指示を利用して、適切な期間にわたって取得したメタデータをキャッシュできるようにするべきである。

12. IANA Considerations

本仕様は IANA に対して 4 つのアクションを要求する。すなわち、「AuthZEN」という名称の新しいプロトコル・レジストリ・グループの作成、このグループ内に 2 つの新しいレジストリ（「AuthZEN Policy Decision Point Metadata」および「AuthZEN Policy Decision Point Capabilities」）の設置、新しい Well-Known URI（「authzen-configuration」）の登録、そして新しい URN サブネームスペース（「authzen」）の登録である。

本仕様によって設立されるレジストリには、次の登録手続きが用いられる。

値は、openid-specs-authzen@lists.openid.net メーリングリストでの 2 週間のレビュー期間を経て、1 名以上の指定専門家（Designated Experts）によるレビューおよび承認の後、Specification Required [RFC8126] に基づいて登録される。ただし、仕様の最終版が公開される前に値の割り当てを可能にするため、指定専門家は、仕様が完成して公開されると確信できる時点で登録を承認してよい。ただし、指定専門家が判断する「適時」に仕様が完成・公開されない場合、指定専門家は IANA に登録の撤回を要請してもよい。

レビューのためにメーリングリストへ送信される登録要求は、適切な件名（例：「Request to register AuthZEN Policy Decision Point Metadata: example」）を使用するべきである。

レビュー期間内に、指定専門家は登録要求を承認または却下し、この決定をレビュー・リストと IANA に伝達する。却下には説明を含め、適用可能な場合には要求を成功させるための提案を含めるべきである。指定専門家が 14 日以内に応答しない場合には、IANA のエスカレーション手続きが適用される。

指定専門家が適用すべき基準には、提案された登録が既存機能を重複していないかの判断、一般的に適用可能でありそうか、あるいは単一アプリケーションにのみ有用かの判断、そして登録が妥当かどうかの判断が含まれる。

IANA は、指定専門家からのレジストリ更新のみを受け入れなければならず、登録に関するすべての要求はレビュー用メーリングリストへ誘導するべきである。

本仕様を利用する異なるアプリケーションの観点を代表できる複数の指定専門家を任命することが提案される。これにより、登録判断のレビューを広い見識に基づいて行えるようにする。特定の専門家にとって登録判断が利益相反を生むと受け取られ得る場合、その専門家は他の専門家の判断に委ねるべきである。

メーリングリストを使用する理由は、登録要求の公開レビューを可能にし、指定専門家および他の関係者が提案登録にフィードバックを提供できるようにするためである。指定専門家が最終仕様として公開される前に値を割り当てられるようにする理由は、登録を提案する仕様の著者が、仕様が完全に完成する前に指定専門家によるレビューの便益を得られるようにし、問題が特定された場合に、最終仕様の公開前に著者が反復して修正できるようにするためである。

12.1. AuthZEN Policy Decision Point Metadata Registry

本仕様は IANA に対し、レジストリ・グループ「AuthZEN Parameters」の下に「AuthZEN Policy Decision Point Metadata」レジストリを設置するよう求める。このレジストリは Policy Decision Point のメタデータ・パラメータと、それを定義する仕様への参照を記録する。

12.1.1. Registry Definition

Registry Name: AuthZEN Policy Decision Point Metadata

Registration Policy: [RFC8126] による Specification Required

Reference: [This Document]

12.1.2. Registration Template

Metadata Name:

要求される名称（例：「resource」）。この名称は大文字小文字を区別する。指定専門家が例外を認める説得力のある理由があると述べない限り、名称は大文字小文字を区別しない比較において他の登録済み名称と一致してはならない。

Metadata Description:

メタデータの簡潔な説明（例：「Resource identifier URL」）。

Change Controller:

IETF ストリームの RFC の場合は「IETF」と記載する。その他の場合は、責任主体の名称を記載する。その他の詳細（例：郵便住所、メールアドレス、ホームページ URI）を含めてもよい。

Specification Document(s):

パラメータを規定する文書（複数可）への参照。できれば、文書のコピーを取得するために使用できる URI を含めること。関連するセクションの表示を含めてもよいが必須ではない。

12.1.3. Initial Registrations

Metadata Name:

policy_decision_point

Metadata Description:

Policy Decision Point のベース URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

access_evaluation_endpoint

Metadata Description:

Policy Decision Point の Access Evaluation API エンドポイントの URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

access_evaluations_endpoint

Metadata Description:

Policy Decision Point の Access Evaluations API エンドポイントの URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

search_subject_endpoint

Metadata Description:

Subject エンティティ向け Policy Decision Point の Search API エンドポイントの URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

search_resource_endpoint

Metadata Description:

Resource エンティティ向け Policy Decision Point の Search API エンドポイントの URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

search_action_endpoint

Metadata Description:

Action エンティティ向け Policy Decision Point の Search API エンドポイントの URL

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.1

Metadata Name:

capabilities

Metadata Description:

特定の Policy Decision Point 能力を記述する URN の配列

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.2

Metadata Name:

signed_metadata

Metadata Description:

保護対象リソースに関するメタデータ・パラメータをクレームとして含む JWT。

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

[This Document] の Section 9.1.3

12.2. Well-Known URI Registry

本仕様は IANA に対し、Section 9.2 で定義される well-known URI を IANA の「Well-Known URIs」レジストリ [IANA.well-known-uris] に登録するよう求める。

12.2.1. Registry Contents

URI Suffix:

authzen-configuration

Reference:

[This Document]

Status:

permanent

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Related Information:

(none)

12.3. AuthZEN Policy Decision Point Capabilities Registry

本仕様は IANA に対し、レジストリ・グループ「AuthZEN Parameters」の下に「AuthZEN Policy Decision Point Capabilities」レジストリを設置するよう求める。このレジストリは PDP 固有の能力または機能を含む。これらの URN は、Policy Decision Point メタデータ・ディスカバリー文書（Section 9 で説明）で使用されることを意図しており、PEP が特定の PDP インスタンスのサポート機能を判断できるようにする。このレジストリの内容は、相互運用可能な能力を宣言したい AuthZEN 準拠 PDP ベンダーによって規定される。

12.3.1. Registry Definition

Registry Name: AuthZEN Policy Decision Point Capabilities

Registration Policy: [RFC8126] による Specification Required

Reference: [This Document]

12.3.2. Registration Template

Capability Name:

能力の名称。この名称はコロン（":"）文字で始まらなければならない。この名称は大文字小文字を区別する。指定専門家が例外を認める説得力のある理由があると述べない限り、名称は大文字小文字を区別しない比較において他の登録済み名称と一致してはならない。

Capability URN: AuthZEN Policy Decision Point Capability の URN。

Capability Description:

能力の簡潔な説明。

Change Controller:

OpenID Foundation AuthZEN Working Group

mailto:openid-specs-authzen@lists.openid.net

Specification Document(s):

パラメータを規定する文書（複数可）への参照。できれば、文書のコピーを取得するために使用できる URI を含めること。関連するセクションの表示を含めてもよいが必須ではない。

12.4. Registration of "authzen" URN Sub-namespace

本仕様は IANA に対し、[RFC3553] で定義される「IETF URN Sub-namespace for Registered Protocol Parameter Identifiers」レジストリ内に、新しい URN サブネームスペースを登録するよう求める。

Registry Name: authzen

Specification: [This Document]

Repository: 「AuthZEN Policy Decision Point Capabilities」レジストリ（\This Document] の Section 12.3）

Index value: サブパラメータは UTF-8 で指定されなければならず、必要に応じて標準の URI エンコーディングを使用すること。

13. References

13.1. Normative References

[RFC6749]

Hardt, D., Ed., 「The OAuth 2.0 Authorization Framework」, RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8259]

Bray, T., Ed., 「The JavaScript Object Notation (JSON) Data Interchange Format」, STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8615]

Nottingham, M., 「Well-Known Uniform Resource Identifiers (URIs)」, RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC3553]

Mealling, M., Masinter, L., Hardie, T., and G. Klyne, 「An IETF URN Sub-namespace for Registered Protocol Parameters」, BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/rfc/rfc3553>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., 「HTTP Semantics」, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[XACML]

Godik, S., Ed. and T. M. (Ed.), Ed., 「eXtensible Access Control Markup Language (XACML) Version 1.1」, 2006, <https://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf>.

13.2. Informative References

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[IANA.well-known-uris]

IANA, "Well-Known URIs", <https://www.iana.org/assignments/well-known-uris>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

[RFC7234]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/rfc/rfc7234>.

[RFC2617]

Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, <https://www.rfc-editor.org/rfc/rfc2617>.

[NIST.SP.800-162]

Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., Scarfone, K., and NIST, "Guide to Attribute Based Access Control (ABAC) Definition and Considerations", NIST Special Publications (General) 800-162, DOI 10.6028/NIST.SP.800-162, January 2014, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

Appendix A. Terminology

Subject:

認可決定が要求されている対象となるユーザー、またはマシン・プリンシパル。

Resource:

要求の対象。すなわち、認可決定が行われる対象となるリソース。

Action:

認可決定の文脈において、Subject が Resource に対して試みている操作。

Context:

要求に存在する場合、本要求のための環境的またはコンテキスト属性。応答に存在する場合、決定または検索結果に関連する追加のコンテキスト情報。

Decision:

PDP によって行われた評価決定の値。true は「allow」、false は「deny」。

PDP:

Policy Decision Point。本仕様で Authorization API として定義されるネットワーク・インタフェースを介して認可決定を提供するコンポーネントまたはシステム。

PEP:

Policy Enforcement Point。PDP のクライアントとして動作するコンポーネントまたはシステム。PEP の最も一般的なユースケースは、PDP から決定を取得して、その決定に基づいてアクセスを強制するために決定を要求することである。また、Subject がどのリソースにアクセスできるかを判定するなど、他の目的のために決定や検索結果を要求することもできる。

Appendix B. Acknowledgements

このテンプレートは、Pekka Savola、Elwyn Davies、Henrik Levkowetz によって書かれたテンプレートからの抜粋を使用している。

Appendix C. Document History

** 最終仕様から削除される予定 **

00 - 初期バージョン。
01 - 最初の Implementers Draft。Subject、Action、Resource のオプション・フィールドを properties サブオブジェクトへリファクタリングし、API のための意味のある JSON Schema と protobuf コントラクトを設計しやすくした。
02 - evaluations API を追加。
03 - search（subject、resource、action）API を追加。
04 - メタデータ・ディスカバリーを追加。
05 - 整合性編集、および Final Specification への準備。

Appendix D. Notices

OpenID Foundation（OIDF）は、いかなる Contributor、開発者、実装者、またはその他の関心ある当事者に対しても、この Implementers Draft、Final Specification、または Errata Corrections を取り込んだ Final Specification を、(i) 仕様の策定、および (ii) そのような文書に基づく Implementers Draft、Final Specifications、ならびに Errata Corrections を取り込んだ Final Specification の実装、という目的に限り、複製し、派生物を作成し、頒布し、実演し、表示するための、非独占的・ロイヤルティフリー・全世界的な著作権ライセンスを付与する。ただし、OIDF を資料の出所として帰属表示することが条件であり、その帰属表示は OIDF による推奨（endorsement）を示すものではない。

本仕様で説明される技術は、OpenID Foundation のメンバーおよびその他を含む、さまざまなソースからの貢献により提供された。OpenID Foundation は、当該技術が配布可能であることを確保するための措置を講じてきたが、本仕様で説明される技術の実装または使用に関して主張され得る知的財産その他の権利の有効性または範囲、ならびにそのような権利の下でライセンスが利用可能であるか否か、またはどの程度利用可能であるかについて、いかなる立場も取らない。また、そのような権利を特定するための独立した努力を行ったことを表明するものでもない。OpenID Foundation および本仕様への貢献者は、本仕様に関連して、商品性、非侵害、特定目的への適合性、または権原に関する黙示の保証を含む（ただしそれらに限られない）、明示・黙示その他いかなる保証も行わず（かつここに明示的に否認する）。本仕様を実装することに関するすべてのリスクは実装者が負う。OpenID Intellectual Property Rights ポリシー（openid.net に掲載）は、貢献者に対し、他の貢献者および実装者に対して特定の特許クレームを主張しない旨の特許約束を提供することを要求する。OpenID は、本仕様を実施するために必要となり得る技術をカバーし得る著作権、特許、特許出願、またはその他の専有権があれば、いかなる関心ある当事者もそれを OpenID に知らせるよう招請する。

Contributors

Marc Jordan

SGNL

Email: marc@sgnl.ai

Erik Gustavson

SGNL

Email: erik@sgnl.ai

Alexandre Babeanu

Indykite

Email: alex.babeanu@indykite.com

David Hyland

ID Partners

Email: dave@idpartners.com.au

Jean-François Lombardo

AWS

Email: jeffsec@amazon.com

Alex Olivier

Cerbos

Email: alex@cerbos.dev

Michiel Trimpe

VNG Realisatie

Email: michiel.trimpe@vng.nl

Elie Azerad

Independent Contributor

Email: elie.azerad@gmail.com

Authors' Addresses

Omri Gazitt (editor)

Aserto

Email: ogazitt@gmail.com

David Brossard (editor)

Axiomatics

Email: david.brossard@axiomatics.com

Atul Tulshibagwale (editor)

SGNL

Email: atul@sgnl.ai

Authorization API 1.0 – draft 05

Abstract

Table of Contents

1. Introduction

2. Model

3. Features

4. API Version

5. Information Model

5.1. Subject

5.1.1. Subject Properties

5.1.2. Examples (non-normative)

5.2. Resource

5.2.1. Resource Properties

5.2.2. Examples (non-normative)

5.3. Action

5.3.1. Action Properties

5.3.2. Examples (non-normative)

5.4. Context

5.5. Decision

5.5.1. Decision Context

5.5.2. Examples (non-normative)

5.5.2.1. Non-normative Example 1: conveying decision Reasons

5.5.2.2. Non-normative Example 2: conveying metadata and environmental elements

5.5.2.3. Non-normative Example 3: requesting step-up authentication

6. Access Evaluation API

6.1. The Access Evaluation API Request

6.1.1. Example (non-normative)

6.2. The Access Evaluation API Response

7. Access Evaluations API

7.1. The Access Evaluations API Request

7.1.1. Default values

7.1.2. Evaluations options

7.1.2.1. Evaluations semantics

7.1.2.1.1. Example: Evaluate read action for three documents using all three semantics

7.2. The Access Evaluations API Response

7.2.1. Errors

8. Search APIs

8.1. Semantics

8.2. Pagination

8.2.1. Paginated Requests

8.2.2. Paginated Responses

8.2.3. Examples (non-normative)

8.3. The Search API Response

8.4. Subject Search API

8.4.1. The Subject Search API Request

8.4.2. Example (non-normative)

8.5. Resource Search API

8.5.1. The Resource Search API Request

8.5.2. Example (non-normative)

8.6. Action Search API

8.6.1. The Action Search API Request

8.6.2. Example (non-normative)

9. Policy Decision Point Metadata

9.1. Data structure

9.1.1. Endpoint Parameters

9.1.2. Capabilities Parameters

9.1.3. Signature Parameter

9.2. Obtaining Policy Decision Point Metadata

9.2.1. Policy Decision Point Metadata Request

9.2.2. Policy Decision Point Metadata Response

9.2.3. Policy Decision Point Metadata Validation

10. Transport

10.1. HTTPS JSON Binding

10.1.1. JSON Serialization

10.1.2. Error Responses

10.1.3. Request Identification

10.1.4. Examples (non-normative)

11. Security Considerations

11.1. Communication Integrity and Confidentiality

11.2. Policy Confidentiality and Sender Authentication

11.3. Sender Authentication Failure

11.4. Trust

11.5. JSON Payload Considerations

11.6. Authorization Response Integrity

11.7. Availability & Denial of Service

11.8. Differences between Unsigned and Signed Metadata

11.9. Metadata Caching

12. IANA Considerations

12.1. AuthZEN Policy Decision Point Metadata Registry

12.1.1. Registry Definition

7.1.2.1.1. Example: Evaluate `read` action for three documents using all three semantics