[要約] RFC 9101は、OAuth 2.0認証フレームワークにおけるJWT-Secured Authorization Request (JAR)に関する文書です。このRFCの目的は、認証リクエストをJSON Web Token (JWT)で安全に署名し、オプションで暗号化する方法を定義することにあります。これにより、OAuth 2.0プロトコルのセキュリティを強化し、リクエストの改ざんを防ぎます。利用場面としては、Webアプリケーションやモバイルアプリケーションが安全に認証情報を交換する際に使用されます。関連するRFCには、RFC 6749（OAuth 2.0認証フレームワーク）、RFC 7519（JSON Web Token (JWT)）、RFC 7523（JWTプロファイルのOAuth 2.0クライアント認証とアサーション）などがあります。
Internet Engineering Task Force (IETF) N. Sakimura
Request for Comments: 9101 NAT.Consulting
Category: Standards Track J. Bradley
ISSN: 2070-1721 Yubico
M. Jones
Microsoft
August 2021
The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
OAuth 2.0承認フレームワーク：JWT保護済み承認要求（JAR）
Abstract
概要
The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.
RFC 6749に記載されているOAuth 2.0の許可要求は、クエリパラメータのシリアル化を利用します。つまり、許可要求パラメータは要求のURIでエンコードされ、Webブラウザなどのユーザーエージェントを介して送信されます。実装が容易な間は、a）ユーザーエージェントを介した通信は完全性が保護されていないことを意味し、したがってパラメータを汚染することができます.B）通信元は認証されず、C）ユーザーを介した通信エージェントを監視することができます。これらの弱点のために、プロトコルへのいくつかの攻撃が今後も前に置かれました。
This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.
この文書では、代わりにJSON Webトークン（JWT）にリクエストパラメータを送信する機能を紹介します。許可要求の機密性および機密性の特性が得られます。要求は値または参照によって送信できます。
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/rfc9101.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9101で入手できます。
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. Requirements Language
2. Terminology
2.1. Request Object
2.2. Request Object URI
3. Symbols and Abbreviated Terms
4. Request Object
5. Authorization Request
5.1. Passing a Request Object by Value
5.2. Passing a Request Object by Reference
5.2.1. URI Referencing the Request Object
5.2.2. Request Using the "request_uri" Request Parameter
5.2.3. Authorization Server Fetches Request Object
6. Validating JWT-Based Requests
6.1. JWE Encrypted Request Object
6.2. JWS-Signed Request Object
6.3. Request Parameter Assembly and Validation
7. Authorization Server Response
8. TLS Requirements
9. IANA Considerations
9.1. OAuth Parameters Registration
9.2. OAuth Authorization Server Metadata Registry
9.3. OAuth Dynamic Client Registration Metadata Registry
9.4. Media Type Registration
9.4.1. Registry Contents
10. Security Considerations
10.1. Choice of Algorithms
10.2. Request Source Authentication
10.3. Explicit Endpoints
10.4. Risks Associated with request_uri
10.4.1. DDoS Attack on the Authorization Server
10.4.2. Request URI Rewrite
10.5. Downgrade Attack
10.6. TLS Security Considerations
10.7. Parameter Mismatches
10.8. Cross-JWT Confusion
11. Privacy Considerations
11.1. Collection Limitation
11.2. Disclosure Limitation
11.2.1. Request Disclosure
11.2.2. Tracking Using Request Object URI
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses
The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization and is typically sent through user agents such as web browsers.
OAuth 2.0 [RFC6749]の承認要求は、クエリパラメータのシリアル化を利用し、通常、Webブラウザなどのユーザーエージェントを介して送信されます。
For example, the parameters "response_type", "client_id", "state", and "redirect_uri" are encoded in the URI of the request:
たとえば、パラメータ "response_type"、 "client_id"、 "state"、および "redirect_uri"は、リクエストのURIでエンコードされています。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
While it is easy to implement, the encoding in the URI does not allow application-layer security to be used to provide confidentiality and integrity protection. While TLS is used to offer communication security between the client and the user agent as well as the user agent and the authorization server, TLS sessions are terminated in the user agent. In addition, TLS sessions may be terminated prematurely at some middlebox (such as a load balancer).
実装が簡単な間、URIのエンコーディングは、アプリケーション層のセキュリティを使用して機密性と整合性保護を提供することはできません。TLSは、クライアントとユーザーエージェントとの間で通信セキュリティを提供するために使用されていますが、ユーザーエージェントと認証サーバーだけでなく、TLSセッションはユーザーエージェントで終了します。さらに、TLSセッションはいくつかのミドルボックス（ロードバランサなど）で時期尚早に終了することがあります。
As a result, the authorization request of [RFC6749] has shortcomings in that:
その結果、[RFC6749]の許可要求はそのほとりがあります。
(a) the communication through the user agents is not integrity protected, and thus, the parameters can be tainted (integrity protection failure);
(a) ユーザーエージェントを介した通信は完全性保護されていないため、パラメータを汚染することができます（整合性保護障害）。
(b) the source of the communication is not authenticated (source authentication failure);
(b) 通信元は認証されていません（ソース認証失敗）。
(c) the communication through the user agents can be monitored (containment/confidentiality failure).
(c) ユーザーエージェントを介した通信は監視できます（包含/機密性の失敗）。
Due to these inherent weaknesses, several attacks against the protocol, such as redirection URI rewriting, have been identified.
これらの固有の弱点のために、リダイレクトURIの書き換えなどのプロトコルに対するいくつかの攻撃が特定されています。
The use of application-layer security mitigates these issues.
アプリケーションレイヤセキュリティの使用はこれらの問題を軽減します。
The use of application-layer security allows requests to be prepared by a trusted third party so that a client application cannot request more permissions than previously agreed upon.
アプリケーション層のセキュリティの使用により、クライアントアプリケーションが以前に合意されたよりも多くの権限を要求することができないように、信頼できる第三者によって要求を準備することができます。
Furthermore, passing the request by reference allows the reduction of over-the-wire overhead.
さらに、リクエストを参照により渡すことで、ワイヤーのオーバーヘッドを削減できます。
The JWT [RFC7519] encoding has been chosen because of:
JWT [RFC7519]エンコーディングは次のように選択されています。
(1) its close relationship with JSON, which is used as OAuth's response format
(1) OAuthの応答フォーマットとして使用されるJSONとの密接な関係
(2) its developer friendliness due to its textual nature
(2) そのテキストの自然のためにその開発者の親しみやすさ
(3) its relative compactness compared to XML
(3) XMLと比較したその相対的なコンパクト性
(4) its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]
(4) 提案された規格としてのその開発状況、関連する署名および暗号化方法とともに[RFC7515] [RFC7516]
(5) the relative ease of JWS and JWE compared to XML Signature and Encryption.
(5) XML署名と暗号化と比較したJWSとJWEの相対的な容易さ。
The parameters "request" and "request_uri" are introduced as additional authorization request parameters for the OAuth 2.0 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0 authorization request parameters. Note that, in contrast to RFC 7519, the elements of the Claims Set are encoded OAuth request parameters [IANA.OAuth.Parameters], supplemented with only a few of the IANA-managed JSON Web Token Claims [IANA.JWT.Claims], in particular, "iss" and "aud". The JWT in the "request" parameter is integrity protected and source authenticated using JWS.
「要求」と「request_uri」とは、OAuth 2.0 [RFC6749]フローの追加の許可要求パラメータとして導入されています。"Request"パラメータは、JWTクレーム・セットがJSONエンコードされたOAuth 2.0許可要求パラメータを保持しているJSON Webトークン（JWT）[RFC7519]です。RFC 7519とは対照的に、特許請求の範囲の要素は、IANA管理JSON Webトークンクレーム[IANA.JWT.CLAIMS]のほんの少しだけ補完された、符号化OAuth要求パラメータ[IANA.OAUTH.PARAMETERS]である。特に、「ISS」と「AUD」。「要求」パラメータのJWTは、整合性保護され、JWSを使用して認証されたソースです。
The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter "request_uri" is used instead of "request".
JWT [RFC7519]は参照により許可エンドポイントに渡すことができます。その場合、「要求」の代わりにパラメータ "request_uri"が使用されます。
Using JWT [RFC7519] as the request encoding instead of query parameters has several advantages:
クエリパラメータの代わりに要求エンコーディングとしてJWT [RFC7519]を使用すると、いくつかの利点があります。
(a) Integrity protection. The request can be signed so that the integrity of the request can be checked.
(a) 完全性保護要求の整合性を確認できるように要求を署名することができます。
(b) Source authentication. The request can be signed so that the signer can be authenticated.
(b) ソース認証署名者が認証できるように要求を署名することができます。
(c) Confidentiality protection. The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another (including at and before user agents).
(c) 機密保護TLS接続が1点または別の点で終了してもエンドツーエンドの機密性を提供できるように、要求を暗号化することができます（ユーザーエージェントを介しておよび前に含む）。
(d) Collection minimization. The request can be signed by a trusted third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a trusted third party to confirm that all the personal data requested is strictly necessary to perform the process that the end user asked for; the request would then be signed by that trusted third party. The authorization server then examines the signature and shows the conformance status to the end user who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances.
(d) 収集最小化要求は、許可要求が特定のポリシーに準拠していることを証明する信頼できる第三者によって署名することができます。例えば、要求された全ての個人データが求められたプロセスを実行するために厳密に必要であることを確認するために、信頼できる第三者によって要求を事前検査することができる。その後、その要求はその信頼できる第三者によって署名されます。その後、認証サーバーは署名を調べて、その認証時の要求の正当性に関するいくつかの保証を持つことを確認するエンドユーザーに適合性を示します。場合によっては、そのような状況下で認証ダイアログをスキップすることさえ望ましい場合があります。
There are a few cases where request by reference is useful, such as:
参照による要求が有用である場合はいくつかあります。
1. when it is desirable to reduce the size of a transmitted request. The use of application-layer security increases the size of the request particularly when public-key cryptography is used.
1. 送信要求のサイズを小さくすることが望ましい場合。アプリケーション層のセキュリティの使用は、特に公開鍵暗号化が使用されている場合の要求のサイズを増加させます。
2. when the client does not want to do the application-level cryptography. The authorization server may provide an endpoint to accept the authorization request through direct communication with the client, so that the client is authenticated and the channel is TLS protected.
2. クライアントがアプリケーションレベルの暗号化をしたくない場合。許可サーバは、クライアントと直接通信することによって許可要求を受け入れるためのエンドポイントを提供することができ、クライアントは認証され、チャネルはTLS保護されている。
This capability is in use by OpenID Connect [OpenID.Core].
この機能はOpenID Connect [OpenID.Core]によって使用されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
For the purposes of this specification, the following terms and definitions apply in addition to what is defined in OAuth 2.0 Framework [RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption [RFC7516].
本明細書の目的のために、OAuth 2.0フレームワーク[RFC6749]、JSON Web Signature [RFC7515]、およびJSON Web暗号化[RFC7516]で定義されているものに加えて、以下の用語と定義が適用されます。
A Request Object is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0 authorization request parameters.
要求オブジェクトは、JWTクレーム・セットがJSONエンコードされたOAuth 2.0許可要求パラメータを保持しているJSON Webトークン（JWT）[RFC7519]です。
A Request Object URI is an absolute URI that references the set of parameters comprising an OAuth 2.0 authorization request. The content of the resource referenced by the URI is a Request Object (Section 2.1), unless the URI was provided to the client by the same authorization server, in which case the content is an implementation detail at the discretion of the authorization server. The content being a Request Object is to ensure interoperability in cases where the provider of the "request_uri" is a separate entity from the consumer, such as when a client provides a URI referencing a Request Object stored on the client's backend service that is made accessible via HTTPS. In the latter case, where the authorization server is both provider and consumer of the URI, such as when it offers an endpoint that provides a URI in exchange for a Request Object, this interoperability concern does not apply.
要求オブジェクトURIは、OAuth 2.0許可要求を含むパラメータのセットを参照する絶対URIです。URIが参照するリソースの内容は、同じ許可サーバーによってクライアントに提供されていない限り、要求オブジェクト（セクション2.1）であり、その場合、コンテンツは認可サーバーの裁量での実装詳細です。要求オブジェクトであるコンテンツは、クライアントがアクセス可能にされているクライアントのバックエンドサービスに格納されている要求オブジェクトを参照するURIを提供する場合など、「request_uri」のプロバイダがコンシューマから別のエンティティである場合に相互運用性を確保することです。HTTPS経由で。後者の場合、許可サーバーは、要求オブジェクトとの間でURIを提供するエンドポイントを提供する場合など、URIのプロバイダーとコンシューマの両方で、この相互運用性に関する関心事が適用されません。
The following abbreviations are common to this specification.
以下の略語はこの仕様に共通しています。
JSON: JavaScript Object Notation
JSON：JavaScriptオブジェクト表記法
JWT: JSON Web Token
JWT：JSON Webトークン
JWS: JSON Web Signature
JWS：JSON Web Signature.
JWE: JSON Web Encryption
JWE：JSON Web暗号化
URI: Uniform Resource Identifier
URI：ユニフォームリソース識別子
URL: Uniform Resource Locator
URL：ユニフォームリソースロケータ
A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request except the "request" and "request_uri" parameters that are defined in this document. The parameters are represented as the JWT Claims of the object. Parameter names and string values MUST be included as JSON strings. Since Request Objects are handled across domains and potentially outside of a closed ecosystem, per Section 8.1 of [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629]. Numerical values MUST be included as JSON numbers. The Request Object MAY include any extension parameters. This JSON [RFC8259] object constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted.
要求オブジェクト（セクション2.1）は、OAuth 2.0許可要求の許可要求パラメータを提供するために使用されます。このドキュメントで定義されている「要求」および「request_uri」パラメータを除くOAuth 2.0 [RFC6749]承認要求を処理するために使用されるすべてのパラメータ（拡張パラメータを含む）を含める必要があります。パラメータは、オブジェクトのJWTクレームとして表されます。パラメータ名と文字列値はJSON文字列として含める必要があります。リクエストオブジェクトはドメイン間で扱われ、閉じたエコシステムの潜在的に閉じられている閉じたエコシステムの外側には、[RFC8259]のセクション8.1は、これらのJSON文字列をUTF-8 [RFC3629]を使用してエンコードする必要があります。数値はJSON番号として含める必要があります。要求オブジェクトは任意の拡張パラメータを含み得る。このJSON [RFC8259]オブジェクトは、JWT [RFC7519]で定義されているJWTクレーム・セットを構成します。その後、JWTクレームセットは署名または署名され、暗号化されます。
To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a JWS-signed JWT [RFC7519]. If signed, the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members with their semantics being the same as defined in the JWT [RFC7519] specification. The value of "aud" should be the value of the authorization server (AS) "issuer", as defined in RFC 8414 [RFC8414].
署名するには、JSON Web Signature（JWS）[RFC7515]が使用されます。結果はJWS署名されたJWT [RFC7519]です。署名されている場合、許可要求オブジェクトには、SemanticsがJWT [RFC7519]仕様と同じであると同じであるメンバーとして、クレーム "ISS"（発行者）と「AUD」（オーディエンス）を含める必要があります。RFC 8414 [RFC8414]で定義されているように、「AUD」の値は、許可サーバー（AS） "ISSUER"の値です。
To encrypt, JWE [RFC7516] is used. When both signature and encryption are being applied, the JWT MUST be signed, then encrypted, as described in Section 11.2 of [RFC7519]. The result is a Nested JWT, as defined in [RFC7519].
暗号化するには、JWE [RFC7516]が使用されます。シグネチャと暗号化の両方が適用されている場合は、[RFC7519]のセクション11.2で説明したように、JWTを署名してから暗号化されている必要があります。[RFC7519]で定義されているように、結果はネストされたJWTです。
The client determines the algorithms used to sign and encrypt Request Objects. The algorithms chosen need to be supported by both the client and the authorization server. The client can inform the authorization server of the algorithms that it supports in its dynamic client registration metadata [RFC7591], specifically, the metadata values "request_object_signing_alg", "request_object_encryption_alg", and "request_object_encryption_enc". Likewise, the authorization server can inform the client of the algorithms that it supports in its authorization server metadata [RFC8414], specifically, the metadata values "request_object_signing_alg_values_supported", "request_object_encryption_alg_values_supported", and "request_object_encryption_enc_values_supported".
クライアントは、要求オブジェクトの署名および暗号化に使用されるアルゴリズムを決定します。選択されたアルゴリズムは、クライアントと許可サーバーの両方によってサポートされる必要があります。クライアントは、そのダイナミックなクライアント登録メタデータ[RFC7591]、具体的には、メタデータ値を「request_object_signing_alg」、「request_object_encryption_alg」、および「request_object_encryption_enc」でサポートしているアルゴリズムの認証サーバに通知することができます。同様に、許可サーバーは、認証サーバーメタデータ[RFC8414]、具体的には、メタデータ値 "request_object_signing_alg_values_supported"、 "request_object_encryption_alg_values_supported"、および "request_object_encryption_enc_values_supported"をクライアントに通知することができます。
The Request Object MAY be sent by value, as described in Section 5.1, or by reference, as described in Section 5.2. "request" and "request_uri" parameters MUST NOT be included in Request Objects.
要求オブジェクトは、セクション5.1で説明されているように、またはセクション5.2で説明されているように、値によって送信されてもよい。"Request"と "Request_URI"パラメータを要求オブジェクトに含めないでください。
A Request Object (Section 2.1) has the media type [RFC2046] "application/oauth-authz-req+jwt". Note that some existing deployments may alternatively be using the type "application/jwt".
リクエストオブジェクト（セクション2.1）には、メディアタイプ[RFC2046] "application / oauth-authz-req jwt"があります。ある種の既存の展開は、「アプリケーション/ JWT」タイプを使用している可能性があることに注意してください。
The following is an example of the Claims in a Request Object before base64url [RFC7515] encoding and signing. Note that it includes the extension parameters "nonce" and "max_age".
以下は、Base64URL [RFC7515]エンコードと署名前の要求オブジェクトの特許請求の範囲の一例である。拡張パラメータ「Nonce」と「MAX_AGE」を含みます。
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400
}
Signing it with the "RS256" algorithm [RFC7518] results in this Request Object value (with line wraps within values for display purposes only):
「RS256」アルゴリズム[RFC7518]で署名すると、この要求オブジェクトの値が表示されます（表示目的の場合にのみ値のみが表示されます）。
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-G
The following RSA public key, represented in JSON Web Key (JWK) format, can be used to validate the Request Object signature in this and subsequent Request Object examples (with line wraps within values for display purposes only):
JSON Webキー（JWK）形式で表されている次のRSA公開鍵を使用して、この要求オブジェクトの例とそれ以降のリクエスト・オブジェクトの例で要求オブジェクトの署名を検証することができます（表示目的の場合のみ値内にあります）。
{
"kty":"RSA",
"kid":"k2bdc",
"n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
"e":"AQAB"
}
The client constructs the authorization request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format:
クライアントは、「アプリケーション/ X-www-www-urlencoded」形式を使用して、次のパラメータを承認エンドポイントURIのクエリコンポーネントに追加することで、許可要求URIを構築します。
request REQUIRED unless "request_uri" is specified. The Request Object (Section 2.1) that holds authorization request parameters stated in Section 4 of [RFC6749] (OAuth 2.0). If this parameter is present in the authorization request, "request_uri" MUST NOT be present.
"request_uri"が指定されていない限り、要求が必要です。[RFC6749]（OAUTH 2.0）のセクション4に記載されている認可要求パラメータを保持する要求オブジェクト（セクション2.1）。このパラメータが許可要求に存在する場合は、「request_uri」が存在してはいけません。
request_uri REQUIRED unless "request" is specified. The absolute URI, as defined by RFC 3986 [RFC3986], that is the Request Object URI (Section 2.2) referencing the authorization request parameters stated in Section 4 of [RFC6749] (OAuth 2.0). If this parameter is present in the authorization request, "request" MUST NOT be present.
"要求"が指定されていない限り、request_uri。RFC 3986 [RFC3986]で定義されているAbsolute URI（RFC6749]（OAuth 2.0）のセクション4に記載されている許可要求パラメータを参照している要求オブジェクトURI（セクション2.2）です。このパラメータが許可要求に存在する場合、「要求」は存在してはいけません。
client_id REQUIRED. OAuth 2.0 [RFC6749] "client_id". The value MUST match the "request" or "request_uri" Request Object's (Section 2.1) "client_id".
client_idが必要です。OAuth 2.0 [RFC6749] "client_id"。値は、「要求」または「request_uri」要求オブジェクト（セクション2.1）「client_id」と一致する必要があります。
The client directs the resource owner to the constructed URI using an HTTP redirection response or by other means available to it via the user agent.
クライアントは、リソース所有者をHTTPリダイレクト応答を使用して、またはユーザーエージェントを介して利用可能な他の手段によって、リソース所有者を構築URIに向けます。
For example, the client directs the end user's user agent to make the following HTTPS request:
たとえば、クライアントはエンドユーザーのユーザーエージェントに次のHTTPSリクエストを実行するように指示します。
GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com
The value for the request parameter is abbreviated for brevity.
要求パラメータの値は簡潔にするために省略されています。
The Authorization Request Object MUST be one of the following:
許可要求オブジェクトは、次のいずれかのものでなければなりません。
(a) JWS signed
(a) JWSは署名されました
(b) JWS signed and JWE encrypted
(b) JWSは署名され、JWE暗号化されました
The client MAY send the parameters included in the Request Object duplicated in the query parameters as well for backward compatibility, etc. However, the authorization server supporting this specification MUST only use the parameters included in the Request Object.
クライアントは、後方互換性などのためにクエリパラメータに重複している要求オブジェクトに含まれるパラメータを送信してもよい。ただし、この仕様をサポートする許可サーバは、要求オブジェクトに含まれるパラメータのみを使用する必要があります。
The client sends the authorization request as a Request Object to the authorization endpoint as the "request" parameter value.
クライアントは、許可要求を要求オブジェクトとして「要求」パラメータ値として送信エンドポイントに送信します。
The following is an example of an authorization request using the "request" parameter (with line wraps within values for display purposes only):
以下は、 "Request"パラメータを使用した許可要求の例です（表示目的のための値内での場合のみ）。
https://server.example.com/authorize?client_id=s6BhdRkqt3& request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6 ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6 ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC 0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W 9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3 j1i7tLR_5Nz-g
https://server.example.com/authorize?client_id=s6BhdRkqt3&リクエスト=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-G
The "request_uri" authorization request parameter enables OAuth authorization requests to be passed by reference rather than by value. This parameter is used identically to the "request" parameter, except that the Request Object value is retrieved from the resource identified by the specified URI rather than passed by value.
"request_uri"承認要求パラメータを使用すると、OAuth承認要求を値ではなく参照によって渡すことができます。このパラメータは、要求オブジェクトの値が、値によって渡されるのではなく、指定されたURIによって識別されたリソースから取得されることを除いて、「要求」パラメータと同じように使用されます。
The entire Request URI SHOULD NOT exceed 512 ASCII characters. There are two reasons for this restriction:
リクエストURI全体が512 ASCII文字を超えてはいけません。この制限には2つの理由があります。
1. Many phones on the market as of this writing still do not accept large payloads. The restriction is typically either 512 or 1024 ASCII characters.
1. この書き込み時点での市場の多くの電話はまだ大きなペイロードを受け入れません。制限は通常、512または1024のASCII文字です。
2. On a slow connection such as a 2G mobile connection, a large URL would cause a slow response; therefore, the use of such is not advisable from the user-experience point of view.
2. 2Gの移動接続などの遅い接続では、大きなURLが遅い応答を引き起こします。したがって、その使用はユーザーエクスペリエンスの観点からはお勧めできません。
The contents of the resource referenced by the "request_uri" MUST be a Request Object and MUST be reachable by the authorization server unless the URI was provided to the client by the authorization server. In the first case, the "request_uri" MUST be an "https" URI, as specified in Section 2.7.2 of [RFC7230]. In the second case, it MUST be a URN, as specified in [RFC8141].
"request_uri"によって参照されるリソースの内容は要求オブジェクトでなければならず、URIが許可サーバーによってクライアントに提供されていない限り、許可サーバーによって到達可能でなければなりません。最初に、[Request_URI]は[RFC7230]のセクション2.7.2で指定されているように、「HTTPS」URIでなければなりません。2番目の場合は、[RFC8141]で指定されているように、URNでなければなりません。
The following is an example of the contents of a Request Object resource that can be referenced by a "request_uri" (with line wraps within values for display purposes only):
以下は、 "request_uri"によって参照できるリクエストオブジェクトリソースの内容の例です（表示目的のための値内のラインラップを使用します）。
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-G
The client stores the Request Object resource either locally or remotely at a URI the authorization server can access. Such a facility may be provided by the authorization server or a trusted third party. For example, the authorization server may provide a URL to which the client POSTs the Request Object and obtains the Request URI. This URI is the Request Object URI, "request_uri".
クライアントは、許可サーバーがアクセスできるURIで、要求オブジェクトリソースをローカルまたはリモートで保存します。そのような施設は、許可サーバーまたは信頼できる第三者によって提供され得る。例えば、許可サーバは、クライアントが要求オブジェクトを投稿し、要求URIを取得するURLを提供することができる。このURIはリクエストオブジェクトURI、「request_uri」です。
It is possible for the Request Object to include values that are to be revealed only to the authorization server. As such, the "request_uri" MUST have appropriate entropy for its lifetime so that the URI is not guessable if publicly retrievable. For the guidance, refer to Section 5.1.4.2.2 of [RFC6819] and "Good Practices for Capability URLs" [CapURLs]. It is RECOMMENDED that the "request_uri" be removed after a reasonable timeout unless access control measures are taken.
要求オブジェクトに許可サーバーにのみ明らかにされる値を含めることができます。そのように、 "request_uri"はその生涯に対して適切なエントロピーを持っていなければなりませんので、URIは公に取得可能であればURIは推測できません。ガイダンスについては、[RFC6819]のセクション5.1.4.2.2、および「機能URLのためのグッドプラクティス」を参照してください[Capurls]。アクセス制御措置が取られない限り、妥当なタイムアウト後に「request_uri」を削除することをお勧めします。
The following is an example of a Request Object URI value (with line wraps within values for display purposes only). In this example, a trusted third-party service hosts the Request Object.
以下は、要求オブジェクトのURI値（表示目的のための値内でのみラップを含む）の例です。この例では、信頼できるサードパーティサービスが要求オブジェクトをホストしています。
https://tfp.example.org/request.jwt/
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
The client sends the authorization request to the authorization endpoint.
クライアントは許可エンドポイントに承認要求を送信します。
The following is an example of an authorization request using the "request_uri" parameter (with line wraps within values for display purposes only):
以下は、 "request_uri"パラメータを使用した認証要求の例です（表示目的の場合のみ値内のラインラップを持つ）。
https://server.example.com/authorize?
client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
Upon receipt of the Request, the authorization server MUST send an HTTP "GET" request to the "request_uri" to retrieve the referenced Request Object unless the Request Object is stored in a way so that the server can retrieve it through other mechanisms securely and parse it to recreate the authorization request parameters.
要求を受け取ると、許可サーバーは、サーバーが他のメカニズムを介して確実にそれを取り出すことができるように、要求オブジェクトが他のメカニズムを通してそれを取り出すことができるように、要求オブジェクトがそのように保存されていない限り、参照要求オブジェクトを取得するために、許可サーバーは "request_uri"に送信する必要があります。認証要求パラメータを再作成するためにそれを再現します。
The following is an example of this fetch process. In this example, a trusted third-party service hosts the Request Object.
以下は、このフェッチ処理の一例です。この例では、信頼できるサードパーティサービスが要求オブジェクトをホストしています。
GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org
The following is an example of the fetch response:
以下は、フェッチ応答の例です。
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2020 23:52:39 GMT
Server: Apache/2.4.43 (tfp.example.org)
Content-type: application/oauth-authz-req+jwt
Content-Length: 797
Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-G
If the Request Object is encrypted, the authorization server MUST decrypt the JWT in accordance with the JSON Web Encryption [RFC7516] specification.
要求オブジェクトが暗号化されている場合、承認サーバーはJSON Web暗号化[RFC7516]仕様に従ってJWTを復号化する必要があります。
The result is a signed Request Object.
結果は署名付き要求オブジェクトです。
If decryption fails, the authorization server MUST return an "invalid_request_object" error to the client in response to the authorization request.
復号化に失敗した場合、許可サーバーは、許可要求に応答してクライアントに "Invalid_Request_Object"エラーを返す必要があります。
The authorization server MUST validate the signature of the JWS-signed [RFC7515] Request Object. If a "kid" Header Parameter is present, the key identified MUST be the key used and MUST be a key associated with the client. The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725].
承認サーバーは、JWS署名付き[RFC7515]要求オブジェクトの署名を検証する必要があります。「キッド」ヘッダパラメータが存在する場合、識別されたキーは使用される鍵でなければならず、クライアントに関連付けられているキーである必要があります。署名は、クライアントに関連付けられているキーと「ALG」ヘッダーパラメータで指定されたアルゴリズムを使用して検証する必要があります。[RFC8725]のセクション3.1および3.2で指定されているように、アルゴリズムの検証を実行する必要があります。
If the key is not associated with the client or if signature validation fails, the authorization server MUST return an "invalid_request_object" error to the client in response to the authorization request.
キーがクライアントに関連付けられていない場合、または署名検証が失敗した場合、許可要求に応答して、承認サーバーは「Invalid_Request_Object」エラーをクライアントに返す必要があります。
The authorization server MUST extract the set of authorization request parameters from the Request Object value. The authorization server MUST only use the parameters in the Request Object, even if the same parameter is provided in the query parameter. The client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The authorization server then validates the request, as specified in OAuth 2.0 [RFC6749].
許可サーバーは、要求オブジェクト値から承認要求パラメータのセットを抽出する必要があります。承認サーバーは、クエリパラメーターに同じパラメーターが提供されていても、要求オブジェクト内のパラメーターのみを使用する必要があります。「client_id」要求パラメータおよび要求オブジェクト「client_id」クレーム内のクライアントID値は同一でなければならない。許可サーバーは、OAuth 2.0 [RFC6749]で指定されているように、要求を検証します。
If the Client ID check or the request validation fails, then the authorization server MUST return an error to the client in response to the authorization request, as specified in Section 5.2 of [RFC6749] (OAuth 2.0).
クライアントIDチェックまたは要求検証が失敗した場合、[RFC6749]（OAuth 2.0）のセクション5.2で指定されているように、許可サーバーは認証要求に応じてエラーを返却する必要があります。
The authorization server response is created and sent to the client as in Section 4 of [RFC6749] (OAuth 2.0).
許可サーバーの応答が作成され、[RFC6749]（OAuth 2.0）のセクション4のようにクライアントに送信されます。
In addition, this document uses these additional error values:
さらに、このドキュメントではこれらの追加のエラー値を使用します。
invalid_request_uri The "request_uri" in the authorization request returns an error or contains invalid data.
invalid_request_uri承認要求の "request_uri"はエラーを返し、無効なデータを含みます。
invalid_request_object The request parameter contains an invalid Request Object.
invalid_request_object requestパラメータに無効な要求オブジェクトが含まれています。
request_not_supported The authorization server does not support the use of the "request" parameter.
request_not_supported承認サーバーは "Request"パラメーターの使用をサポートしていません。
request_uri_not_supported The authorization server does not support the use of the "request_uri" parameter.
request_uri_not_supported authorizationサーバーは、 "request_uri"パラメーターの使用をサポートしていません。
Client implementations supporting the Request Object URI method MUST support TLS, following "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525].
要求オブジェクトURIメソッドをサポートするクライアント実装は、「トランスポートレイヤセキュリティ（TLS）とデータグラムトランスポートレイヤセキュリティ（DTLS）」[RFC7525]を次に示します。
To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a cipher suite that provides confidentiality and integrity protection.
情報の開示と改ざんから保護するためには、機密保護を使用して機密保護を利用して、機密性と完全性保護を提供するCipher Suiteを使用して適用する必要があります。
HTTP clients MUST also verify the TLS server certificate, using DNS-ID [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
HTTPクライアントは、中間攻撃を避けるために、DNS-ID [RFC6125]を使用してTLSサーバー証明書を検証する必要があります。[RFC6125]で定義されている規則とガイドラインはここに適用されます。
* Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED. Certification authorities that issue server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in server certificates.
* DNS-ID識別子タイプのサポート（つまり、SubjectAltName拡張子内のDNSNAME ID）が必要です。サーバー証明書を発行する認証局は、DNS-ID識別子タイプをサポートし、DNS-ID IDタイプをサーバー証明書に存在する必要があります。
* DNS names in server certificates MAY contain the wildcard character "*".
* サーバー証明書のDNS名はワイルドカード文字 "*"を含めることができます。
* Clients MUST NOT use CN-ID identifiers; a Common Name field (CN field) may be present in the server certificate's subject name but MUST NOT be used for authentication within the rules described in [RFC7525].
* クライアントはCN-ID識別子を使用してはいけません。一般的な名前フィールド（CNフィールド）がサーバー証明書の件名名に存在しますが、[RFC7525]で説明されているルール内の認証に使用しないでください。
* SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST NOT be used for comparison.
* [RFC6125]のセクション6.5に記載されているSRV-IDとURI-IDは、比較に使用しないでください。
Since the Request Object is a JWT, the core JWT claims cannot be used for any purpose in the Request Object other than for what JWT dictates. Thus, they have been registered as OAuth authorization request parameters to avoid future OAuth extensions using them with different meanings.
要求オブジェクトはJWTであるため、JWTがJWTが指定したもの以外の要求オブジェクト内の任意の目的には、コアJWTクレームを使用することはできない。したがって、それらは異なる意味でそれらを使用している将来のOAUTH拡張を避けるために、OAuth認証要求パラメータとして登録されています。
This specification adds the following values to the "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].
この仕様は、[RFC6749]によって確立された「OAuthパラメータ」レジストリ[iana.oauth.parameters]に次の値を追加します。
Name: "iss" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.1 of [RFC7519].
名前： "ISS"パラメータの使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書およびセクション4.1.1。
Name: "sub" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.2 of [RFC7519].
名前： "SUB"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書およびセクション4.1.2。
Name: "aud" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.3 of [RFC7519].
名前： "AUD"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書とセクション4.1.3。
Name: "exp" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.4 of [RFC7519].
名前： "exp"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書とセクション4.1.4。
Name: "nbf" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.5 of [RFC7519].
名前： "NBF"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：この文書とセクション4.1.5 [RFC7519]。
Name: "iat" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.6 of [RFC7519].
名前： "IAT"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書とセクション4.1.6。
Name: "jti" Parameter Usage Location: authorization request Change Controller: IETF Specification Document(s): This document and Section 4.1.7 of [RFC7519].
名前： "JTI"パラメータ使用場所：承認要求変更コントローラ：IETF仕様書：[RFC7519]のこの文書とセクション4.1.7。
This specification adds the following value to the "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].
この仕様は、[RFC8414]によって確立された「OAuth認証サーバーメタデータ」レジストリ[IANA.OAUTH.PARAMETERS]に次の値を追加します。
Metadata Name: "require_signed_request_object" Metadata Description: Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". Change Controller: IETF Specification Document(s): Section 10.5 of this document.
メタデータ名： "required_red_request_object"メタデータ説明：許可要求を要求オブジェクトとして保護する必要があり、 "Request"または "Request_Uriパラメータ"を介して提供されるようにします。変更コントローラー：IETF仕様書この文書の10.5項。
This specification adds the following value to the "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591].
この仕様は、[RFC7591]によって確立された「OAuth動的クライアント登録メタデータ」レジストリ[IANA.OAUTH.PARAMETERS]に次の値を追加します。
Metadata Name: "require_signed_request_object" Metadata Description: Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". Change Controller: IETF Specification Document(s): Section 10.5 of this document.
メタデータ名： "required_red_request_object"メタデータ説明：許可要求を要求オブジェクトとして保護する必要があり、 "Request"または "Request_Uriパラメータ"を介して提供されるようにします。変更コントローラー：IETF仕様書この文書の10.5項。
This section registers the "application/oauth-authz-req+jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838]. It can be used to indicate that the content is a JWT containing Request Object claims.
このセクションでは、[RFC6838]に記載されている方法で、 "Media Types"レジストリ[IANA.MEDIATYPES]の「アプリケーション/ oauth-authz-req jwt」メディアタイプ[RFC2046]を登録します。コンテンツが要求オブジェクトクレームを含むJWTであることを示すために使用できます。
Type name: application
Subtype name: oauth-authz-req+jwt
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary; a Request Object is a JWT; JWT
values are encoded as a series of base64url-encoded values (some
of which may be the empty string) separated by period (".")
characters.
Security considerations: See Section 10 of RFC 9101
Interoperability considerations: N/A
Published specification: Section 4 of RFC 9101
Applications that use this media type: Applications that use Request
Objects to make an OAuth 2.0 authorization request
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Nat Sakimura <nat@nat.consulting>
Intended usage: COMMON
Restrictions on usage: none
Author: Nat Sakimura <nat@nat.consulting>
Change controller: IETF
Provisional registration? No
In addition to all the security considerations discussed in OAuth 2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516], [RFC7518], and [RFC8725] need to be considered. Also, there are several academic papers such as [BASIN] that provide useful insight into the security properties of protocols like OAuth.
OAuth 2.0 [RFC6819]で説明したすべてのセキュリティ上の考慮事項に加えて、[RFC7515]、[RFC7516]、[RFC7518]、[RFC8725]のセキュリティ上の考慮事項を考慮する必要があります。また、OAuthのようなプロトコルのセキュリティ特性について有用な洞察を提供する[盆地]のようないくつかの学術論文があります。
In consideration of the above, this document advises taking the following security considerations into account.
上記を考慮して、この文書は以下のセキュリティ上の考慮事項を考慮してお勧めします。
When sending the Authorization Request Object through the "request" parameter, it MUST be either signed using JWS [RFC7515] or signed and then encrypted using JWS [RFC7515] and JWE [RFC7516], respectively, with algorithms considered appropriate at the time.
承認要求オブジェクトを "Request"パラメーターで送信する場合は、JWS [RFC7515]を使用して署名されたり、JWS [RFC7515]とJWS [RFC7516]を使用して暗号化され、その時点で適切と見なされるアルゴリズムを使用して暗号化する必要があります。
The source of the authorization request MUST always be verified. There are several ways to do it:
承認要求の源は常に検証されなければなりません。それをする方法はいくつかあります。
(a) Verifying the JWS Signature of the Request Object.
(a) リクエストオブジェクトのJWSシグネチャを検証します。
(b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Note, however, that if public key encryption is used, no source authentication is enabled by the encryption, as any party can encrypt to the public key.
(b) JWEが対称暗号化を使用している場合は、JWE暗号化の対称鍵が正しいものであることを確認してください。ただし、公開鍵の暗号化が使用されている場合、公開鍵に暗号化できるため、暗号化によってソース認証は有効になりません。
(c) Verifying the TLS Server Identity of the Request Object URI. In this case, the authorization server MUST know out-of-band that the client uses the Request Object URI and only the client is covered by the TLS certificate. In general, this is not a reliable method.
(c) 要求オブジェクトURIのTLSサーバーのIDを確認します。この場合、許可サーバーは、クライアントが要求オブジェクトURIを使用し、クライアントのみがTLS証明書でカバーされている範囲外を知っている必要があります。一般に、これは信頼できる方法ではありません。
(d) When an authorization server implements a service that returns a Request Object URI in exchange for a Request Object, the authorization server MUST perform client authentication to accept the Request Object and bind the client identifier to the Request Object URI it is providing. It MUST validate the signature, per (a). Since the Request Object URI can be replayed, the lifetime of the Request Object URI MUST be short and preferably one-time use. The entropy of the Request Object URI MUST be sufficiently large. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute, and the Request Object URI is to include a cryptographic random value of 128 bits or more at the time of the writing of this specification.
(d) 許可サーバーが要求オブジェクトの要求オブジェクトURIを返すサービスを実装すると、許可サーバーは要求オブジェクトを受け入れてクライアント識別子を提供している要求オブジェクトURIにバインドするためにクライアント認証を実行する必要があります。（a）ごとに署名を検証する必要があります。要求オブジェクトURIを再生することができるので、要求オブジェクトURIの寿命は短く、好ましくは1回使用する必要がある。要求オブジェクトURIのエントロピーは十分に大きくなければなりません。妥当性の適切な短さと要求オブジェクトURIのエントロピーは、保護されているリソースの値に基づくリスク計算に依存します。有効期間の一般的なガイダンスは1分未満になり、この仕様書の書き込み時に要求オブジェクトURIは128ビット以上の暗号ランダム値を含むことになる。
(e) When a trusted third-party service returns a Request Object URI in exchange for a Request Object, it MUST validate the signature, per (a). In addition, the authorization server MUST be trusted by the third-party service and MUST know out-of-band that the client is also trusted by it.
(e) 信頼できるサードパーティサービスがリクエストオブジェクトとExchangeの要求オブジェクトURIを返す場合は、（A）ごとに署名を検証する必要があります。さらに、許可サーバーはサードパーティのサービスによって信頼されなければならず、クライアントが信頼されている帯域外を知っている必要があります。
Although this specification does not require them, research such as [BASIN] points out that it is a good practice to explicitly state the intended interaction endpoints and the message position in the sequence in a tamper-evident manner so that the intent of the initiator is unambiguous. It is RECOMMENDED by this specification to use this practice for the following endpoints defined in [RFC6749], [RFC6750], and [RFC8414]:
この仕様はそれらを必要としないが、「盆地」のような研究は、意図的に意図的な対話エンドポイントを明示的に明示的に述べることが、イニシエータの意図が不明瞭な方法で明示的に述べていることを指摘している。明確な。[RFC6749]、[RFC6750]、[RFC8414]で定義されている次のエンドポイントには、この仕様がこの慣行を使用することをお勧めします。
(a) Protected resources ("protected_resources")
(a) 保護されたリソース（ "protected_resources"）
(b) Authorization endpoint ("authorization_endpoint")
(b) 承認エンドポイント（ "authorization_endpoint"）
(c) Redirection URI ("redirect_uri")
(c) リダイレクトURI（ "Redirect_Uri"）
(d) Token endpoint ("token_endpoint")
(d) トークンエンドポイント（ "token_endpoint"）
Further, if dynamic discovery is used, then this practice also applies to the discovery-related endpoints.
さらに、動的検出が使用されている場合、この慣行は発見関連のエンドポイントにも適用されます。
In [RFC6749], while the redirection URI is included in the authorization request, others are not. As a result, the same applies to the Authorization Request Object.
[RFC6749]では、リダイレクトURIが許可要求に含まれている間は、他のものはありません。その結果、承認要求オブジェクトについても同様です。
The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of [RFC3986] for more information regarding risks associated with URIs.
「request_uri」の導入はいくつかの攻撃の可能性を紹介します。URIに関連するリスクの詳細については、[RFC3986]のセクション7のセキュリティ上の考慮事項を参照してください。
A set of malicious clients can launch a DoS attack to the authorization server by pointing the "request_uri" to a URI that returns extremely large content or is extremely slow to respond. Under such an attack, the server may use up its resource and start failing.
悪意のあるクライアントのセットは、非常に大きなコンテンツを返す、または応答が非常に遅いURIに「request_uri」を指すことによって、許可サーバーへのDOS攻撃を起動できます。このような攻撃の下で、サーバーはそのリソースを使用して失敗し始めることがあります。
Similarly, a malicious client can specify a "request_uri" value that itself points to an authorization request URI that uses "request_uri" to cause the recursive lookup.
同様に、悪意のあるクライアントは、それ自身が「request_uri」を使用して再帰的検索を引き起こす承認要求URIを指す「request_uri」値を指定できます。
To prevent such an attack from succeeding, the server should a) check that the value of the "request_uri" parameter does not point to an unexpected location, b) check that the media type of the response is "application/oauth-authz-req+jwt", c) implement a timeout for obtaining the content of "request_uri", and d) not perform recursive GET on the "request_uri".
このような攻撃を防ぐために、「Request_URI」パラメータの値が予期せぬ場所を指していないことを確認する必要があります.b）応答のメディアタイプが「application / oauth-authz-req」であることを確認してください。JWT "、c）" request_uri "の内容を取得するためのタイムアウトを実装し、d）" request_uri "に再帰的に実行されません。
The value of "request_uri" is not signed; thus, it can be tampered with by a man-in-the-browser attacker. Several attack possibilities arise because of this. For example, a) an attacker may create another file that the rewritten URI points to, making it possible to request extra scope, or b) an attacker may launch a DoS attack on a victim site by setting the value of "request_uri" to be that of the victim.
"request_uri"の値は署名されていません。したがって、ブラウザの攻撃者によって改ざんすることができます。このため、いくつかの攻撃の可能性が発生します。たとえば、a）攻撃者は、書き換えられたURIを指している別のファイルを作成し、追加の範囲を要求することを可能にします。犠牲者のそれ。
To prevent such an attack from succeeding, the server should a) check that the value of the "request_uri" parameter does not point to an unexpected location, b) check that the media type of the response is "application/oauth-authz-req+jwt", and c) implement a timeout for obtaining the content of "request_uri".
このような攻撃を防ぐために、「Request_URI」パラメータの値が予期せぬ場所を指していないことを確認する必要があります.b）応答のメディアタイプが「application / oauth-authz-req」であることを確認してください。jwt "、c）" request_uri "の内容を取得するためのタイムアウトを実装してください。
Unless the protocol used by the client and the server is locked down to use an OAuth JWT-Secured Authorization Request (JAR), it is possible for an attacker to use RFC 6749 requests to bypass all the protection provided by this specification.
クライアントとサーバーが使用するプロトコルがOAuth JWT保護許可要求（JAR）を使用するようにロックダウンされていない限り、攻撃者はこの仕様によって提供されるすべての保護を回避するためにRFC 6749要求を使用することが可能です。
To prevent this kind of attack, this specification defines new client metadata and server metadata values, both named "require_signed_request_object", whose values are both booleans.
このような攻撃を防ぐために、この仕様は新しいクライアントメタデータとサーバーメタデータ値を定義し、その値は両方ともBooleansである "require_signed_request_object"。
When the value of it as client metadata is "true", then the server MUST reject the authorization request from the client that does not conform to this specification. It MUST also reject the request if the Request Object uses an "alg" value of "none" when this server metadata value is "true". If omitted, the default value is "false".
クライアントメタデータとしての値が "true"の場合、サーバーはこの仕様に準拠していないクライアントからの許可要求を拒否する必要があります。要求オブジェクトが、このサーバーメタデータ値が "True"のときに "None"の "ALG"値を使用する場合は、要求を拒否する必要があります。省略した場合、デフォルト値は "false"です。
When the value of it as server metadata is "true", then the server MUST reject the authorization request from any client that does not conform to this specification. It MUST also reject the request if the Request Object uses an "alg" value of "none". If omitted, the default value is "false".
サーバーメタデータとしての値が "true"の場合、サーバーはこの仕様に準拠しない任意のクライアントからの許可要求を拒否する必要があります。Requestオブジェクトが "NONE"の "ALG"値を使用する場合は、要求を拒否する必要があります。省略した場合、デフォルト値は "false"です。
Note that even if "require_signed_request_object" metadata values are not present, the client MAY use signed Request Objects, provided that there are signing algorithms mutually supported by the client and the server. Use of signing algorithm metadata is described in Section 4.
"require_signed_request_object"メタデータ値が存在しない場合でも、クライアントとサーバーによって相互にサポートされている署名アルゴリズムがある場合は、クライアントは署名された要求オブジェクトを使用できます。署名アルゴリズムメタデータの使用はセクション4で説明されています。
Current security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525]. This supersedes the TLS version recommendations in OAuth 2.0 [RFC6749].
現在のセキュリティ上の考慮事項は、「トランスポートレイヤセキュリティ（TLS）とデータグラムトランスポートレイヤセキュリティ（DTLS）」[RFC7525]を「安全に使用するための推奨事項」にあります。これにより、OAuth 2.0 [RFC6749]のTLSバージョンの推奨事項が優先されます。
Given that OAuth parameter values are being sent in two different places, as normal OAuth parameters and as Request Object claims, implementations must guard against attacks that could use mismatching parameter values to obtain unintended outcomes. That is the reason that the two client ID values MUST match, the reason that only the parameter values from the Request Object are to be used, and the reason that neither "request" nor "request_uri" can appear in a Request Object.
OAuthパラメータ値が2つの異なる場所で、通常のOAuthパラメータとして、および要求オブジェクトのクレームとして送信されていることを考えると、実装は不一致パラメータ値を使用して意図しない結果を得ることができる攻撃に対してガードしなければなりません。これが、2つのクライアントID値が一致しなければならないため、要求オブジェクトからのパラメータ値のみを使用する理由と、要求オブジェクトに "Request" NOR "Request_uri"も表示されない理由です。
As described in Section 2.8 of [RFC8725], attackers may attempt to use a JWT issued for one purpose in a context that it was not intended for. The mitigations described for these attacks can be applied to Request Objects.
[RFC8725]のセクション2.8で説明されているように、攻撃者は、それが意図されていなかった文脈で1つの目的のために発行されたJWTを使用しようとするかもしれません。これらの攻撃について説明した軽減は、オブジェクトを要求するために適用できます。
One way that an attacker might attempt to repurpose a Request Object is to try to use it as a client authentication JWT, as described in Section 2.2 of [RFC7523]. A simple way to prevent this is to never use the client ID as the "sub" value in a Request Object.
[RFC7523]のセクション2.2で説明されているように、攻撃者が要求オブジェクトの再利用を試みることは、クライアント認証JWTとして使用しようとすることです。これを防ぐための簡単な方法は、リクエストオブジェクト内の "sub"値としてクライアントIDを使用することは決してないことです。
Another way to prevent cross-JWT confusion is to use explicit typing, as described in Section 3.11 of [RFC8725]. One would explicitly type a Request Object by including a "typ" Header Parameter with the value "oauth-authz-req+jwt" (which is registered in Section 9.4.1). Note, however, that requiring explicitly typed Request Objects at existing authorization servers will break most existing deployments, as existing clients are already commonly using untyped Request Objects, especially with OpenID Connect [OpenID.Core]. However, requiring explicit typing would be a good idea for new OAuth deployment profiles where compatibility with existing deployments is not a consideration.
Cross-JWTの混乱を防ぐもう1つの方法は、[RFC8725]のセクション3.11で説明されているように、明示的なタイピングを使用することです。「typ」ヘッダパラメータを「oauth-authz-req jwt」（セクション9.4.1で登録されている）を含めて、要求オブジェクトを明示的に入力します。ただし、既存の認可サーバーで明示的に型付けされた要求オブジェクトを必要とすると、既存のクライアントはすでに一般的に既存のクライアントがすでに一般的に既存の展開を壊しています。特にOpenID Connect [OpenID.Core]。ただし、明示的なタイピングが必要な場合は、既存の展開との互換性が考慮されていない新しいOAuthデプロイメントプロファイルに適しています。
Finally, yet another way to prevent cross-JWT confusion is to use a key management regime in which keys used to sign Request Objects are identifiably distinct from those used for other purposes. Then, if an adversary attempts to repurpose the Request Object in another context, a key mismatch will occur, thwarting the attack.
最後に、Cross-JWTの混乱を防ぐためのもう1つの方法は、要求オブジェクトに署名するために使用されるキーが他の目的のために使用されるものと識別的に異なるキー管理体制を使用することです。次に、敵対者が他のコンテキストで要求オブジェクトを再プログ用しようとすると、攻撃を除いて鍵の不一致が発生します。
When the client is being granted access to a protected resource containing personal data, both the client and the authorization server need to adhere to Privacy Principles. "Privacy Considerations for Internet Protocols" [RFC6973] gives excellent guidance on the enhancement of protocol design and implementation. The provisions listed in it should be followed.
クライアントが個人データを含む保護されたリソースへのアクセスを許可されている場合、クライアントと許可サーバーの両方がプライバシーの原則に従う必要があります。「インターネットプロトコルのプライバシーに関する考察」[RFC6973]は、プロトコル設計と実装の強化に関する優れたガイダンスを提供します。それに記載されている規定に従うべきです。
Most of the provisions would apply to "The OAuth 2.0 Authorization Framework" [RFC6749] and "The OAuth 2.0 Authorization Framework: Bearer Token Usage" [RFC6750] and are not specific to this specification. In what follows, only the provisions specific to this specification are noted.
ほとんどの規定は、「OAuth 2.0承認フレームワーク」[RFC6749]と「OAuth 2.0認証フレームワーク：Bearer Token Usage」[RFC6750]に適用され、この仕様に固有のものではありません。以下では、本明細書に特有の規定のみが注目されている。
When the client is being granted access to a protected resource containing personal data, the client SHOULD limit the collection of personal data to that which is within the bounds of applicable law and strictly necessary for the specified purpose(s).
クライアントが個人データを含む保護されたリソースへのアクセスを許可されている場合、クライアントは、適用される法の範囲内にある個人データの収集を制限する必要があり、特定の目的には厳密に必要です。
It is often hard for the user to find out if the personal data asked for is strictly necessary. A trusted third-party service can help the user by examining the client request, comparing it to the proposed processing by the client, and certifying the request. After the certification, the client, when making an authorization request, can submit an authorization request to the trusted third-party service to obtain the Request Object URI. This process has two steps:
ユーザーが求められた個人データが厳密に必要な場合には、ユーザーが見つけるのは困難です。信頼できるサードパーティサービスは、クライアントの要求を調べて、クライアントによる提案された処理と比較し、要求を証明することによってユーザーが役立ちます。認証の後、クライアントは許可要求を行うときに、要求オブジェクトURIを取得するために信頼できるサードパーティサービスに許可要求を送信できます。このプロセスには2つのステップがあります。
(1) (Certification Process) The trusted third-party service examines the business process of the client and determines what claims they need; this is the certification process. Once the client is certified, they are issued a client credential to authenticate against to push Request Objects to the trusted third-party service to get the "request_uri".
(1) （認証プロセス）信頼できるサードパーティサービスはクライアントのビジネスプロセスを調べ、必要なクレームを決定します。これは認証プロセスです。クライアントが認証されたら、「Request_URI」を取得するために要求オブジェクトを信頼できるサードパーティサービスにプッシュするためのクライアント認証情報が発行されます。
(2) (Translation Process) The client uses the client credential that it got to push the Request Object to the trusted third-party service to get the "request_uri". The trusted third-party service also verifies that the Request Object is consistent with the claims that the client is eligible for, per the prior step.
(2) （翻訳プロセス）クライアントは、リクエストオブジェクトを信頼できるサードパーティサービスにプッシュして "Request_uri"を取得するようになったクライアント資格情報を使用します。信頼できるサードパーティサービスはまた、要求オブジェクトが、クライアントが以前のステップごとに適格であるというクレームと一致していることを確認します。
Upon receiving such a Request Object URI in the authorization request, the authorization server first verifies that the authority portion of the Request Object URI is a legitimate one for the trusted third-party service. Then, the authorization server issues an HTTP GET request to the Request Object URI. Upon connecting, the authorization server MUST verify that the server identity represented in the TLS certificate is legitimate for the Request Object URI. Then, the authorization server can obtain the Request Object, which includes the "client_id" representing the client.
許可要求においてそのような要求オブジェクトURIを受信すると、許可サーバは、最初に、要求オブジェクトURIの権限部分が信頼できる第三者サービスのための正当なものであることを検証する。その後、許可サーバーは要求オブジェクトURIにHTTP GET要求を発行します。接続すると、許可サーバーは、TLS証明書に表されるサーバーIDがRequestオブジェクトURIの正当なものであることを確認する必要があります。そして、許可サーバは、クライアントを表す「client_id」を含む要求オブジェクトを取得することができる。
The Consent screen MUST indicate the client and SHOULD indicate that the request has been vetted by the trusted third-party service for the adherence to the collection limitation principle.
同意画面はクライアントを示す必要があり、その要求が収集制限の原則を遵守するために信頼できる第三者サービスによって吟味されたことを示すべきです。
This specification allows extension parameters. These may include potentially sensitive information. Since URI query parameters may leak through various means but most notably through referrer and browser history, if the authorization request contains a potentially sensitive parameter, the client SHOULD encrypt the Request Object using JWE [RFC7516].
この仕様では拡張パラメータを使用できます。これらは潜在的に敏感な情報を含み得る。URIクエリパラメータは様々な手段を介して漏洩する可能性があるので、承認要求に潜在的に機密なパラメータを含む場合、クライアントはJWE [RFC7516]を使用して要求オブジェクトを暗号化する必要があります。
Where the Request Object URI method is being used, if the Request Object contains personally identifiable or sensitive information, the "request_uri" SHOULD be used only once and have a short validity period, and it MUST have sufficient entropy for the applicable security policies unless the Request Object itself is encrypted using JWE [RFC7516]. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute, and the Request Object URI is to include a cryptographic random value of 128 bits or more at the time of the writing of this specification.
要求オブジェクトURIメソッドが使用されている場合、要求オブジェクトに個人的に識別可能または機密情報が含まれている場合は、「request_uri」を1回だけ使用し、短信期間が短く、短い有効期間が必要である必要があります。要求オブジェクト自体はJWE [RFC7516]を使用して暗号化されています。妥当性の適切な短さと要求オブジェクトURIのエントロピーは、保護されているリソースの値に基づくリスク計算に依存します。有効期間の一般的なガイダンスは1分未満になり、この仕様書の書き込み時に要求オブジェクトURIは128ビット以上の暗号ランダム値を含むことになる。
Even if the protected resource does not include personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent static per-user Request Object URIs are used. A third party may observe it through browser history, etc. and start correlating the user's activity using it. In a way, it is a data disclosure as well and should be avoided.
保護されたリソースに個人識別可能な情報が含まれていなくても、ユーザの要求オブジェクトURIごとに永続的な静的な場合は、要求オブジェクトURIを介してユーザを識別することが可能である。第三者は、ブラウザの履歴などを通してそれを観察し、それを使用してユーザーの活動を相関させることができる。ある意味では、データ開示も同様に避けるべきです。
Therefore, per-user persistent Request Object URIs should be avoided. Single-use Request Object URIs are one alternative.
したがって、ユーザーごとの永続要求オブジェクトURIを回避する必要があります。単一使用要求オブジェクトURIは1つの代替案です。
[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>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[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>。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.
[RFC6750] Jones、M.およびD. Hardt、「OAuth 2.0認証フレームワーク：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<https：//www.rfc-editor.org/info/RFC6750>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[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/info/rfc7515>.
[RFC7515] Jones、M.、Bradley、J.、およびN.Sakimura、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https：//www.rfc-editor.org/ info / rfc7515>。
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516] Jones、M.およびJ.Hildebrand、「JSON Web暗号化（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<https：//www.rfc-editor.org/info/rfc7516>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518] Jones、M.、 "JSON Web Algorithms（JWA）"、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<https：//www.rfc-editor.org/info/rfc7518>。
[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>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8141] Saint-Andre、P.およびJ.Klensin、「ユニフォームリソース名（URNS）」、RFC 8141、DOI 10.17487 / RFC8141、2017年4月、<https：//www.rfc-editor.org/info/rfc8141>。
[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>。
[BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication", Journal of Computer Security - Security and Trust Principles, Volume 21, Issue 6, pp. 817-846, November 2013, <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/ papers/BCM2012-iso9798.pdf>.
[盆地]洗面台、D.、クレマー、C.およびS.Meier、「事業体認証のためのISO / IEC 9798規格」、コンピュータセキュリティジャーナル - セキュリティと信頼の原則、第21巻、PP。2013年11月、<https://www.cs.ox.ac.uk/people/cas.cas.cas.cremers/downloads/papers / bcm2012-iso9798.pdf>。
[CapURLs] Tennison, J., Ed., "Good Practices for Capability URLs", W3C First Public Working Draft, 18 February 2014, <https://www.w3.org/TR/capability-urls/>.
[Capurls] Tennison、J.、ED。、「機能URLのための良い慣行」、2014年2月18日、<https://www.w3.org/tr/capability-urls/>
[IANA.JWT.Claims] IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.
[IANA.JWT.CLAMS] IANA、「JSON WEB TOKEN（JWT）」、<https：//www.iana.org/assignments/jwt>。
[IANA.MediaTypes] IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[IANA.MEDIATYPES] IANA、「メディアタイプ」、<https：//www.iana.org/assignments/media-types>。
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[iana.oauth.parameters] IANA、 "OAUTHパラメータ"、<https：//www.iana.org/ashignments/oauth-parameters>。
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", OpenID Foundation Standards, 8 November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.CORE] SAKIMURA、N.、Bradley、J.、Jones、MB、De Medeiros、B.、Mortimore、「OpenID Connect Core 1.0 Erorata Set 1」、OpenID Foundation Standards、2014年11月8日、<http://openid.net/specs/openid-connect-core-1_0.html>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N.およびN.Borenstein、「MultiPurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https：//www.rfc-editor.org/ info / rfc2046>。
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6819] LodderStedt、T.、Ed。、McGloin、M.、およびP. Hunt、 "OAUTH 2.0脅威モデルおよびセキュリティ上の考慮事項"、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<https：//www.rfc-editor.org/info/rfc6819>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[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>。
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/info/rfc8725>.
[RFC8725] Sheffer、Y.、Hardt、D.、およびM. Jones、「JSON WebトークンBEST Current Practices」、BCP 225、RFC 8725、DOI 10.17487 / RFC8725、2020年2月、<https：///www.rfc-editor.org/info/rfc8725>。
Acknowledgements
謝辞
The following people contributed to the creation of this document in the OAuth Working Group and other IETF roles. (Affiliations at the time of the contribution are used.)
以下の人は、OAuthワーキンググループおよびその他のIETFロールでこの文書の作成に貢献しました。（貢献時の所属は使用されます。）
Annabelle Backman (Amazon), Dirk Balfanz (Google), Sergey Beryozkin, Ben Campbell (as AD), Brian Campbell (Ping Identity), Roman Danyliw (as AD), Martin Duke (as AD), Vladimir Dzhuvinov (Connect2id), Lars Eggert (as AD), Joel Halpern (as GENART), Benjamin Kaduk (as AD), Stephen Kent (as SECDIR), Murray Kucherawy (as AD), Warren Kumari (as OPSDIR), Watson Ladd (as SECDIR), Torsten Lodderstedt (yes.com), Jim Manico, James H. Manger (Telstra), Kathleen Moriarty (as AD), Axel Nennker (Deutsche Telecom), John Panzer (Google), Francesca Palombini (as AD), David Recordon (Facebook), Marius Scurtescu (Google), Luke Shepard (Facebook), Filip Skokan (Auth0), Hannes Tschofenig (ARM), Éric Vyncke (as AD), and Robert Wilton (as AD).
Annabelle Backman（Amazon）、Dirk Balfanz（Google）、Sergey Beryozkin、Ben Campbell（ADとして）、Brian Campbell（Ping Identity）、ローマDanyLiw（ADとして）、Martin Duke（ADとして）、Vladimir Dzhuvinov（Connect2ID）、LARSeggert（ADとして）、Joel Halpern（Genartとして）、Benjamin Kaduk（ADとして）、スティーブンケント（Secdir）、Murray Kucherawy（AD）、Warren Kumari（opsdir）、Watson Laddttedt（yes.com）、Jim Manico、James H. Manger（Telstra）、Kathleen Moriarty（ADとして）、Axel Nennker（Deutsche Telecom）、John Panzer（Google）、Francesca Palombini（ADとして）、David Recordon（Facebook）、Marius Skurtescu（Google）、Luke Shepard（Facebook）、Filip Skokan（AUT0）、Hannes Tschofenig（ARM）、ÉricVyncke（AD）、およびRobert Wilton（AD）。
The following people contributed to creating this document through the OpenID Connect Core 1.0 [OpenID.Core].
以下の人々は、OpenID Connect Core 1.0 [OpenID.Core]を介してこの文書の作成に貢献しました。
Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou (Mixi), Edmund Jay (Illumila), Breno de Medeiros (Google), Hideki Nara (TACT), and Justin Richer (MITRE).
Brian Campbell（Ping Identity）、George Fletcher（AOL）、Ryo Itou（Mixi）、Edmund Jay（Illumila）、Breno de Medeiros（Google）、Nara（Tact）、Justin Richer（Miter）。
Authors' Addresses
著者の住所
Nat Sakimura NAT.Consulting 2-22-17 Naka Kunitachi, Tokyo 186-0004 Japan
Nat Sakimura Nat.Consulting 2-22-17東京186-0004日本
Phone: +81-42-580-7401
Email: nat@nat.consulting
URI: https://nat.sakimura.org/
John Bradley Yubico Sucursal Talagante Casilla 177 Talagante RM Chile
John Bradley Yubico Supural Talagante Casilla 177 Talagante RMチリ
Phone: +1.202.630.5272
Email: rfc9101@ve7jtb.com
URI: http://www.thread-safe.com/
Michael B. Jones Microsoft One Microsoft Way Redmond, Washington 98052 United States of America
Michael B. Jones Microsoft One Microsoft Way Redmond、ワシントン98052アメリカ合衆国
Email: mbj@microsoft.com
URI: https://self-issued.info/