Part 1

Document Metadata

• Workgroup: fapi
• Internet-Draft: fapi-grant-management-02
• Published: 15 July 2021
• Intended Status: Standards Track
• Authors:
  • T. Lodderstedt (yes.com)
  • S. Low (Biza.io)
  • D. Postnikov

Grant Management for OAuth 2.0

Abstract\ 本仕様は、クライアントがAuthorization Serverに対して自身のグラントを明示的に管理できるようにするための、OAuth 2.0 [RFC6749] の拡張を定義する。

1. Introduction

OAuth の Authorization Server は、認可プロセスの過程で Resource Owner が特定のクライアントに付与した権限、または事前設定されたポリシーに基づいて、Access Token および Refresh Token を発行する。これらの権限および特定クライアントへの割り当てを表す概念は、しばしば「underlying grant」と呼ばれる。

この概念は OAuth の基礎であるにもかかわらず、OAuth プロトコルにはグラントの明示的な表現が存在しない。その結果、クライアントはグラントを明示的に管理できない。たとえば、状態の照会や、不要になったグラントの失効（revoke）ができない。状態は、Access Token の更新（refresh）が成功/失敗した場合、あるいは Access Token を用いた API 呼び出しが HTTP ステータスコード 401（トークンが無効）または 403（トークンに権限が不足）で失敗した場合に、暗黙的に伝達される。

また、クライアントは、特定ユーザーに紐づく特定のグラントを更新するよう Authorization Server に明示的に要求できない。代わりに Authorization Server は通常、認可リクエストに含まれる client id と、認証済み Resource Owner の user id を用いて、既存のグラントを特定する。

クライアントが Authorization Server に既存グラントの更新を望む場合、ユーザーに関する識別データを取得し、それを login hint のようなパラメータで用いて「前回と同じユーザー」を参照する必要がある。この方法は、必要以上の識別データをクライアントに開示することになる。

別の提案として、Refresh Token を用いてグラントを参照するというパターンもあった。しかしこの場合、Refresh Token をフロントチャネル経由で認可リクエストの一部として送信する必要がある。Refresh Token はクレデンシャルであり、漏えいしたり、その経路で注入（inject）されたりし得るため、セキュリティ上の問題を生じる。

さらに、規制が厳しい分野（例: Open Data）では、クライアントが同時並行の独立したグラントを維持することを強制される場合がある。これは、同一ユーザーに対し、クライアントが提供する区別されたサービスの文脈で Resource Owner が当該クライアントへ委任した権限を表現するためである。この場合、異なる client_ids を用いることは適切ではない。

前述のユースケースを支援するため、本仕様は、クライアントが特定のグラントを識別するために使用できる grant_id を導入し、さらに、そのようなグラントIDの作成と使用を要求するための追加の認可リクエストパラメータを定義する。また、本仕様は Authorization Server が提供する新しいグラント管理 API を定義し、クライアントがグラントの状態を照会し、失効させられるようにする。

1.1. Terminology

Grant は、User が Client に付与した権限（認可）の集合である。Grant は、Authorization Server が捕捉して管理するリソースである。

Consent は法的概念であり、グラントの作成につながり得るだけでなく、法務、監査、報告、保管、否認防止の要件を含み得る。Grant は、consent の結果として作成される認可である。

Grant Management API: Authorization Server が提供する HTTP ベースの API であり、クライアントはこれを用いてグラントの状態を照会、更新、置換、失効できる。

Data Recipients（オーストラリアおよび FDX）および TPPs（英国および PSD2）は、以下のユースケースを説明するために用いる OAuth クライアントの例である。

Data Holders（オーストラリア）、ASPSPs（英国および PSD2）および Data Providers（FDX）は、以下のユースケースを説明するために用いる OAuth Authorization Servers の例である。

2. Overview

この拡張をサポートする Authorization Server は、クライアントが自身のグラントを明示的に管理できるようにする。基本設計の原則は、グラントの作成および更新は常に OAuth の認可リクエストを用いて要求され、グラントの状態照会および失効は新しい Grant Management API を用いて行われる、というものである。

