[要約] RFC 9126 - OAuth 2.0 Pushed Authorization Requestsは、認証リクエストをより安全に行うための拡張であり、クライアントが認証サーバーに直接リクエストを送信することを可能にします。これにより、リダイレクトを介したリクエストの漏洩リスクが減少します。主に、Webやモバイルアプリケーションでのセキュアなユーザー認証とデータアクセス制御に利用されます。
Internet Engineering Task Force (IETF) T. Lodderstedt
Request for Comments: 9126 yes.com
Category: Standards Track B. Campbell
ISSN: 2070-1721 Ping Identity
N. Sakimura
NAT.Consulting
D. Tonge
Moneyhub Financial Technology
F. Skokan
Auth0
September 2021
OAuth 2.0 Pushed Authorization Requests
OAuth 2.0プッシュ承認要求
Abstract
概要
This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.
このドキュメントはプッシュされた許可要求（PAR）エンドポイントを定義します。これにより、クライアントは直接要求を介してOAuth 2.0許可要求のペイロードを許可サーバーにプッシュし、それらのデータへの参照として使用される要求URIを提供することができます。その後の許可エンドポイントへの呼び出し。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9126.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9126で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Introductory Example
1.2. Conventions and Terminology
2. Pushed Authorization Request Endpoint
2.1. Request
2.2. Successful Response
2.3. Error Response
2.4. Management of Client Redirect URIs
3. The "request" Request Parameter
4. Authorization Request
5. Authorization Server Metadata
6. Client Metadata
7. Security Considerations
7.1. Request URI Guessing
7.2. Open Redirection
7.3. Request Object Replay
7.4. Client Policy Change
7.5. Request URI Swapping
8. Privacy Considerations
9. IANA Considerations
9.1. OAuth Authorization Server Metadata
9.2. OAuth Dynamic Client Registration Metadata
9.3. OAuth URI Registration
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
This document defines the pushed authorization request (PAR) endpoint, which enables an OAuth [RFC6749] client to push the payload of an authorization request directly to the authorization server. A request URI value is received in exchange; it is used as reference to the authorization request payload data in a subsequent call to the authorization endpoint via the user agent.
このドキュメントでは、Pushed Authorization Request（PAR）エンドポイントを定義します。これにより、OAuth [RFC6749]クライアントは許可要求のペイロードを許可サーバーに直接プッシュします。要求URI値はExchangeで受信されます。これは、ユーザエージェントを介した許可エンドポイントへの後続の呼び出しで、許可要求ペイロードデータの参照として使用されます。
In OAuth [RFC6749], authorization request parameters are typically sent as URI query parameters via redirection in the user agent. This is simple but also yields challenges:
OAuth [RFC6749]では、許可要求パラメータは通常、ユーザーエージェントのリダイレクトを介してURIクエリパラメータとして送信されます。これは単純ですが、課題も課金します。
* There is no cryptographic integrity and authenticity protection. An attacker could, for example, modify the scope of access requested or swap the context of a payment transaction by changing scope values. Although protocol facilities exist to enable clients or users to detect some such changes, preventing modifications early in the process is a more robust solution.
* 暗号化の整合性と信頼性の保護はありません。攻撃者は、例えば、スコープ値を変更することによって支払いトランザクションのコンテキストを要求または交換するアクセスの範囲を変更することができます。クライアントやユーザーがそのような変更を検出できるようにするためのプロトコル機能は存在しますが、プロセスの早期に修正を防ぐことはより堅牢なソリューションです。
* There is no mechanism to ensure confidentiality of the request parameters. Although HTTPS is required for the authorization endpoint, the request data passes through the user agent in the clear, and query string data can inadvertently leak to web server logs and to other sites via the referrer. The impact of such leakage can be significant, if personally identifiable information or other regulated data is sent in the authorization request (which might well be the case in identity, open banking, and similar scenarios).
* 要求パラメータの機密性を確保するためのメカニズムはありません。httpsは許可エンドポイントに必要ですが、要求データはクリア内のユーザーエージェントを通過し、クエリ文字列データは誤ってWebサーバーログにリークして参照元を介して他のサイトにリークすることができます。個人的に識別可能な情報または他の規制されたデータが許可要求で送信されている場合（それはID、オープンバンキング、および同様のシナリオの場合がよくある可能性がある）場合、そのような漏れの影響は重要になる可能性があります。
* Authorization request URLs can become quite large, especially in scenarios requiring fine-grained authorization data, which might cause errors in request processing.
* 承認要求のURLは、特に微細な承認データを必要とするシナリオにおいて、非常に大きくなる可能性があります。これはリクエスト処理にエラーを引き起こす可能性があります。
JWT-Secured Authorization Request (JAR) [RFC9101] provides solutions for the security challenges by allowing OAuth clients to wrap authorization request parameters in a Request Object, which is a signed and optionally encrypted JSON Web Token (JWT) [RFC7519]. In order to cope with the size restrictions, JAR introduces the "request_uri" parameter that allows clients to send a reference to a Request Object instead of the Request Object itself.
JWT-Secured Authorization Request（JAR）[RFC9101]は、OAuthクライアントが要求オブジェクトで承認要求パラメータをラップすることを許可することで、セキュリティ上の課題に対する解決策を提供します。これは、署名付きでオプションで暗号化されたJSON Webトークン（JWT）[RFC7519]です。サイズの制限に対処するために、JARは、クライアントが要求オブジェクト自体の代わりに要求オブジェクトへの参照を送信できるようにする「request_uri」パラメータを導入します。
This document complements JAR by providing an interoperable way to push the payload of an authorization request directly to the authorization server in exchange for a "request_uri" value usable at the authorization server in a subsequent authorization request.
このドキュメントは、その後の許可要求で許可サーバーで使用可能な「Request_URI」値と引き換えに、許可要求のペイロードを許可サーバーに直接プッシュするための相互運用方法を提供することによってJARを補完する。
PAR fosters OAuth security by providing clients a simple means for a confidential and integrity-protected authorization request. Clients requiring an even higher security level, especially cryptographically confirmed non-repudiation, are able to use JWT-based Request Objects as defined by [RFC9101] in conjunction with PAR.
PARは、顧客を提供することで、顧客を顧客に提供することで、機密保護保護承認要求のための簡単な手段を提供します。さらに高いセキュリティレベル、特に暗号的に確認されていない否認を必要とするクライアントは、PARと組み合わせて[RFC9101]で定義されているJWTベースの要求オブジェクトを使用することができます。
PAR allows the authorization server to authenticate the client before any user interaction happens. The increased confidence in the identity of the client during the authorization process allows the authorization server to refuse illegitimate requests much earlier in the process, which can prevent attempts to spoof clients or otherwise tamper with or misuse an authorization request.
PAR許可サーバーは、ユーザーの対話が発生する前にクライアントを認証できます。許可プロセス中のクライアントの識別情報に対する信頼性の向上により、許可サーバーはプロセスの違法な要求を拒否することができ、それはクライアントのスプロードまたはその他の方法では承認要求を誤用または誤用することを試みることができます。
Note that HTTP "POST" requests to the authorization endpoint via the user agent, as described in Section 3.1 of [RFC6749] and Section 3.1.2.1 of [OIDC], could also be used to cope with the request size limitations described above. However, it's only optional per [RFC6749], and, even when supported, it is a viable option for conventional web applications but is prohibitively difficult to use with installed mobile applications. As described in [RFC8252], those apps use platform-specific APIs to open the authorization request URI in the system browser. When a mobile app launches a browser, however, the resultant initial request is constrained to use the "GET" method. Using "POST" for the authorization request would require the app to first direct the browser to open a URI that the app controls via "GET" while somehow conveying the sizable authorization request payload and then having the resultant response contain the content and script to initiate a cross-site form "POST" towards the authorization server. PAR is simpler to use and has additional security benefits, as described above.
[RFC6749]のセクション3.1の[OIDC]のセクション3.1.2.1で説明されているように、ユーザエージェントを介したhttp "post"は、上記の要求サイズの制限に対処するために使用することもできます。ただし、[RFC6749]ごとにオプションで、サポートされている場合でも、従来のWebアプリケーションの実行可能なオプションですが、インストールされているモバイルアプリケーションでは使用できません。 [RFC8252]に記載されているように、これらのアプリはシステムブラウザで許可要求URIを開くためにプラットフォーム固有のAPIを使用します。しかしながら、モバイルアプリがブラウザを起動すると、結果として生じる初期要求は「get」メソッドを使用するように制約される。認証要求の「POST」を使用すると、Appが「get」を介してコントロールするURIを開くためにアプリが最初にURIを開く必要があり、どういうわけか開始された応答にコンテンツとスクリプトが含まれています。承認サーバーに向かって「POST」を横断します。上記のように、PARは使用が簡単であり、追加のセキュリティ上の利点があります。
In conventional OAuth 2.0, a client typically initiates an authorization request by directing the user agent to make an HTTP request like the following to the authorization server's authorization endpoint (extra line breaks and indentation for display purposes only):
従来のOAuth 2.0では、クライアントは通常、ユーザエージェントに次のようなHTTPリクエストを承認サーバの許可エンドポイントに設定することを指示することで、許可要求を開始します（余分なラインブレイクと表示目的のためのインデントのみ）。
GET /authorize?response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: as.example.com
Such a request could instead be pushed directly to the authorization server by the client with a "POST" request to the PAR endpoint as illustrated in the following example (extra line breaks and spaces for display purposes only). The client can authenticate (e.g., using JWT client assertion-based authentication as shown) because the request is made directly to the authorization server.
このような要求は、次の例（表示目的のための追加のラインブレークとスペースのみ）のように、クライアントによってクライアントによって承認サーバーに直接プッシュされます。クライアントは、要求が許可サーバーに直接行われるため、（例えば、図示のようにJWT Assertionベースの認証を使用して）認証できます。
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
&response_type=code &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA
＆response_type=コード＆CLIENT_ID=CLIENT1234＆状態=duk681S8n00GsJpe7n9boxdzen＆REDIRECT_URI=HTTPS％3A％2F％2Fclient.example.org％2Fcb＆client_assertion_type=URN％3Aietf％3Aparams％3Aoauth％3Aclientアサーション型％3Ajwtベアラ＆client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTElFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ。IGW8QRPAWRNPDGOWGRMJUMLBM WBLJEIYWQWUU-YWGVVUFL_0SQJFTNS3BZJIRP0BV9RRG-3EI1KSH0KQ1CWVZA.
The authorization server responds with a request URI:
許可サーバーはリクエストURIで応答します。
HTTP/1.1 201 Created
Cache-Control: no-cache, no-store
Content-Type: application/json
{
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90
}
The client uses the request URI value to create the subsequent authorization request by directing the user agent to make an HTTP request to the authorization server's authorization endpoint like the following (extra line breaks and indentation for display purposes only):
クライアントは、要求URI値を使用して、次のように承認サーバーの許可エンドポイントにHTTPリクエストを作成するようにユーザーエージェントに依頼されて、次の許可要求を作成します（余分なラインブレークと表示目的のみのインデントのみ）。
GET /authorize?client_id=CLIENT1234
&request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: as.example.com
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "token endpoint", and "client" defined by "The OAuth 2.0 Authorization Framework" [RFC6749].
この仕様では、「アクセストークン」、「承認サーバ」、「承認エンドポイント」、「承認要求」、「トークンエンドポイント」、「TOKEN ENDPOINT」、「クライアント」とを使用しています[RFC6749]。
The pushed authorization request endpoint is an HTTP API at the authorization server that accepts HTTP "POST" requests with parameters in the HTTP request message body using the "application/x-www-form-urlencoded" format. This format has a character encoding of UTF-8, as described in Appendix B of [RFC6749]. The PAR endpoint URL MUST use the "https" scheme.
プッシュされた許可要求エンドポイントは、 "Application / X-www-www-urlencoded"フォーマットを使用して、HTTP要求メッセージ本文のパラメータを使用してHTTP "POST"要求を受け付ける認可サーバーのHTTP APIです。このフォーマットは、[RFC6749]の付録Bで説明されているように、UTF-8の文字エンコードを持ちます。PARエンドポイントURLは "HTTPS"スキームを使用する必要があります。
Authorization servers supporting PAR SHOULD include the URL of their pushed authorization request endpoint in their authorization server metadata document [RFC8414] using the "pushed_authorization_request_endpoint" parameter as defined in Section 5.
PARをサポートする承認サーバーには、承認サーバーメタデータドキュメント[RFC8414]のプッシュされた許可要求エンドポイントのURLを、セクション5で定義されているように、「PUSHED_AUTHORIZATION_REQUEST_ENDPOINT」パラメーターを使用する必要があります。
The endpoint accepts the authorization request parameters defined in [RFC6749] for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint. Some examples of such extensions include Proof Key for Code Exchange (PKCE) [RFC7636], Resource Indicators [RFC8707], and OpenID Connect (OIDC) [OIDC]. The endpoint MAY also support sending the set of authorization request parameters as a Request Object according to [RFC9101] and Section 3 of this document.
エンドポイントは、承認エンドポイントの場合は[RFC6749]で定義されている認証要求パラメータと、許可エンドポイントに定義されているすべての該当する拡張機能を受け入れます。そのような拡張のいくつかの例には、コード交換（PKCE）[RFC7636]、リソースインジケータ[RFC8707]、およびOpenID Connect（OIDC）[OIDC]のプルーフキーがあります。エンドポイントは、このドキュメントの[RFC9101]およびセクション3に従って、承認要求パラメータのセットを要求オブジェクトとして送信することもできます。
The rules for client authentication as defined in [RFC6749] for token endpoint requests, including the applicable authentication methods, apply for the PAR endpoint as well. If applicable, the "token_endpoint_auth_method" client metadata parameter [RFC7591] indicates the registered authentication method for the client to use when making direct requests to the authorization server, including requests to the PAR endpoint. Similarly, the "token_endpoint_auth_methods_supported" authorization server metadata [RFC8414] parameter lists client authentication methods supported by the authorization server when accepting direct requests from clients, including requests to the PAR endpoint.
適用可能な認証方法を含むトークンエンドポイント要求については、[RFC6749]で定義されているクライアント認証の規則も同様にパー間エンドポイントに適用されます。該当する場合、 "token_endpoint_auth_method"クライアントメタデータパラメータ[RFC7591]は、PARエンドポイントへの要求を含む、許可サーバーに直接要求するときに使用するクライアントの登録認証方法を示します。同様に、 "token_endpoint_auth_methods_supported"承認サーバーメタデータ[RFC8414]パラメータは、areエンドポイントへの要求を含む、クライアントからの直接要求を受け入れるときに、許可サーバーによってサポートされているクライアント認証方法をリストします。
Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in Section 2.2 of [RFC7523] with "private_key_jwt" or "client_secret_jwt" authentication method names per Section 9 of [OIDC]). To address that ambiguity, the issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.
歴史的な理由から、JWTクライアントアサーションベースの認証（RFC7523のセクション2.2で定義されている）（RFC7523のセクション2.2で "Private_Key_JWT"または "client_secret_jwt"認証方法名が[OIDCのセクション2.2で定義されています）の適切な視聴者の価値があります。]）。その曖昧さに対処するために、[RFC8414]に従って認可サーバの発行者識別子URLを視聴者の値として使用する必要があります。相互運用性を促進するために、許可サーバーは、その発行者識別子、トークンエンドポイントURL、または承認要求ENDPOINT URLを対象としている値として識別する必要があります。
A client sends the parameters that comprise an authorization request directly to the PAR endpoint. A typical parameter set might include: "client_id", "response_type", "redirect_uri", "scope", "state", "code_challenge", and "code_challenge_method" as shown in the example below. However, the pushed authorization request can be composed of any of the parameters applicable for use at the authorization endpoint, including those defined in [RFC6749] as well as all applicable extensions. The "request_uri" authorization request parameter is one exception, and it MUST NOT be provided.
クライアントは、承認要求を直接PARエンドポイントに直接含むパラメータを送信します。典型的なパラメータセットには、以下の例に示すように、「client_id」、「response_type」、「redirect_type」、「scope」、「状態」、「code_challenge」、および「code_challenge_method」が含まれる場合があります。ただし、プッシュされた許可要求は、[RFC6749]で定義されているものと適用可能なすべての拡張子を含む、許可エンドポイントでの使用に適用されるパラメータのいずれかで構成できます。"request_uri"承認要求パラメータは1つの例外であり、それを提供してはいけません。
The request also includes, as appropriate for the given client, any additional parameters necessary for client authentication (e.g., "client_secret" or "client_assertion" and "client_assertion_type"). Such parameters are defined and registered for use at the token endpoint but are applicable only for client authentication. When present in a pushed authorization request, they are relied upon only for client authentication and are not germane to the authorization request itself. Any token endpoint parameters that are not related to client authentication have no defined meaning for a pushed authorization request. The "client_id" parameter is defined with the same semantics for both authorization requests and requests to the token endpoint; as a required authorization request parameter, it is similarly required in a pushed authorization request.
この要求には、特定のクライアントに適しているように、クライアント認証に必要な追加のパラメータ（例えば、「Client_Secret」または「Client_Assertion」および「client_assertion_type」）が含まれます。そのようなパラメータは、トークンエンドポイントで使用するために定義され登録されますが、クライアント認証にのみ適用されます。プッシュされた許可要求に存在する場合、それらはクライアント認証のためだけに頼りにされ、許可要求自体へのゲルマンではありません。クライアント認証に関連しないトークンエンドポイントパラメータは、プッシュされた許可要求に対して定義された意味はありません。"client_id"パラメータは、承認要求とトークンエンドポイントへの要求の両方について同じ意味で定義されています。必要な許可要求パラメータとして、プッシュされた許可要求でも同様に要求されます。
The client constructs the message body of an HTTP "POST" request with parameters formatted with "x-www-form-urlencoded" using a character encoding of UTF-8, as described in Appendix B of [RFC6749]. If applicable, the client also adds its authentication credentials to the request header or the request body using the same rules as for token endpoint requests.
[RFC6749]の付録Bの付録Bで説明されているように、UTF-8の文字エンコードを使用して、「X-WWW - URLENCODED」でフォーマットされたパラメータを使用してHTTP "POST"要求のメッセージ本文を構築します。該当する場合、クライアントはトークンエンドポイント要求と同じ規則を使用して、要求ヘッダーまたは要求本文に認証資格情報を追加します。
This is illustrated by the following example (extra line breaks in the message body for display purposes only):
これは、次の例で説明されています（表示目的のためのメッセージ本文の内訳のみ）。
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge_method=S256&scope=account-information &client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 GQ
response_type=コード＆状態=af0ifjsldkj＆CLIENT_ID=s6BhdRkqt3＆REDIRECT_URI=HTTPS％3A％2F％2Fclient.example.org％2Fcb＆code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U＆code_challenge_method=S256＆スコープ=アカウント情報＆client_assertion_type=URN％3Aietf％3Aparams％3Aoauth％3Aclient-assertion-型％3Ajwtベアラ＆client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrhTWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6sef5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-KdTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8WyeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJERWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6GQ
The authorization server MUST process the request as follows:
許可サーバーは次のように要求を処理する必要があります。
1. Authenticate the client in the same way as at the token endpoint (Section 2.3 of [RFC6749]).
1. トークンエンドポイントと同じ方法でクライアントを認証します（[RFC6749]のセクション2.3）。
2. Reject the request if the "request_uri" authorization request parameter is provided.
2. "request_uri"承認要求パラメータが提供されている場合、要求を拒否してください。
3. Validate the pushed request as it would an authorization request sent to the authorization endpoint. For example, the authorization server checks whether the redirect URI matches one of the redirect URIs configured for the client and also checks whether the client is authorized for the scope for which it is requesting access. This validation allows the authorization server to refuse unauthorized or fraudulent requests early. The authorization server MAY omit validation steps that it is unable to perform when processing the pushed request; however, such checks MUST then be performed when processing the authorization request at the authorization endpoint.
3. 許可エンドポイントに送信要求が送信されるため、プッシュされた要求を検証します。たとえば、承認サーバーは、リダイレクトURIがクライアントに設定されているリダイレクトURIの1つと一致するかどうかを確認し、クライアントがアクセスを要求しているスコープに対してクライアントが許可されているかどうかを確認します。この検証により、許可サーバーは不正または不正な要求を早期に拒否できます。許可サーバーは、プッシュされた要求を処理するときに実行できないことが検証手順を省略することがあります。ただし、そのようなチェックは、許可エンドポイントで許可要求を処理するときに実行されなければなりません。
The authorization server MAY allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pushed authorization request. Described in more detail in Section 2.4, this is possible since, in contrast to [RFC6749], this specification gives the authorization server the ability to authenticate clients and validate client requests before the actual authorization request is performed.
認証サーバーでは、認証資格情報をクライアントが許可されていると、プッシュされた許可要求ごとに承認要求リダイレクトURIを確立できます。セクション2.4でより詳細に説明されています。これは、[RFC6749]とは対照的に、この仕様に認証サーバーにクライアントを認証し、実際の許可要求が実行される前にクライアント要求を検証する機能を示しているためです。
If the verification is successful, the server MUST generate a request URI and provide it in the response with a "201" HTTP status code. The following parameters are included as top-level members in the message body of the HTTP response using the "application/json" media type as defined by [RFC8259].
検証が成功した場合、サーバーは要求URIを生成し、「201」HTTPステータスコードを使用して応答に提供する必要があります。[RFC8259]で定義されている「アプリケーション/ JSON」メディアタイプを使用して、HTTPレスポンスのメッセージ本文の最上位メンバーとして次のパラメータが含まれています。
request_uri The request URI corresponding to the authorization request posted. This URI is a single-use reference to the respective request data in the subsequent authorization request. The way the authorization process obtains the authorization request data is at the discretion of the authorization server and is out of scope of this specification. There is no need to make the authorization request data available to other parties via this URI.
request_uri承認要求に対応する要求URI。このURIは、後続の許可要求におけるそれぞれの要求データへの単一用参照である。許可プロセスが許可要求データを取得する方法は、許可サーバーの裁量にあり、この仕様の範囲外です。このURIを介して他の当事者で認可要求データを利用できるようにする必要はありません。
expires_in A JSON number that represents the lifetime of the request URI in seconds as a positive integer. The request URI lifetime is at the discretion of the authorization server but will typically be relatively short (e.g., between 5 and 600 seconds).
expires_in要求URIの有効期間を正の整数として表すJSON番号。要求URI寿命は、許可サーバの裁量にあるが、通常は比較的短い（例えば、5~600秒）。
The format of the "request_uri" value is at the discretion of the authorization server, but it MUST contain some part generated using a cryptographically strong pseudorandom algorithm such that it is computationally infeasible to predict or guess a valid value (see Section 10.10 of [RFC6749] for specifics). The authorization server MAY construct the "request_uri" value using the form "urn:ietf:params:oauth:request_uri:<reference-value>" with "<reference-value>" as the random part of the URI that references the respective authorization request data.
"request_uri"値の形式は許可サーバーの裁量にありますが、有効な値を予測または推測することが計算できるように、暗号的に強い疑似乱数アルゴリズムを使用して生成されたいくつかの部分を含める必要があります（[RFC6749のセクション10.10を参照）。]詳細）。）。許可サーバーは、「<reference-value>」を使用して "request_uri"値を構築することができ、それぞれの許可を参照するURIのランダムな部分として "<reference-value>"で "request_uri：<基準値>"データを要求します。
The "request_uri" value MUST be bound to the client that posted the authorization request.
承認要求を投稿したクライアントに「request_uri」の値をバインドする必要があります。
The following is an example of such a response:
以下はそのような応答の例です。
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"request_uri":
"urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
"expires_in": 60
}
The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of [RFC6749] using the appropriate error code from therein or from Section 4.1.2.1 of [RFC6749]. In those cases where Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an error back to the requesting client and hence doesn't define an error code (for example, when the request fails due to a missing, invalid, or mismatching redirection URI), the "invalid_request" error code can be used as the default error code. Error codes defined by the OAuth extension can also be used when such an extension is involved in the initial processing of the authorization request that was pushed. Since initial processing of the pushed authorization request does not involve resource owner interaction, error codes related to user interaction, such as "consent_required" defined by [OIDC], are never returned.
承認サーバーは、[RFC6749]の[RFC6749]の[RFC6749]から、[RFC6749]の[RFC6749]の[4.2]の[RFC6749]の[4.1.2.1]の[4.1.2.1]の[RFC6749]のエラー応答と同じ形式でエラー応答を返します。[RFC6749]のセクション4.1.2.1が要求側クライアントにエラーを伴う自動リダイレクトを禁止し、エラーコードを定義していない場合（たとえば、不足、無効、または不一致のリダイレクトのために要求が失敗した場合など）。URI）、「Invalid_Request」エラーコードをデフォルトのエラーコードとして使用できます。このような拡張子がプッシュされた承認要求の初期処理に含まれる場合には、OAuth拡張機能によって定義されたエラーコードも使用できます。プッシュされた許可要求の初期処理では、リソース所有者の対話が含まれていないため、[OIDC]によって定義された「同意書」などのユーザーの操作に関連するエラーコードが返されません。
If the client is required to use signed Request Objects, by either the authorization server or the client policy (see [RFC9101], Section 10.5), the authorization server MUST only accept requests complying with the definition given in Section 3 and MUST refuse any other request with HTTP status code 400 and error code "invalid_request".
承認サーバーまたはクライアントポリシー（[RFC9101]、セクション10.5を参照）のどちらかで署名付き要求オブジェクトを使用する必要がある場合、認証サーバーはセクション3に記載されている定義に準拠した要求のみを受け入れる必要があります。HTTPステータスコード400およびエラーコード「invalid_request」を要求します。
In addition to the above, the PAR endpoint can also make use of the following HTTP status codes:
上記に加えて、PARエンドポイントは次のHTTPステータスコードを使用することもできます。
405: If the request did not use the "POST" method, the authorization server responds with an HTTP 405 (Method Not Allowed) status code.
405：要求が「POST」メソッドを使用しなかった場合、許可サーバーはHTTP 405（メソッドは許可されていない）ステータスコードで応答します。
413: If the request size was beyond the upper bound that the authorization server allows, the authorization server responds with an HTTP 413 (Payload Too Large) status code.
413：要求サイズが許可サーバーが許可する上限を超えていた場合、許可サーバーはHTTP 413（ペイロードすぎる）ステータスコードで応答します。
429: If the number of requests from a client during a particular time period exceeds the number the authorization server allows, the authorization server responds with an HTTP 429 (Too Many Requests) status code.
429：特定の期間中のクライアントからの要求数が許可サーバーが許可する番号を超える場合、許可サーバーはHTTP 429（要求が多すぎる）ステータスコードで応答します。
The following is an example of an error response from the PAR endpoint:
以下は、PARエンドポイントからのエラー応答の例です。
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"error": "invalid_request",
"error_description":
"The redirect_uri is not valid for the given client"
}
OAuth 2.0 [RFC6749] allows clients to use unregistered "redirect_uri" values in certain circumstances or for the authorization server to apply its own matching semantics to the "redirect_uri" value presented by the client at the authorization endpoint. However, the OAuth security BCP [OAUTH-SECURITY-TOPICS] as well as the OAuth 2.1 specification [OAUTH-V2] require an authorization server to exactly match the "redirect_uri" parameter against the set of redirect URIs previously established for a particular client. This is a means for early detection of client impersonation attempts and prevents token leakage and open redirection. As a downside, this can make client management more cumbersome since the redirect URI is typically the most volatile part of a client policy.
OAuth 2.0 [RFC6749]クライアントは、特定の状況で未登録の「Redirect_URI」の値を使用するか、または許可サーバーには、クライアントによって提示された「Redirect_URI」の値に独自のマッチングセマンティクスを適用することができます。ただし、OAuthセキュリティBCP [OAUTH-Security-Topics]とOAuth 2.1仕様[OAUTH-V2]は、特定のクライアントに対して以前に確立されたリダイレクトURIのセットに対して「Redirect_URI」パラメータを正確に一致させるように承認サーバーを必要とします。これは、クライアントの偽装の試みを早期に検出するための手段であり、トークンの漏洩とオープンリダイレクトを防ぎます。下側として、リダイレクトURIは通常クライアントポリシーの最も揮発性の一部であるため、これはクライアント管理をより面倒にすることができます。
The exact matching requirement MAY be relaxed when using PAR for clients that have established authentication credentials with the authorization server. This is possible since, in contrast to a conventional authorization request, the authorization server authenticates the client before the authorization process starts and thus ensures it is interacting with the legitimate client. The authorization server MAY allow such clients to specify "redirect_uri" values that were not previously registered with the authorization server. This will give the client more flexibility (e.g., to mint distinct "redirect_uri" values per authorization server at runtime) and can simplify client management. It is at the discretion of the authorization server to apply restrictions on supplied "redirect_uri" values, e.g., the authorization server MAY require a certain URI prefix or allow only a query parameter to vary at runtime.
認証サーバーを使用して認証資格情報を確立したクライアントに対してPARを使用する場合は、完全に一致する要件を緩和することができます。これは、従来の許可要求とは対照的に、許可プロセスが開始される前にクライアントを認証し、したがって正規クライアントと対話することを保証するので、これは可能である。許可サーバーは、そのようなクライアントは、以前に許可サーバーに登録されていなかった「Redirect_URI」の値を指定することを可能にします。これにより、クライアントには、実行時に認証サーバーごとに異なる「Redirect_URI」の値がより柔軟になり、クライアント管理を簡素化できます。指定された「Redirect_URI」値、例えば、許可サーバーの制限を適用することは、特定のURIプレフィックスを必要とするか、または実行時にクエリパラメータのみを許可することができます。
Note: The ability to set up transaction-specific redirect URIs is also useful in situations where client IDs and corresponding credentials and policies are managed by a trusted third party, e.g., via client certificates containing client permissions. Such an externally managed client could interact with an authorization server trusting the respective third party without the need for an additional registration step.
注：トランザクション固有のリダイレクトURIを設定する機能は、クライアントIDと対応する信任状およびポリシーが、クライアントアクセス許可を含むクライアント証明書を介して、信頼できる第三者によって管理されている状況でも役立ちます。そのような外部管理クライアントは、追加の登録ステップを必要とせずにそれぞれの第三者を信頼する許可サーバと対話することができる。
Clients MAY use the "request" parameter as defined in JAR [RFC9101] to push a Request Object JWT to the authorization server. The rules for processing, signing, and encryption of the Request Object as defined in JAR [RFC9101] apply. Request parameters required by a given client authentication method are included in the "application/ x-www-form-urlencoded" request directly and are the only parameters other than "request" in the form body (e.g., mutual TLS client authentication [RFC8705] uses the "client_id" HTTP request parameter, while JWT assertion-based client authentication [RFC7523] uses "client_assertion" and "client_assertion_type"). All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request.
クライアントは、JAR [RFC9101]で定義されている「要求」パラメータを使用して、要求オブジェクトJWTを許可サーバーにプッシュします。JAR [RFC9101]で定義されている要求オブジェクトの処理、署名、および暗号化の規則が適用されます。特定のクライアント認証方法によって要求される要求パラメータは、「アプリケーション/ X-WWW-www-urlencoded」要求に直接含み、ボディのフォームボディの「要求」以外のパラメータ（例えば、Pluotial TLSクライアント認証[RFC8705]）に含まれています。「client_id」http要求パラメータを使用しますが、JWTアサーションベースのクライアント認証[RFC7523]は "client_assertion"と "client_assertion_type"を使用します。他のすべての要求パラメータ、すなわち許可要求自体に関するものは、承認要求を表すJWTの特許請求の範囲として現れる必要があります。
The following is an example of a pushed authorization request using a signed Request Object with the same authorization request payload as the example in Section 2.1. The client is authenticated with JWT client assertion-based authentication [RFC7523] (extra line breaks and spaces for display purposes only):
以下は、セクション2.1の例として同じ承認要求ペイロードを持つ署名付き要求オブジェクトを使用したプッシュされた許可要求の例です。クライアントはJWTクライアントアサーションベースの認証[RFC7523]で認証されています（表示目的のための追加のラインブレークとスペースのみ）。
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 GQ &request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJleHAiOj E2MjU4Njk2NzcsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwiY2xpZW50X2lkIjoiczZ CaGRSa3F0MyIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUu b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjODNhY2M0aDBjOXc2RV NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI 6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5 BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA 6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS _5y54dVLQPA1jKYx-fxbYSG7dp2fw &client_id=s6BhdRkqt3
client_assertion_type = URN％3Aietf％3Aparams％3Aoauth％3Aclientアサーション型％3Ajwtベアラ＆client_assertion = eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 GQ＆リクエスト= eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0。 eyJpc3MiOiJzNkJoZ FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJleHAiOj E2MjU4Njk2NzcsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwiY2xpZW50X2lkIjoiczZ CaGRSa3F0MyIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUu b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjOD NhY2M0aDBjOXc2RV NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI 6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5 BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA -6- WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS _5y54dVLQPA1jKYx-fxbYSG7dp2fw＆CLIENT_ID = s6BhdRkqt3
The authorization server MUST take the following steps beyond the processing rules defined in Section 2.1:
承認サーバーは、セクション2.1で定義されている処理規則を超えて次の手順を実行する必要があります。
1. If applicable, decrypt the Request Object as specified in JAR [RFC9101], Section 6.1.
1. 該当する場合は、JAR [RFC9101]、6.1で指定されている要求オブジェクトを復号化します。
2. Validate the Request Object signature as specified in JAR [RFC9101], Section 6.2.
2. JAR [RFC9101]、セクション6.2で指定されている要求オブジェクト署名を検証します。
3. If the client has authentication credentials established with the authorization server, reject the request if the authenticated "client_id" does not match the "client_id" claim in the Request Object. Additionally, requiring the "iss" claim to match the "client_id" is at the discretion of the authorization server.
3. クライアントが認証サーバーで認証資格情報を確立している場合は、認証された「client_id」が要求オブジェクトの「client_id」クレームと一致しない場合は、要求を拒否してください。さらに、「ISS」クレームを必要とする「client_id」と一致させることは、許可サーバーの裁量にあります。
The following RSA key pair, represented in JSON Web Key (JWK) format [RFC7517], can be used to validate or recreate the Request Object signature in the above example (extra line breaks and indentation within values for display purposes only):
上記の例では、JSON Webキー（JWK）形式[RFC7517]に表される次のRSAキーペアを使用して、上記の例では要求オブジェクトの署名を検証または再作成することができます（表示目的の場合にのみ値内の追加のラインブレークとインデント）。
{
"kty": "RSA",
"kid":"k2bdc",
"n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE
5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa
aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj
dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL
L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG
sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
"e": "AQAB",
"d": "LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPlXOL
zjqxXuQc8MdMqRQZTnAwgd7HH0B6gncrruV3NewI-XQV0ckldTjqNfOTz1V
Rs-jE-57KAXI3YBIhu-_0YpIDzdk_wBuAk661Svn0GsPQe7m9DoxdzenQu9
O_soewUhlPzRrTH0EeIqYI715rwI3TYaSzoWBmEPD2fICyj18FF0MPy_SQz
k3noVUUIzfzLnnJiWy_p63QBCMqjRoSHHdMnI4z9iVpIwJWQ3jO5n_2lC2-
cSgwjmKsFzDBbQNJc7qMG1N6EssJUwgGJxz1eAUFf0w4YAQ",
"qi": "J-mG0swR4FTy3atrcQ7dd0hhYn1E9QndN-
-sDG4EQO0RnFj6wIefCvwIc4
7hCtVeFnCTPYJNc_JyV-mU-9vlzS5GSNuyR5qdpsMZXUMpEvQcwKt23ffPZ
YGaqfKyEesmf_Wi8fFcE68H9REQjnniKrXm7w2-IuG_IrVJA9Ox-uU",
"q": "4hlMYAGa0dvogdK1jnxQ7J_Lqpqi99e-AeoFvoYpMPhthChTzwFZO9lQmUo
BpMqVQTws_s7vWGmt7ZAB3ywkurf0pV7BD0fweJiUzrWk4KJjxtmP_auuxr
jvm3s2FUGn6f0wRY9Z8Hj9A7C72DnYCjuZiJQMYCWDsZ8-d-L1a-s",
"p": "5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3bSEL
5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5
LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE",
"dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19
zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k",
"dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe
ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE"
}
The client uses the "request_uri" value returned by the authorization server to build an authorization request as defined in [RFC9101]. This is shown in the following example where the client directs the user agent to make the following HTTP request (extra line breaks and indentation for display purposes only):
クライアントは、承認サーバーによって返された "request_uri"値を使用して、[RFC9101]で定義されているように許可要求を作成します。これは、クライアントが次の例で次のHTTPリクエストを行うように指示する次の例に示されています（例示的なラインブレークと表示目的のためのインデントのみ）。
GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
Host: as.example.com
Since parts of the authorization request content, e.g., the "code_challenge" parameter value, are unique to a particular authorization request, the client MUST only use a "request_uri" value once. Authorization servers SHOULD treat "request_uri" values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired "request_uri" MUST be rejected as invalid.
許可要求のコンテンツ、例えば「Code_Challenge」パラメータ値は、特定の許可要求に固有のものであるため、クライアントは「request_uri」値のみを1回使用する必要があります。許可サーバーは、「Request_URI」の値をワンタイム使用として扱う必要がありますが、ユーザーエージェントをリロード/更新するユーザーによる重複要求を許可する場合があります。期限切れの "request_uri"は無効として拒否されなければなりません。
The authorization server MUST validate authorization requests arising from a pushed request as it would any other authorization request. The authorization server MAY omit validation steps that it performed when the request was pushed, provided that it can validate that the request was a pushed request and that the request or the authorization server's policy has not been modified in a way that would affect the outcome of the omitted steps.
許可サーバーは、他の許可要求としてプッシュされた要求から発生する許可要求を検証する必要があります。許可サーバーは、要求がプッシュされた要求であることが検証され、要求または許可サーバーのポリシーがの結果に影響を与えていないことを確認できるように、要求がプッシュされたときに実行された検証手順を省略することができます。省略されたステップ。
Authorization server policy MAY dictate, either globally or on a per-client basis, that PAR be the only means for a client to pass authorization request data. In this case, the authorization server will refuse, using the "invalid_request" error code, to process any request to the authorization endpoint that does not have a "request_uri" parameter with a value obtained from the PAR endpoint.
許可サーバーポリシーは、グローバルに、またはクライアントごとにかけますが、クライアントが許可要求データを渡すための唯一の手段となることがあります。この場合、承認サーバは、「Invalid_Request」エラーコードを使用して、PARエンドポイントから取得された値を持つ「request_uri」パラメータを持たない承認エンドポイントに任意の要求を処理することを拒否します。
Note: Authorization server and clients MAY use metadata as defined in Sections 5 and 6 to signal the desired behavior.
注意：許可サーバーとクライアントは、セクション5と6で定義されているメタデータを使用して、目的の動作を伝えます。
The following authorization server metadata parameters [RFC8414] are introduced to signal the server's capability and policy with respect to PAR.
次の許可サーバーメタデータパラメータ[RFC8414]は、PARに関してサーバーの機能とポリシーをシグナリングするために導入されます。
pushed_authorization_request_endpoint The URL of the pushed authorization request endpoint at which a client can post an authorization request to exchange for a "request_uri" value usable at the authorization server.
pushed_authorization_request_Endpoint承認サーバーで使用可能な "request_uri"値を交換するための許可要求を投稿できるプッシュされた許可要求エンドポイントのURL。
require_pushed_authorization_requests Boolean parameter indicating whether the authorization server accepts authorization request data only via PAR. If omitted, the default value is "false".
require_pushed_authorization_requests承認サーバーが権限要求データをPARを介してのみ受け入れるかどうかを示すBooleanパラメーター。省略した場合、デフォルト値は "false"です。
Note that the presence of "pushed_authorization_request_endpoint" is sufficient for a client to determine that it may use the PAR flow. A "request_uri" value obtained from the PAR endpoint is usable at the authorization endpoint regardless of other authorization server metadata such as "request_uri_parameter_supported" or "require_request_uri_registration" [OIDC.Disco].
「pushed_authorization_request_endpoint」の存在は、クライアントがPARフローを使用できると判断するのに十分です。PARエンドポイントから取得された「request_uri」値は、 "request_uri_parameter_supported"または "require_request_rerigistration" [oidc.disce]などの他の許可サーバーメタデータに関係なく、許可エンドポイントで使用できます。
The Dynamic Client Registration Protocol [RFC7591] defines an API for dynamically registering OAuth 2.0 client metadata with authorization servers. The metadata defined by [RFC7591], and registered extensions to it, also imply a general data model for clients that is useful for authorization server implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations will typically have some sort of user interface available for managing client configuration. The following client metadata parameter is introduced by this document to indicate whether pushed authorization requests are required for the given client.
動的クライアント登録プロトコル[RFC7591]は、OAuth 2.0クライアントメタデータを認可サーバーに動的に登録するためのAPIを定義します。[RFC7591]で定義されたメタデータとそれに登録された拡張機能は、ダイナミッククライアント登録プロトコルがプレイされていない場合でも、許可サーバーの実装に役立つクライアントの一般的なデータモデルを意味します。そのような実装は通常、クライアント構成を管理するためにある種のユーザインタフェースを有する。次のクライアントメタデータパラメータは、このドキュメントによって、指定されたクライアントにプッシュされた許可要求が必要かどうかを示すために紹介されます。
require_pushed_authorization_requests Boolean parameter indicating whether the only means of initiating an authorization request the client is allowed to use is PAR. If omitted, the default value is "false".
Require_Pushed_Authorization_requests booleanパラメータクライアントが使用できる承認要求を開始する手段がPARです。省略した場合、デフォルト値は "false"です。
An attacker could attempt to guess and replay a valid request URI value and try to impersonate the respective client. The authorization server MUST account for the considerations given in JAR [RFC9101], Section 10.2, clause (d) on request URI entropy.
攻撃者は有効な要求URI値を推測して再生し、それぞれのクライアントを偽装しようとします。許可サーバーは、要求URIエントロピーに関するJAR [RFC9101]、セクション10.2、句（D）に記載されている考慮事項を説明する必要があります。
An attacker could try to register a redirect URI pointing to a site under their control in order to obtain authorization codes or launch other attacks towards the user. The authorization server MUST only accept new redirect URIs in the pushed authorization request from authenticated clients.
攻撃者は、許可コードを取得するか、ユーザーに向かって他の攻撃を起動するために、コントロールの下でサイトを指すリダイレクトURIを登録しようとする可能性があります。認証サーバーは、認証されたクライアントからプッシュされた許可要求でのみ新しいリダイレクトURIを受け入れる必要があります。
An attacker could replay a request URI captured from a legitimate authorization request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use.
攻撃者は、正当な承認要求からキャプチャされた要求URIを再生することができます。そのような攻撃に対処するために、許可サーバーはリクエストURIを1回使用する必要があります。
The client policy might change between the lodging of the Request Object and the authorization request using a particular Request Object. Therefore, it is recommended that the authorization server check the request parameter against the client policy when processing the authorization request.
クライアントポリシーは、特定の要求オブジェクトを使用して、要求オブジェクトの宿泊施設と承認要求との間で変わる可能性があります。したがって、許可要求を処理するときに、許可サーバーがクライアントポリシーに対して要求パラメータを確認することをお勧めします。
An attacker could capture the request URI from one request and then substitute it into a different authorization request. For example, in the context of OpenID Connect, an attacker could replace a request URI asking for a high level of authentication assurance with one that requires a lower level of assurance. Clients SHOULD make use of PKCE [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" parameter [OIDC] in the pushed Request Object to prevent this attack.
攻撃者は1つの要求からリクエストURIをキャプチャしてから、それを別の許可要求に置き換えることができます。たとえば、OpenID Connectというコンテキストでは、攻撃者は、高レベルの認証保証を求めるリクエストURIを、より低いレベルの保証を必要とするものと置き換えることができます。クライアントは、この攻撃を防ぐために、プッシュされた要求オブジェクトのOIDC "Nonce"パラメータ[OIDC]をPKCE [RFC7636]、またはOIDC "Nonce"パラメーター[OIDC]を使用してください。
OAuth 2.0 is a complex and flexible framework with broad-ranging privacy implications due to its very nature of having one entity intermediate user authorization to data access between two other entities. The privacy considerations of all of OAuth are beyond the scope of this document, which only defines an alternative way of initiating one message sequence in the larger framework. However, using PAR may improve privacy by reducing the potential for inadvertent information disclosure since it passes the authorization request data directly between the client and authorization server over a secure connection in the message body of an HTTP request rather than in the query component of a URL that passes through the user agent in the clear.
OAuth 2.0は、他の2つのエンティティ間のデータアクセスに対する1つのエンティティ中間ユーザー認証を持つというその非常に性質のために、広範囲のプライバシーの影響を伴う複雑で柔軟なフレームワークです。OAuthのすべてのプライバシーに関する考慮事項はこの文書の範囲を超えています。これは、より大きなフレームワークで1つのメッセージシーケンスを開始するための代替方法を定義します。しかしながら、PARを使用すると、URLの照会コンポーネントではなく、HTTPリクエストのメッセージ本文で安全な接続を介してクライアントおよび許可サーバーの間で認証要求データを直接渡すため、不注意による情報開示の可能性を低下させることによってプライバシーを向上させることができる。それはクリアのユーザーエージェントを通過します。
IANA has registered the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Parameters] established by [RFC8414].
IANAは、[RFC8414]によって確立された[IANA.OAUTH.PARAMETERS]の「IANA.OAUTH.PARAMETERS」のレジストリに次の値を登録しました。
Metadata Name: "pushed_authorization_request_endpoint" Metadata Description: URL of the authorization server's pushed authorization request endpoint. Change Controller: IESG Specification Document(s): Section 5 of RFC 9126
メタデータ名： "pushed_authorization_request_endpoint"メタデータ説明：許可サーバーのプッシュされた許可要求エンドポイントのURL。変更コントローラ：IESG仕様書：RFC 9126のセクション5
Metadata Name: "require_pushed_authorization_requests" Metadata Description: Indicates whether the authorization server accepts authorization requests only via PAR. Change Controller: IESG Specification Document(s): Section 5 of RFC 9126
メタデータ名： "require_pushed_authorization_requests"メタデータ説明：承認サーバーがPARを介してのみ許可要求を受け入れるかどうかを示します。変更コントローラ：IESG仕様書：RFC 9126のセクション5
IANA has registered the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry of [IANA.OAuth.Parameters] established by [RFC7591].
IANAは、[RFC7591]によって確立された[IANA.OAUTH.PARAMETERS]の「OAUTHダイナミッククライアント登録メタデータ」レジストリに次の値を登録しました。
Client Metadata Name: "require_pushed_authorization_requests" Client Metadata Description: Indicates whether the client is required to use PAR to initiate authorization requests. Change Controller: IESG Specification Document(s): Section 6 of RFC 9126
クライアントメタデータ名： "require_pushed_authorization_requests"クライアントメタデータ説明：クライアントが許可要求を開始するためにクライアントを使用する必要があるかどうかを示します。変更コントローラ：IESG仕様書：RFC 9126のセクション6
IANA has registered the following value in the "OAuth URI" registry of [IANA.OAuth.Parameters] established by [RFC6755].
IANAは、[RFC6755]によって確立された[iana.oauth.parameters]の「OAuth URI」レジストリに次の値を登録しました。
URN: "urn:ietf:params:oauth:request_uri:"
Common Name: A URN Sub-Namespace for OAuth Request URIs.
Change Controller: IESG
Specification Document(s): Section 2.2 of RFC 9126
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>.
[RFC6749]ハードル、D.、ED。、「OAuth 2.0認証フレームワーク」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https：//www.rfc-editor.org/info/rfc6749>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[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>.
[RFC8414] Jones、M.、Sakimura、N.、J. Bradley、 "OAUTH 2.0認証サーバーメタデータ"、RFC 8414、DOI 10.17487 / RFC8414、2018年6月、<https：//www.rfc-editor.org/情報/ RFC8414>。
[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, <https://www.rfc-editor.org/info/rfc9101>.
[RFC9101]桜、N.、Bradley、J。、およびM. Jones、「OAuth 2.0承認フレームワーク：JWT担保付承認要求（JAR）」、RFC 9101、DOI 10.17487 / RFC9101、2021年8月、<https：//www.rfc-editor.org/info/rfc9101>。
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <http://www.iana.org/assignments/oauth-parameters>.
[iana.oauth.parameters] IANA、 "OAUTHパラメータ"、<http://www.iana.org/ashignments/oauth-parameters>。
[OAUTH-SECURITY-TOPICS] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-18, 13 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18>.
[OAuth-Security-Topics] Lodderstedt、T.、Bradley、J.、Labunets、A.、D. FETT、「OAuth 2.0セキュリティ最高の現在の練習」、進行中の作業、インターネットドラフト、ドラフトIETF-OAUTH-Security-Topics-18、2021年4月13日、<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-topics-topics-topics-topics-topics-
[OAUTH-V2] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet-Draft, draft-ietf-oauth-v2-1-03, 8 September 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-03>.
[OAUTH-V2]ハードル、D.、Parcki、A.、T.Lldderstedt、「OAuth 2.1承認フレームワーク」、進行中の作業、インターネットドラフト、ドラフト-IETF-OAUTH-V2-1-03,9 9月8日2021、<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-03>。
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OIDC] SAKIMURA、N.、Bradley、J.、Jones、M.、De Medeiros、B.、Mortimore、Mortimore、2014年11月11日、<http：// OpenID。net / specs / openid-connect-core-1_0.html>。
[OIDC.Disco] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/openid-connect-discovery-1_0.html>.
[OIDC.Disco] SAKIMURA、N.、Bradley、J.、Jones、M.、およびE.JAY、「OpenID Connect Discovery 1.0エラタセット1」、2014年11月、<http://openid.net/specs/OpenID-Connect-Discovery-1_0.html>。
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/info/rfc6755>.
[RFC6755] Campbell、B.およびH.Schofenig、「OAuthのIETF URNサブネームスペース」、RFC 6755、DOI 10.17487 / RFC6755、2012年10月、<https：//www.rfc-editor.org/info/rfc6755>。
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517] Jones、M.、 "JSON Webキー（JWK）"、RFC 7517、DOI 10.17487 / RFC7517、<https：//www.rfc-editor.org/info/rfc7517>。
[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/info/rfc7519>.
[RFC7519] Jones、M.、Bradley、J.、およびSAKIMURA、「JSON Webトークン（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https：//www.rfc-editor.org/ Info / RFC7519>。
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/info/rfc7523>.
[RFC7523] Jones、M.、Campbell、B、およびC. Mortimore、OAuth 2.0クライアント認証および承認基準の「JSON Webトークン（JWT）プロファイル」、RFC 7523、DOI 10.17487 / RFC7523、2015年5月、<https：//www.rfc-editor.org/info/rfc7523>。
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[RFC7591] Richer、J.、Ed。、Jones、M.、Bradley、J.、Machulak、M.、およびP. Hunt、 "OAuth 2.0ダイナミッククライアント登録プロトコル"、RFC 7591、DOI 10.17487 / RFC7591、2015年7月<https：//www.rfc-editor.org/info/rfc7591>。
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/info/rfc7636>.
[RFC7636] SAKIMURA、N.、ED。、Bradley、J.、およびN.Agarwal、「OAuth Public Clientによるコード交換のための証明キー」、RFC 7636、DOI 10.17487 / RFC7636、2015年9月、<HTTPS：// WWW.rfc-editor.org / info / rfc7636>。
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/info/rfc8252>.
[RFC8252] Denniss、W.およびJ.Bradley、「ネイティブアプリのためのOAuth 2.0」、BCP 212、RFC 8252、DOI 10.17487 / RFC8252、2017年10月、<https：//www.rfc-editor.org/info/rfc8252>。
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/info/rfc8705>.
[RFC8705]キャンベル、B.、Bradley、J.、Sakimura、N.、およびT.Lldderstedt、「OAuth 2.0 Mutual-TLSクライアント認証および証明書バインドアクセストークン」、RFC 8705、DOI 10.17487 / RFC8705、2020年2月、<https://www.rfc-editor.org/info/rfc8705>。
[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>.
[RFC8707]キャンベル、B.、Bradley、J.、およびH.Tschofenig、「OAuth 2.0のリソースインジケータ2.0」、RFC 8707、DOI 10.17487 / RFC8707、2020年2月、<https：//www.rfc-editor.org/情報/ RFC8707>。
Acknowledgements
謝辞
This specification is based on the work on Pushed Request Object (https://bitbucket.org/openid/fapi/src/master/ Financial_API_Pushed_Request_Object.md) conducted at the Financial-grade API Working Group at the OpenID Foundation. We would like to thank the members of the WG for their valuable contributions.
この仕様は、OpenID FoundationのFinancial Grade APIワーキンググループで実施されたプッシュ要求オブジェクト（https://bitbucket.org/openid/fapi/src/master/ financial_api_pushed_request_object.md）の作業に基づいています。私たちは彼らの貴重な貢献についてWGのメンバーに感謝します。
We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, Karsten Meyer zu Selhausen, Roman Danyliw, Meral Shirazipour, and Takahiko Kawasaki for their valuable feedback on this document.
vladimir dzhuvinov、アーロン・アーロン・パレッキ、ジャスティン・リッカー、ダニエル・フェット、Michael B.ジョーンズ、ジョセフ・ヘイニャン、ジョセフ・ヘイニャン、ジョセフ・ヘイニャン、マッジ・ハング・カルステン・マイヤー、マーサン・マイヤーズ・セルハウゼン、Meral Shirazipourこの文書についての貴重なフィードバックのための川崎貴彦。
Authors' Addresses
著者の住所
Torsten Lodderstedt yes.com
Torsten LodderStedt yes.com
Email: torsten@lodderstedt.net
Brian Campbell Ping Identity
Brian Campbell Ping Identity.
Email: bcampbell@pingidentity.com
Nat Sakimura NAT.Consulting
Nat Sakimura Nat.Consulting.
Email: nat@sakimura.org
Dave Tonge Moneyhub Financial Technology
Dave Tonge Tonehub Financial Technology.
Email: dave@tonge.org
Filip Skokan Auth0
Skokan Auth0をフィリップ
Email: panva.ip@gmail.com