メインコンテンツまでスキップ

1. はじめに (Introduction)

"OAuth 2.0認可フレームワーク"[RFC6749]は、OAuthクライアントがアクセストークンの要求されたスコープ、すなわち限定された能力を指定できるscopeパラメータを定義しています。このメカニズムは、"リソース所有者のプロファイルへの読み取りアクセスを与えてください"などの静的シナリオや粗粒度の認可リクエストを実装するには十分です。しかし、"商家Aに45ユーロの金額を転送させてください"や"ディレクトリAへの読み取りアクセスとファイルXへの書き込みアクセスを与えてください"などの細粒度の認可要件を指定するには不十分です。

本仕様は、クライアントがJSON[RFC8259]データ構造の表現力を使用して細粒度の認可要件を指定できる新しいパラメータauthorization_detailsを導入します。

例えば、信用転送の認可リクエスト(いくつかのオープンバンキングイニシアチブでは"支払い開始"と呼ばれる)は、次のようなJSONオブジェクトを使用して表現できます:

{
  "type": "payment_initiation",
  "locations": [
    "https://example.com/payments"
  ],
  "instructedAmount": {
    "currency": "EUR",
    "amount": "123.50"
  },
  "creditorName": "Merchant A",
  "creditorAccount": {
    "bic": "ABCIDEFFXXX",
    "iban": "DE02100100109307118603"
  },
  "remittanceInformationUnstructured": "Ref Number Merchant"
}

このオブジェクトには、ユーザーに通知し同意を得るために必要な、金額、通貨、債権者などの意図された支払いに関する詳細情報が含まれています。認可サーバー(AS)およびそれぞれのリソースサーバー(RS)(支払い開始APIを提供)は、この同意を共同で実施します。

オープンバンキングおよび電子署名分野の新しいユースケースから生じる課題の包括的な議論については、[Transaction-Auth]を参照してください。

カスタム認可リクエストを促進することに加えて、本仕様は、異なるAPI間で使用するための一連の共通データタイプフィールドも導入します。

1.1. 表記法と用語 (Conventions and Terminology)​

本文書のキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および"OPTIONAL"は、BCP 14[RFC2119][RFC8174]に記載されているように解釈されるものとし、ここに示すようにすべて大文字で表示される場合に限ります。

本仕様は、"OAuth 2.0認可フレームワーク"[RFC6749]で定義されている用語"アクセストークン"、"リフレッシュトークン"、"認可サーバー"(AS)、"リソースサーバー"(RS)、"認可エンドポイント"、"認可リクエスト"、"認可レスポンス"、"トークンエンドポイント"、"グラントタイプ"、"アクセストークンリクエスト"、"アクセストークンレスポンス"、および"クライアント"を使用します。

に最終更新