前提となる想定は、グラントの作成および更新にはほとんど常に Resource Owner との対話が必要だということである。さらに、クライアントは Authorization Server の支援なしに、対応するトークンとともに grant id を自ら管理することが想定されている。

3. Use cases supported

3.1. Revoking a grant

クライアントは、特定のグラントを失効させる能力を必要とする。

例:

• 英国では、TPPs は現在、ASPSP 側で認可を失効させるために、DELETE /account-access-consents/{ConsentId} のカスタムエンドポイントを使用している。
• オーストラリアでは、Data Recipients は現在、ユーザーが Data Recipient のダッシュボード経由で同意を取り消した後に、Data Holder 側で認可を失効させるために、cdr_arrangement_id と POST /arrangements/revoke のカスタムエンドポイントを使用している。
• どちらも、標準化された grant_id と grant management endpoint の DELETE 操作を用いることで同等のことを実現できる。

3.2. Querying the details of a grant

元の認可後にグラントの詳細の一部が変わり得るビジネスシナリオは多い。そのためクライアントは、グラントの現在の詳細を照会する手段を必要とする場合がある。

例:

• 英国では、TPPs は現在、ASPSP から認可の詳細を取得するために、GET /account-access-consents/{ConsentId} のカスタムエンドポイントを使用している。
• 銀行業務では、クライアントはグラントの詳細を照会して、ユーザーによってどの口座がグラントに追加されたか、あるいは（ユーザーに選択肢がある場合の）より細かな認可の詳細を判断できる。
• シナリオによっては Resource Owner が複数の自然人であることがあり、その場合、追加の authorisations が必要になることがある。これは、元の認可が、開始した Resource Owner によって付与された後に発生し得る。クライアントは、認可後の任意の時点で consent の状態を照会して、完全な認可が成立したかどうかを確認できる（アドホックな照会または定期的なポーリングによる）。このカテゴリーに当てはまる別のシナリオとして、法人に対する複数当事者の承認プロセスがある。
• 法域によっては、クライアントおよび authorisation server のアプリケーションが、ユーザーが authorisation server に与えた authorisations を閲覧し失効できるダッシュボードを提供することを求める。グラントの詳細を照会できれば、クライアントは up-to-date な状態および consent の内容にアクセスできる。

3.3. Replace the details of a grant

クライアントは、あるグラントの既存の権限を新しい権限で置き換えたい場合がある。

シナリオによっては、同じ grant id を維持しつつグラントを新しいものに置き換えることを選ぶ場合がある。古い権限は失効され、ユーザーによって承認されれば新しい権限が追加される。クライアントは新しい要求の完全な詳細を指定しなければならない。

例:

• 英国およびオーストラリアでは、認可リクエストでグラント識別子が指定された場合に「replace」がサポートされる。

3.4. Update the details of a grant

クライアントは、既存グラントの詳細を更新したい場合がある。追加の詳細はグラントにマージされる。

これは特に、同一の Access Token で API にアクセスできるようにするため、または単一の Refresh Token から新しい Access Token を取得できるようにするために、必要に応じて既存グラントに権限を追加したい場合に有用である。シナリオによっては、グラントの期間を延長する目的だけで update を選ぶ場合もある。

クライアントは、追加または修正された authorisation の詳細のみを指定すればよい。grant id は同じまま保持される。

また、ある API リクエストが権限不足（典型的には HTTP ステータスコード 403）で失敗した場合、クライアントは別の認可プロセスを開始しなければならないこともある。

「update」を用いて実装できる例:

• authorisation の期間延長
• OAuth Incremental Authorization（https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04）で扱われるその他のユースケース

3.5. Support for concurrent grants

エコシステムによっては、同一のクライアント、同一の Authorization Server、同一の Resource Owner の間で、複数の有効な authorisations（concurrent grants）が同時に存在し得る。concurrent grants をサポートするため、最低限、クライアントは特定グラントを参照して失効できる能力に加え、同じ当事者間に既存グラントが存在する場合でも新しいグラントを作成できる能力が必要となる。

例:

• オーストラリアでは、Data Recipients と Data Holders は concurrent grants（authorizations）をサポートすることが義務付けられている。新しいグラントが以前のグラントの置換であるか、新規グラントであるかを決めるのは Data Recipient 側である。
• 英国でも concurrent grants がサポートされている。

3.6. Creation of another resource

ユースケースによっては、グラントが別のリソースを作成する権限となる場合がある。作成されたリソースは独立したライフサイクルを持ち、Authorization Server の外側で管理できる。

例:

• 支払い開始（payment initiation）では、支払い要求を作成する権限を持つ新しいグラントを最初に作成する場合がある。クライアントは取得した Access Token を用いて支払いを開始し、その結果として新しい支払い/取引リソースが作成され得る。

3.7. Obtaining new tokens for existing grants

クライアントは、認可リクエストを再発行し、既存グラントを参照し、残りの Authorization Code Flow を実行することで、既存グラントに基づいて新しい Access Token、および任意で Refresh Token を取得することもできる。

4. Use cases not supported

4.1. Historical grant, authorisation or consent records

Grant Management 仕様は、クライアントがグラント（Resource Owner の consent）の状態および内容を照会できるようにする。これは、クライアントが現在有効なグラントに何が含まれているかを理解するためのものである。法務、報告、保管などの目的、たとえば失効または取り消された consent を 7 年間保持する、といった用途を提供するものではない。

4.2. Consent resource shared with other parties

End-User が自身の consents を第三者（例: 集中型の同意管理ダッシュボード）と共有したい、というユースケースがある。この目的のために新しい Consent Resource API を作成できるが、これは本仕様のスコープ外である。

また、AS が単一の管理主体に属するクライアント間でグラントの共有をサポートする、という別のユースケースもある。たとえば、ある組織が複数のプラットフォーム（例: iOS、Android、Web app）にまたがってサービスを提供し、それぞれが別のクライアントを持つ場合である。[OpenID.Registration] で定義される sector identifier URIs は、この目的を達成するための選択肢のひとつである。これは本仕様のスコープ外である。

5. OAuth Protocol Extensions

5.1. Requirements for Authorization Servers

セキュリティ上の理由により、グラント管理は Confidential client のみのクライアントに制限される。

5.2. Authorization Request

本仕様は、認可リクエストパラメータ grant_id と grant_management_action を導入する。これらのパラメータは、認可リクエストとして機能する任意のリクエストで使用できる。たとえば、CIBA リクエストで使用してもよい。

• grant_id: OPTIONAL。特定の Authorization Server が、特定のクライアントおよび特定の Resource Owner に対して管理する個別のグラントを識別する文字列値。grant_id の値は当該 Authorization Server により発行されていなければならず、当該クライアントはその特定の grant id を使用する権限を与えられていなければならない。

• grant_management_action: Authorization Server が認可リクエストを処理する際にグラントをどのように扱うかを制御する文字列値。本仕様は以下の値を定義する。

  • create: AS が grant management action create をサポートする場合、AS は新しいグラントを作成する。
  • update: このモードでは、クライアントは grant_id パラメータを用いて grant id を指定する必要がある。パラメータが存在し、AS が grant management action update をサポートする場合、AS は今回のリクエストでユーザーが同意した権限を、グラント内に既に存在する権限とマージする。
  • replace: このモードでは、クライアントは grant_id paramter を用いて grant id を指定する必要がある。パラメータが存在し、AS が grant management action replace をサポートする場合、AS はグラントを、今回のリクエストでクライアントが要求しユーザーが同意した権限「のみ」に変更する。

以下の例は、クライアントが特定の grant id を使用するように認可リクエストで要求する方法を示す。

GET /authorize?response_type=code&
     client_id=s6BhdRkqt3
     &grant_management_action=update
     &grant_id=TSdqirmAxDa0_-DB_1bASQ
     &scope=write
     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
     &code_challenge_method=S256
     &code_challenge=K2-ltc83acc4h... HTTP/1.1
Host: as.example.com

5.3. Authorization Error Response

grant_id が不明または無効な場合、Authorization Server はエラーコード invalid_grant_id で応答しなければならない。

AS がクライアントにより要求された grant management action をサポートしない場合、または grant management action が必要（grant_management_action_required メタデータによる）であるにもかかわらず指定されていない場合、エラーコード invalid_request で応答しなければならない。

5.4. Token Response

本仕様は、token response パラメータ grant_id を導入する。

• grant_id: 特定の Authorization Server が、特定のクライアントおよび特定の Resource Owner に対して管理する個別のグラントを識別する URL safe な文字列値。grant_id の値は、特定の Authorization Server の文脈で一意でなければならず、推測が現実的でない程度の十分なエントロピーを持つことが望ましい（SHOULD）。

AS が grant management actions（query、revoke、update、replace）のいずれかをサポートする場合、AS は grant_id を返す。

以下にレスポンス例を示す。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "example",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "grant_id": "TSdqirmAxDa0_-DB_1bASQ"
}

5.5. Lifecycle of the grant

5.5.1. Creation

Grant は、認可済み権限の集合として、認可リクエストの完了時に AS により作成される。

初回の Authorization Code Flow では、対応するトークンがクライアントによって正常に受領（claim）された時点で、グラントは有効（active）とみなすべきである。

トークンが受領されなかった場合、グラントは合理的なタイムアウト後に AS により削除されるべきである。削除のタイムラインは AS の実装に委ねられる。

5.5.2. Modification

Grant は、クライアントが update または replace アクションを通じて変更できる。

Grant の一部要素は、AS が更新して、グラントに含まれるリソースの一部の状態を反映してもよい。たとえば、ユーザーがクライアントに対してある口座を共有することを選び、その口座が完全に認可済みとみなされる前に追加の authorisations を必要とする場合である。

5.5.3. Deletion

Authorization Server は裁量で古い（obsolete）グラントを削除してもよいが、グラントに含まれる認可要素の状態および有効期限を考慮すべきである。正確な仕組みはデプロイごとに異なり得る。たとえば、デプロイによっては、グラントに付随する個々の authorization_details がすべて期限切れまたは失効した場合にグラントをパージすることがある。

6. Grant Management API

Grant Management API は、クライアントが以前に Authorization Server から取得した grant_id を持つグラントに対して、さまざまなアクションを実行できるようにする。

現在サポートされるアクションは以下である。

• Query: 特定のグラントの現在の状態を取得する
• Revoke: グラントの失効を要求する

Grant Management API は、機能上およびプライバシー上の理由から、特定クライアントの全グラントへの一括アクセスは提供しない。すべてのグラントは特定の Resource Owner に関連付けられているため、クライアントが「どのユーザーに対してこのグラントを使えるか」を示す手がかりがない限り、状態を取得してもクライアントにとって有用ではない。状態データにユーザーの識別データを追加することは、OAuth がユーザーに対してクライアントへのプライバシー保護として提供しているものを弱めてしまう。

Grant Management API は、トークン漏えいを防ぐため、特定グラントに関連付けられたトークンを公開しない。クライアントは自身のグラントを対応するトークンとともに管理し、正しいユーザー文脈で利用されることを保証することが想定されている。

6.1. API authorization

grant management API を使用するには、クライアントはこの API に対して認可された Access Token を取得する必要がある。この Access Token を取得するためにクライアントが使用する grant_type は、本仕様のスコープ外である。

このトークンは、以下の scope 値に関連付けられていることが求められる。

• grant_management_query: クライアントがグラントの状態を照会するための Access Token を要求する際に使用する scope 値
• grant_management_revoke: クライアントがグラントを失効させるための Access Token を要求する際に使用する scope 値

6.2. Endpoint

grant management API は、Authorization Server が提供する新しい endpoint によって提供される。クライアントは、server metadata パラメータ grant_management_endpoint（Section 7.1 参照）を利用して endpoint URL を取得してもよい（MAY）。

6.3. Grant Resource URL

特定グラントの resource URL は、grant management endpoint URL、スラッシュ、そして grant_id を連結して構築する。

例として、grant management endpoint が次のように定義され、

• https://as.example.com/grants

grant_id が次のとおりである場合、

• TSdqirmAxDa0_-DB_1bASQ

得られる resource URL は次のとおりである。

• https://as.example.com/grants/TSdqirmAxDa0_-DB_1bASQ

6.4. Query Status of a Grant

グラントの状態は、以下の例に示すとおり、グラントの resource URL に HTTP GET リクエストを送信することで照会する。

GET /grants/TSdqirmAxDa0_-DB_1bASQ
Host: as.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Authorization Server は、以下の例に示すような JSON 形式のレスポンスで応答する。

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: application/json

{
  "scopes": [
    {
      "scope": "contacts read write",
      "resources": [
        "https://rs.example.com/api"
      ]
    },
    {
      "scope": "openid"
    }
  ],
  "claims": [
    "given_name",
    "nickname",
    "email",
    "email_verified"
  ],
  "authorization_details": [
    {
      "type": "account_information",
      "actions": [
        "list_accounts",
        "read_balances",
        "read_transactions"
      ],
      "locations": [
        "https://example.com/accounts"
      ]
    }
  ]
}

グラントに関連付けられた権限は、以下の構造を持つオブジェクトの JSON 配列として提供される。

• scopes: JSON 配列。各エントリは scope フィールドを含み、さらに 1 つ以上の resource フィールドを含み得る。この構造により、AS は scope 値と、（[RFC8707] で定義される）それらが要求され承認された resource indicators との関係を表現できる。具体的なマッピングは AS の裁量に委ねられる。AS は、たとえば「resource ごと」にそれらのオブジェクトを整理し、各 resource に対して関連する scope 値のリストを持たせてもよい。また、ある認可リクエストで要求され承認されたとおりに、scope 値のまとまりを resource パラメータ値と組にして保存してもよい。
• claims: JSON 配列。該当グラントに関連付けられた 1 つ以上の認可リクエストで要求され、同意されたすべての OpenID Connect claims（[OpenID] 参照）の名前を含む。
• authorization_details: [I-D.ietf-oauth-rar] で定義される JSON Object。該当グラントに関連付けられた 1 つ以上の認可リクエストで要求され、同意されたすべての authorization details を含む。

レスポンス構造は、拡張で定義される追加要素を含んでもよい（MAY）。

OP が高負荷を経験している場合、[RFC7231] の Section 7.1.3 に記載のとおり Retry-After レスポンスヘッダーを付けて HTTP 503 を返す場合がある。その場合クライアントは、ヘッダーに示された時間が経過した後にのみ再試行するなど、当該ヘッダーを尊重すべきである。

Part 2

6.5. Revoke Grant

グラントを失効させるには、クライアントはグラントの resource URL に HTTP DELETE リクエストを送信する。Authorization Server は HTTP ステータスコード 204 と空のレスポンスボディで応答する。

以下の例に示す。

DELETE /grants/TSdqirmAxDa0_-DB_1bASQ
Host: as.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

HTTP/1.1 204 No Content

AS は、その特定のグラントに基づいて発行されたすべての Refresh Token を失効させなければならない（MUST）。また、その特定のグラントに基づいて発行されたすべての Access Token を失効させることが望ましい（SHOULD）。

注: [RFC7009] で定義される token revocation は、本仕様で定義される grant revocation と異なる。token revocation は、underlying grant の失効を引き起こすことが必須ではない。token revocation の場合にグラントを保持し、その後の認可リクエストによってクライアントがこのグラントへ再接続できるようにするかどうかは AS の裁量である。この分離は、クライアントがクレデンシャルとしてのトークンを単に破棄したかっただけの場合に、ユーザー体験を改善し得る。

6.6. Error Responses

• resource URL が不明な場合、Authorization Server は HTTP ステータスコード 404 で応答する。
• クライアントが呼び出しを行う権限を持たない場合、Authorization Server は HTTP ステータスコード 403 で応答する。
• リクエストに有効な Access Token が欠けている場合、Authorization Server は HTTP ステータスコード 401 および invalid_token エラーコードで応答する。

7. Metadata

7.1. Authorization server's metadata

• grant_management_actions_supported: OPTIONAL。AS がサポートするアクションを含む JSON 配列。許容値は query、revoke、update、create である。

  • query: AS はクライアントが特定グラントに関連付けられた権限を照会できるようにする。
  • revoke: AS はクライアントがグラントを失効できるようにする。
  • update: AS はクライアントが既存グラントを更新できるようにする。
  • replace: AS はクライアントが既存グラントを置換できるようにする。
  • create: AS はクライアントが新しいグラントの作成を要求できるようにする。

  省略された場合、AS はいかなる grant management actions もサポートしない。

• grant_management_endpoint: OPTIONAL。Authorization Server の Grant Management Administration Endpoint の URL。

• grant_management_action_required: OPTIONAL。true の場合、すべての認可リクエストは grant_management_action を指定しなければならない（MUST）。省略された場合のデフォルトは false である。

8. Implementation Considerations

8.1. Client to grant relationship

クライアント（論理エンティティ）は、複数のプラットフォーム（例: iOS と Android のアプリおよび Web app）にまたがってサービスを提供するために、複数の client ids を使用してもよい（MAY）。AS が、同じクライアントに属する client ids 間でのグラント共有をサポートすることが推奨される（RECOMMENDED）。[OpenID.Registration] で定義される sector identifier URIs は、client ids を単一の管理下にグルーピングするための選択肢のひとつである。

8.2. Addressibility of grant components

実装者は、グラント内の個々のコンポーネントをアドレス指定できるようにする解決策を検討したい場合がある。Trust ecosystems は実装時に要件を検討し、以下のいずれかを考慮すべきである。

• authorization オブジェクト（すなわち RAR 内）に一意の識別子（例: RAR 内の id）を含める、または
• update および append アクションを導出できるように、グラントを比較するアルゴリズムを定義する

9. Privacy Consideration

grant_id は、クライアントとユーザーの間に確立された各グラントごとに Authorization Server により発行される。これにより、異なるクライアント間での相関が防止されるはずである。

grant_id のみからユーザーを特定したり、個人を特定できる情報（PII）を導出したりできてはならない。

grant_id は、同一エンティティに属する異なる client_id 間で共有され得る。

10. Security Considerations

grant id は公開識別子とみなされ、秘密情報ではない。実装は、grant ids が攻撃者に漏えいすることを前提としなければならない（MUST）。たとえば認可リクエストを通じて漏えいし得る。そのため、特定グラントに関連付けられた機微なデータへのアクセスは、適切なセキュリティ対策なしに可能になってはならない（MUST NOT）。たとえば、当該クライアントに対する適切な認証および認可が必要である。

grant mode replace を利用したトランザクションの実行中、結果として得られるグラントに含まれる権限セットが、以前の権限セットの上位集合ではない可能性がある。そのため、自己完結型の Access Token を使用しており、Access Token の寿命より短い時間で即時の反映（propogation）が必要である場合、AS はアウト・オブ・バンドの手段により、関連するすべてのトークンを直ちに失効させるべきである。

11. Normative References

• [RFC8414]\ Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, https://www.rfc-editor.org/info/rfc8414.

• [I-D.ietf-oauth-rar]\ Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-05, 15 May 2021, https://tools.ietf.org/html/draft-ietf-oauth-rar-05.

• [RFC7231]\ Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, https://www.rfc-editor.org/info/rfc7231.

• [RFC8707]\ Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, https://www.rfc-editor.org/info/rfc8707.

• [OpenID]\ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", 8 November 2014, http://openid.net/specs/openid-connect-core-1_0.html.

12. Informative References

• [IANA.OAuth.Parameters]\ IANA, "OAuth Parameters", http://www.iana.org/assignments/oauth-parameters.

• [RFC6749]\ Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/info/rfc6749.

• [RFC7009]\ Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, https://www.rfc-editor.org/info/rfc7009.

• [OpenID.Registration]\ Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", 8 November 2014, https://openid.net/specs/openid-connect-registration-1_0.html.

Appendix A. IANA Considerations

A.1. OAuth Parameter registry

本仕様は、[RFC6749] により確立された [IANA.OAuth.Parameters] の IANA「OAuth Parameters Registry」レジストリに、以下の値の登録を要求する。

• Parameter name: grant_id
  • Parameter location: authorization request, token response
  • Change Controller: IESG
  • Specification Document(s): Section 5.2 of [[ this document ]]

• Parameter name: grant_management_action
  • Parameter location: authorization request
  • Change Controller: IESG
  • Specification Document(s): Section 5.2 of [[ this document ]]

A.2. OAuth Authorization Server Metadata

本仕様は、[RFC8414] により確立された [IANA.OAuth.Parameters] の IANA「OAuth Authorization Server Metadata」レジストリに、以下の値の登録を要求する。

• Metadata Name: grant_management_actions_supported
  • Metadata Description: AS がサポートする authorization details の type を含む JSON 配列
  • Change Controller: IESG
  • Specification Document(s): Section 7.1 of [[ this document ]]

• Metadata Name: grant_management_endpoint
  • Metadata Description: Authorization Server の Grant Management Administration Endpoint の URL
  • Change Controller: IESG
  • Specification Document(s): Section 7.1 of [[ this document ]]

• Metadata Name: grant_management_action_required
  • Metadata Description: true の場合、すべての認可リクエストが grant_management_action を指定しなければならない（MUST）ことを示す Boolean
  • Change Controller: IESG
  • Specification Document(s): Section 7.1 of [[ this document ]]

A.3. OAuth Extensions Error registry

本仕様は、[RFC6749] により確立された [IANA.OAuth.Parameters] の IANA「OAuth Extensions Error registry」レジストリに、以下の値の登録を要求する。

• Metadata Name: invalid_grant_id
  • Metadata Description: クライアントに対し、無効な grant_id であることを示す。
  • Change Controller: IESG
  • Specification Document(s): Section 5.2 of [[ this document ]]

Appendix B. Acknowledgements

本仕様の発展に役立つ貴重なフィードバックおよび貢献を提供してくれた Vladimir Dzhuvinov、Takahiko Kawasaki、Roland Hedberg、Filip Skokan、Dave Tonge、Brian Campbell、Ralph Bragg に感謝する。

Appendix C. Notices

Copyright (c) 2021 The OpenID Foundation.

The OpenID Foundation (OIDF) は、あらゆる Contributor、開発者、実装者、その他の利害関係者に対し、(i) 仕様の策定、ならびに (ii) そのような文書に基づく Implementers Drafts および Final Specifications の実装の目的に限り、本 Implementers Draft または Final Specification を複製し、派生物を作成し、頒布し、上演し、表示するための、非独占的、ロイヤルティフリー、全世界的な著作権ライセンスを付与する。ただし、OIDF が素材の提供元であることの帰属表示を行うことを条件とし、その帰属表示が OIDF による推奨を示すものであってはならない。

本仕様で記述される技術は、OpenID Foundation のメンバーおよびその他を含むさまざまな提供元からの貢献により利用可能となった。OpenID Foundation は当該技術が頒布可能であることを確保するための措置を講じているが、本仕様に記述された技術の実装または使用に関して主張され得る知的財産その他の権利の有効性または範囲、ならびにそのような権利に基づくライセンスが利用可能か否かについて、いかなる立場も取らない。また、そのような権利を特定するための独立した努力を行ったことも表明しない。OpenID Foundation および本仕様への貢献者は、本仕様に関して、商品性、非侵害、特定目的への適合性、権原に関する黙示保証を含む（ただしこれらに限られない）いかなる保証（明示・黙示・その他）も行わず（ここに明示的に否認する）、本仕様の実装に関する一切のリスクは実装者が負う。OpenID Intellectual Property Rights policy は、貢献者が、他の貢献者および実装者に対し、特定の特許請求を主張しないという特許の約束（patent promise）を提示することを求める。OpenID Foundation は、本仕様を実施するために必要となり得る技術をカバーする著作権、特許、特許出願、その他の専有権が存在する場合、あらゆる利害関係者に対し、その旨を OpenID Foundation に知らせるよう呼びかける。

Appendix D. Document History

[[ To be removed from the final specification ]]

-02

• server metadata に replace grant management action を追加
• IANA セクションの内容を追加

-01

• 認可リクエストを簡素化
• AS とクライアントの grant management 振る舞いを制御するメタデータを追加
• grant resource のデータモデルを拡張

-00

• 初版

Authors' Addresses

• Torsten Lodderstedt\ yes.com\ Email: torsten@lodderstedt.net

• Stuart Low\ Biza.io\ Email: stuart@biza.io

• Dima Postnikov\ Email: dima@postnikov.net