RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9207.html
タイトル : RFC 9207 - OAuth 2.0承認サーバー発行者識別情報
翻訳編集 : 自動生成

[要約] RFC 9207は、OAuth 2.0認証フレームワークにおける認証サーバーの発行者識別に関するものです。この文書の目的は、OAuth 2.0認証サーバーが自身を一意に識別するための方法を定義することにあります。これは、セキュリティ上の理由から、クライアントが正しい認証サーバーと通信していることを確認するために重要です。利用場面としては、OAuth 2.0を使用するあらゆるアプリケーションやサービスでの認証プロセスが挙げられます。関連するRFCには、OAuth 2.0を定義するRFC 6749や、OAuth 2.0のセキュリティに関するベストプラクティスを扱うRFC 6819などがあります。

Internet Engineering Task Force (IETF)             K. Meyer zu Selhausen
Request for Comments: 9207                                     Hackmanit
Category: Standards Track                                        D. Fett
ISSN: 2070-1721                                                  yes.com
                                                              March 2022

OAuth 2.0 Authorization Server Issuer Identification

OAuth 2.0承認サーバー発行者識別情報

Abstract

概要

This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks".

このドキュメントはISSと呼ばれる新しいパラメータを指定します。このパラメータは、OAuth承認フローの許可応答に承認サーバーの発行者識別子を明示的に含めるために使用されます。ISSパラメータは、「ミックスアップ攻撃」に対する効果的な対策として機能します。

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/rfc9207.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9207で入手できます。

著作権表示

著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。

Table of Contents

   1.  Introduction
     1.1.  Conventions and Terminology
   2.  Response Parameter iss
     2.1.  Example Authorization Response
     2.2.  Example Error Response
     2.3.  Providing the Issuer Identifier
     2.4.  Validating the Issuer Identifier
   3.  Authorization Server Metadata
   4.  Security Considerations
   5.  IANA Considerations
     5.1.  OAuth Authorization Server Metadata
     5.2.  OAuth Parameters Registration
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The OAuth 2.0 Authorization Framework [RFC6749] allows clients to interact with multiple independent authorization servers under the control of separate entities. Some OAuth grant types utilize the resource owner's user agent to deliver the authorization server's response to the OAuth client. One example of this pattern is the authorization response of the authorization code grant.

OAuth 2.0承認フレームワーク[RFC6749]は、クライアントが別々のエンティティの制御下で複数の独立した許可サーバーと対話することができます。一部のOAuth Grantタイプは、OAuthクライアントへの許可サーバーの応答を配信するために、リソース所有者のユーザーエージェントを利用しています。このパターンの一例は、認証コード許可の許可応答です。

The authorization response as specified in Section 4.1.2 of [RFC6749] does not contain any information about the identity of the authorization server that issued the response. Therefore, clients receiving a response from the resource owner's user agent cannot be sure who initially issued the response and the secrets contained therein. The lack of certainty about the origin of the response enables a class of attacks called "mix-up attacks".

[RFC6749]のセクション4.1.2で指定されている認証応答には、応答を発行した認証サーバーのIDに関する情報は含まれていません。したがって、リソース所有者のユーザーエージェントからの応答を受信したクライアントは、最初に応答とその中に含まれている秘密を確実に発行することはできません。応答の起源についての確実性の欠如は、「ミックスアップ攻撃」と呼ばれる攻撃のクラスを可能にします。

Mix-up attacks are a potential threat to all OAuth clients that interact with multiple authorization servers. When at least one of these authorization servers is under an attacker's control, the attacker can launch a mix-up attack to acquire authorization codes or access tokens issued by any one of the other authorization servers. There are multiple ways in which an attacker can gain control over an authorization server supported by the client; for instance, an authorization server could become compromised, or the attacker could register their own authorization server, for example, using dynamic client registration [RFC7591].

ミックスアップ攻撃は、複数の許可サーバーと対話するすべてのOAuthクライアントに対する潜在的な脅威です。これらの許可サーバーのうちの少なくとも1つが攻撃者の制御下にあるとき、攻撃者は混合攻撃を起動して、他の認可サーバーのいずれかによって発行された許可コードまたはアクセストークンを取得することができます。攻撃者がクライアントでサポートされている認証サーバーを制御することができる複数の方法があります。たとえば、承認サーバーが侵害される可能性があるか、または攻撃者が動的クライアント登録[RFC7591]を使用して、自分の許可サーバーを登録できる可能性があります。

OAuth clients that interact with only one authorization server are not vulnerable to mix-up attacks. However, when such clients decide to add support for a second authorization server in the future, they become vulnerable and need to apply countermeasures to mix-up attacks.

OAuthクライアントは、1つの許可サーバーだけと対話するクライアントは、ミックスアップ攻撃に対して脆弱ではありません。ただし、そのようなクライアントが将来2回目の承認サーバーのサポートを追加することにした場合、それらは脆弱になり、混合攻撃に対策を適用する必要があります。

Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe threat to the confidentiality and integrity of resources whose access is managed with OAuth. A detailed description and different variants of the mix-up attack class can be found in Section 4.4 of "OAuth 2.0 Security Best Current Practice" [OAUTH-SECURITY-TOPICS] as well as in the original research first highlighting this attack class, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] and "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].

ミックスアップ攻撃は、正直な許可またはリソースサーバーではなく、承認コードまたはアクセストークンを攻撃者に送信するためにクライアントをトリックすることで、認証コードまたはアクセストークンを盗むことを目的としています。これは、アクセスがOAuthで管理されているリソースの機密性と完全性に対する深刻な脅威を示しています。ミックスアップ攻撃クラスの詳細な説明とさまざまな亜種は、「OAuth 2.0セキュリティ最優秀現在の実践」の4.4セクション4.4であります。現代のシングルサインオンプロトコルのセキュリティ：OpenID Connectの2次脆弱性「[ARXIV.1508.04324]と「OAuth 2.0の包括的な正式セキュリティ分析」[ARXIV.1601.01229]。

This document defines a new parameter in the authorization response called iss. The iss parameter allows the authorization server to include its identity in the authorization response explicitly. The client can compare the value of the iss parameter to the issuer identifier of the authorization server (e.g., retrieved from its metadata) it believes it is interacting with. The iss parameter gives the client certainty about the authorization server's identity and enables it to send credentials such as authorization codes and access tokens only to the intended recipients.

このドキュメントは、ISSという認証応答に新しいパラメータを定義します。ISSパラメータを使用すると、許可サーバーは認可応答に明示的にそのIDを含めることができます。クライアントは、ISSパラメータの値を許可サーバの発行者識別子（例えば、そのメタデータから取得された）とを比較することができると考えている。ISSパラメータは、許可サーバーのIDに関するクライアントの確実性を与え、許可コードやアクセストークンなどの認証情報を意図した受信者にのみ送信できます。

The effectiveness of the iss parameter against mix-up attacks was analyzed and formally proven in "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].

ミックスアップ攻撃に対するISSパラメータの有効性は、「OAuth 2.0の包括的な正式なセキュリティ分析」で分析し、正式に証明されました[ARXIV.1601.01229]。

1.1. Conventions and Terminology

1.1. 表記法と用語

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 code", "authorization code grant", "authorization server", "resource server", "authorization response", "grant type", and "client" defined by the OAuth 2.0 Authorization Framework [RFC6749]. The term "issuer identifier" is defined by OAuth 2.0 Authorization Server Metadata [RFC8414].

本明細書は、「アクセストークン」、「認可コード」、「承認コード付与」、「承認サーバ」、「承認応答」、「許可応答」、「付与タイプ」、および「クライアント」、「クライアント」をOAuth 2.0で定義しています。承認フレームワーク[RFC6749]。「発行者識別子」という用語は、OAuth 2.0許可サーバーメタデータ[RFC8414]によって定義されています。

2. Response Parameter iss

2. 応答パラメータISS

In authorization responses to the client, including error responses, an authorization server supporting this specification MUST indicate its identity by including the iss parameter in the response.

エラー応答を含むクライアントへの許可応答において、この仕様をサポートする認証サーバーは、ISSパラメータを応答に含めることによってそのアイデンティティを示している必要があります。

The iss parameter value is the issuer identifier of the authorization server that created the authorization response, as defined in [RFC8414]. Its value MUST be a URL that uses the "https" scheme without any query or fragment components.

ISSパラメータ値は、[RFC8414]で定義されているように、許可応答を作成した認証サーバーの発行者識別子です。その値は、クエリまたはフラグメントコンポーネントなしで "https"スキームを使用するURLでなければなりません。

2.1. Example Authorization Response

2.1. 承認応答の例

The following example shows an authorization response from the authorization server whose issuer identifier is https://honest.as.example (extra line breaks and indentation are for display purposes only):

次の例は、発行者識別子がhttps：//honest.as.exampleの承認サーバーからの許可応答を示しています（余分なラインブレークとインデントは表示目的のみです）。

   HTTP/1.1 302 Found
   Location: https://client.example/cb?
     code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
     &state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
     &iss=https%3A%2F%2Fhonest.as.example

2.2. Example Error Response

2.2. エラー応答の例

The following example shows an error response from the same authorization server (extra line breaks and indentation are for display purposes only):

次の例は、同じ認証サーバーからのエラー応答（余分なラインブレークとインデントは表示目的のみのためのものです）を示しています。

   HTTP/1.1 302 Found
   Location: https://client.example/cb?
     error=access_denied
     &state=N2JjNGJhY2JiZjRhYzA3MGJkMzNmMDE5OWJhZmJhZjA
     &iss=https%3A%2F%2Fhonest.as.example

2.3. Providing the Issuer Identifier

2.3. 発行者識別子を提供する

Authorization servers supporting this specification MUST provide their issuer identifier to enable clients to validate the iss parameter effectively.

この仕様をサポートする認証サーバーは、クライアントがISSパラメータを効果的に検証できるようにするために発行者識別子を提供する必要があります。

For authorization servers publishing metadata according to [RFC8414], the following rules apply:

[RFC8414]に従ってメタデータを公開する認証サーバーの場合、以下の規則が適用されます。

* The issuer identifier included in the server's metadata value issuer MUST be identical to the iss parameter's value.

* サーバのメタデータ値発行者に含まれる発行者識別子は、ISSパラメータの値と同じでなければなりません。

* The server MUST indicate its support for the iss parameter by setting the metadata parameter authorization_response_iss_parameter_supported, defined in Section 3, to true.

* サーバーは、セクション3で定義されているMetadataパラメータauthorization_response_iss_parameter_supportedを設定することによって、ISSパラメータのサポートを示している必要があります。

Authorization servers MAY additionally provide the issuer identifier to clients by any other mechanism, which is outside of the scope of this specification.

許可サーバーは、この仕様の範囲外である他のメカニズムによって、発行者識別子を他のメカニズムによってクライアントに提供することができます。

2.4. Validating the Issuer Identifier

2.4. 発行者識別子を検証する

Clients that support this specification MUST extract the value of the iss parameter from authorization responses they receive if the parameter is present. Clients MUST then decode the value from its "application/x-www-form-urlencoded" form according to Appendix B of [RFC6749] and compare the result to the issuer identifier of the authorization server where the authorization request was sent to. This comparison MUST use simple string comparison as defined in Section 6.2.1 of [RFC3986]. If the value does not match the expected issuer identifier, clients MUST reject the authorization response and MUST NOT proceed with the authorization grant. For error responses, clients MUST NOT assume that the error originates from the intended authorization server.

この仕様をサポートするクライアントは、パラメータが存在する場合に受信した許可応答からISSパラメータの値を抽出する必要があります。その後、クライアントは[RFC6749]の付録Bに従って、その結果を「Application / X-WWW-orm-urlencoded」フォームからデコードし、許可要求が送信された認証サーバーの発行者識別子に結果を比較する必要があります。この比較は、[RFC3986]の6.2.1項で定義されている単純な文字列比較を使用する必要があります。値が予想される発行者識別子と一致しない場合、クライアントは許可応答を拒否し、認証許可を続行しないでください。エラー応答の場合、クライアントはエラーが意図された許可サーバーから発生してはいけません。

More precisely, clients that interact with authorization servers supporting OAuth metadata [RFC8414] MUST compare the iss parameter value to the issuer value in the server's metadata document. If OAuth metadata is not used, clients MUST use deployment-specific ways (for example, a static configuration) to decide if the returned iss value is the expected value in the current flow (see also Section 4).

より正確には、OAuthメタデータ[RFC8414]をサポートする認可サーバと対話するクライアントは、ISSパラメータ値をサーバのメタデータ文書内の発行者値と比較する必要があります。OAuthメタデータが使用されていない場合、クライアントは展開固有の方法（たとえば、静的設定）を使用して、返されたIS値が現在のフローの期待値であるかどうかを決定する必要があります（セクション4も参照）。

If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients MUST retain state about whether each authorization server supports the iss parameter. Clients MUST reject authorization responses without the iss parameter from authorization servers that do support the parameter according to the client's configuration. Clients SHOULD discard authorization responses with the iss parameter from authorization servers that do not indicate their support for the parameter. However, there might be legitimate authorization servers that provide the iss parameter without indicating their support in their metadata. Local policy or configuration can determine whether to accept such responses, and specific guidance is out of scope for this specification.

この仕様をサポートしていないこの仕様および許可サーバーをサポートする両方の許可サーバーとの両方の許可サーバーと対話する場合、クライアントは各許可サーバーがISSパラメータをサポートするかどうかについての状態を保持する必要があります。クライアントは、クライアントの設定に従ってパラメータをサポートしている許可サーバーからISSパラメータなしで認証応答を拒否する必要があります。クライアントは、パラメータのサポートを示さない認証サーバーからのISSパラメータとの許可応答を廃棄する必要があります。ただし、Metadataでのサポートを示すことなく、ISSパラメータを提供する正当な許可サーバーがあるかもしれません。ローカルポリシーまたは構成は、そのような応答を受け入れるかどうかを判断でき、特定のガイダンスはこの仕様の範囲外です。

In general, clients that support this specification MAY accept authorization responses that do not contain the iss parameter or reject them and exclusively support authorization servers that provide the iss parameter in the authorization response. Local policy or configuration can determine when to accept such responses, and specific guidance is out of scope for this specification.

一般に、この仕様をサポートするクライアントは、ISSパラメータを含まない、またはそれらを拒否して、isSutivation応答にISSパラメータを提供する認証サーバーを排他的にサポートする認証応答を受け付けます。ローカルポリシーまたは設定は、そのような応答を受け入れるかを決定することができ、そして特定のガイダンスはこの仕様に対して範囲外です。

In OpenID Connect [OIDC.Core] flows where an ID Token is returned from the authorization endpoint, the value in the iss parameter MUST always be identical to the iss claim in the ID Token.

OpenID Connect [OIDC.CORE] Flowsが許可エンドポイントから返される場合、ISSパラメータの値は常にIDトークンのISSクレームと同じでなければなりません。

Section 4.1.2 of [RFC6749] already mandates that clients that do not support this specification MUST ignore the unrecognized iss parameter.

[RFC6749]のセクション4.1.2では、この仕様をサポートしていないクライアントが未認識のISSパラメータを無視する必要があります。

Note: The "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)" [JARM] defines a mechanism that conveys all authorization response parameters in a JSON Web Token (JWT). This JWT contains an iss claim that provides the same protection if it is validated as described in Section 2.4. Therefore, an additional iss parameter outside the JWT is not necessary when JARM is used.

注：「OAuth 2.0（JARM）のJWT保護許可応答モード[JARM]は、JSON Webトークン（JWT）内のすべての許可応答パラメータを伝達するメカニズムを定義します。このJWTには、セクション2.4で説明されているように検証されている場合に同じ保護を提供するISSクレームが含まれています。したがって、JARMが使用されている場合、JWTの外側の追加のISSパラメータは必要ありません。

3. Authorization Server Metadata

3. 許可サーバーメタデータ

The following parameter for the authorization server metadata [RFC8414] is introduced to signal the authorization server's support for this specification:

認可サーバーメタデータの次のパラメータ[RFC8414]がこの仕様に対する認証サーバーのサポートを送信するために導入されました。

authorization_response_iss_parameter_supported: Boolean parameter indicating whether the authorization server provides the iss parameter in the authorization response as defined in Section 2. If omitted, the default value is false.

authorization_response_iss_parameter_supported：承認サーバーがセクション2で定義されているように認可応答にISSパラメーターを提供するかどうかを示すBooleanパラメータは、省略された場合、デフォルト値はfalseです。

4. Security Considerations

4. セキュリティに関する考慮事項

Clients MUST validate the iss parameter precisely as described in Section 2.4 and MUST NOT allow multiple authorization servers to use the same issuer identifier. In particular, when authorization server details can be manually configured in the client, the client MUST ensure that the accepted iss values are unique for each authorization server.

クライアントはSection 2.4で説明されているようにISSパラメータを正確に検証する必要があり、複数の許可サーバーが同じ発行者識別子を使用できるようにする必要があります。特に、許可サーバーの詳細をクライアントで手動で設定できる場合、クライアントは認証されたIS値が各許可サーバーに対して一意であることを確認する必要があります。

The iss parameter enables a client to decide if an authorization server "expects" to be used in an OAuth flow together with a certain token endpoint and potentially other endpoints, like the userinfo endpoint [OIDC.Core]. When OAuth metadata is used, the iss parameter identifies the issuer and therefore the respective OAuth metadata document that points to the other endpoints. When OAuth metadata is not used, the client can use, for example, a statically configured expected iss value for each configured authorization server.

ISSパラメータを使用すると、userInfoエンドポイント[OIDC.CORE]のように、特定のトークンエンドポイントと潜在的に他のエンドポイントとともに、許可サーバーがOAuthフローで使用されることを許可サーバーが「期待」するかどうかを決定できます。OAuthメタデータが使用されるとき、ISSパラメータは発行者、したがって他のエンドポイントを指すそれぞれのOAuthメタデータ文書を識別します。OAuthメタデータが使用されていない場合、クライアントは、設定された各許可サーバーに対して、たとえば、静的に設定された予想されるIS値を使用できます。

The issuer identifier contained in the authorization response is not cryptographically protected against tampering. In general, mechanisms such as JWTs (as specified in [JARM]) could be used to protect the integrity of the authorization response. However, in mix-up attacks, the client generally receives the authorization response from an uncompromised authorization server. If an attacker can tamper with this authorization response before it is received by the client, the attacker would also have direct access to the authorization code. The attacker does not need to execute a mix-up attack to steal the authorization code. Therefore, integrity protection for the authorization response is not necessary to defend against mix-up attacks.

許可応答に含まれる発行者識別子は、改ざんから暗号的に保護されていません。一般に、JWT（[JARM]で指定されている）などのメカニズムを使用して、許可応答の整合性を保護することができます。ただし、ミックスアップ攻撃では、クライアントは一般に、妥協のない許可サーバーからの許可応答を受け取ります。攻撃者がクライアントによって受信される前にこの許可応答を改ざんすることができる場合、攻撃者は認証コードに直接アクセスすることもできます。攻撃者は、認証コードを盗むためにミックスアップ攻撃を実行する必要はありません。したがって、認可応答に対する完全性保護は、ミックスアップ攻撃に対して守る必要はありません。

There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means and this identifier is checked as laid out in Section 2.4, the use and verification of the iss parameter is not necessary and MAY be omitted. For example, this is the case when OpenID Connect response types that return an ID Token from the authorization endpoint (e.g., response_type=code id_token) or [JARM] are used. However, if a client receives an authorization response that contains multiple issuer identifiers, the client MUST reject the response if these issuer identifiers do not match. The details of alternative countermeasures are outside of the scope of this specification.

混合攻撃への代替対策もあります。許可応答が他の手段で既に認可サーバーの発行者識別子を含んでいて、この識別子をセクション2.4でレイアウトされているとチェックされている場合、ISSパラメータの使用と検証は必要ではなく、省略される可能性があります。たとえば、認証エンドポイントからIDトークンを返すOpenID Connectレスポンスタイプ（例えば、response_type =コードID_TOKEN）または[JARM]が使用されている場合です。ただし、クライアントが複数の発行者識別子を含む認証応答を受信した場合、これらの発行者識別子が一致しない場合、クライアントは応答を拒否する必要があります。代替対策の詳細は、本明細書の範囲外です。

Mix-up attacks are only relevant to clients that interact with multiple authorization servers. However, clients interacting with only one authorization server might add support for a second authorization server in the future. By supporting multiple authorization servers, they become vulnerable to mix-up attacks and need to apply countermeasures.

ミックスアップ攻撃は、複数の許可サーバーと対話するクライアントにのみ関連しています。ただし、1つの許可サーバーと対話するクライアントは、将来2回目の許可サーバーのサポートを追加する可能性があります。複数の許可サーバーをサポートすることによって、それらはミックスアップ攻撃に対して脆弱になり、対策を適用する必要があります。

5. IANA Considerations

5. IANAの考慮事項

5.1. OAuth Authorization Server Metadata

5.1. OAuth認証サーバーメタデータ

IANA has registered the following value in the "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Parameters] established by [RFC8414].

IANAは、[RFC8414]によって確立された[iana.oauth.parameters]の「OAuth認証サーバーメタデータ」に次の値を登録しました。

Metadata Name: authorization_response_iss_parameter_supported Metadata Description: Boolean value indicating whether the authorization server provides the iss parameter in the authorization response. Change Controller: IETF Specification Document(s): Section 3 of RFC 9207

メタデータ名：authorization_response_iss_parameter_supportedメタデータ説明：許可サーバーが許可応答にISSパラメータを提供するかどうかを示すブール値。変更コントローラ：IETF仕様書：RFC 9207のセクション3

5.2. OAuth Parameters Registration

5.2. OAuthパラメータ登録

IANA has updated the iss entry to appear as follows in the "OAuth Parameters" registry of [IANA.OAuth.Parameters] established by [RFC6749].

IANAは、[RFC6749]によって確立された[IANA.OAUTH.PARAMETERS]の「OAuthパラメータ」レジストリに次のように表示されるように表示されました。

Parameter name: iss Parameter usage location: authorization request, authorization response Change Controller: IETF Specification Document(s): Section 2 of RFC 9207, [RFC9101], and Section 4.1.1 of [RFC7519].

パラメータ名：ISSパラメータ使用場所：承認要求、承認応答変更コントローラ：IETF仕様書：RFC 9207、[RFC9101]、および[RFC7519]のセクション4.1.1。

6. References

6. 参考文献

6.1. Normative References

6.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、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[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>。

[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>。

[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>。

6.2. Informative References

6.2. 参考引用

[arXiv.1508.04324] Mainka, C., Mladenov, V., and J. Schwenk, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect", August 2015, <https://arxiv.org/abs/1508.04324>.

[ARXIV.1508.04324] Mainka、C、Mladenov、V.およびJ.Schwenk、「現代のシングルサインオンプロトコルのセキュリティについて：OpenID Connectのセカンド次の脆弱性」、2015年8月、<https：// arxiv.ORG / ABS / 1508.04324>。

[arXiv.1601.01229] Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive Formal Security Analysis of OAuth 2.0", DOI 10.1145/2976749.2978385, January 2016, <https://arxiv.org/abs/1601.01229>.

[ARXIV.1601.01229] FETS、D.、Kuesters、R.、G.Schmitz、「OAuth 2.0の包括的な正式なセキュリティ分析」、2016年1月、2016年1月、<https://arxiv.org/abs/1601.01229>。

[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.

[IANA.OAUTH.PARAMETERS] IANA、 "OAUTHパラメータ"、<https：//www.iana.org/assignments/oauth-parameters>。

[JARM] Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)", October 2018, <https://openid.net/specs/openid-financial-api-jarm.html>.

[JARM] LodderStedt、T.およびB.Campbell、2018年10月、2018年10月、<https：//openid.net/specs/openid-financial-API-jarm.html>。

[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-19, 16 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19>.

[OAuth-Security-Topics] LodderStedt、T.、Bradley、J.、Labunets、A.、D. FETT、「OAuth 2.0セキュリティBEST現在の実践」、進行中の作業、インターネットドラフト、ドラフトIETF-OAUTH-Security-Topics-19、2021年12月16日、<https：//datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-topics-topics-topics-

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

[OIDC.CORE] SAKIMURA、N.、Bradley、J.、Jones、M.、De Medeiros、B.、Mortimore、Mortimore、2014年11月11日、<https：//openid.net/specs/openid-connect-core-1_0.html>。

[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]ジョーンズ、M.、Bradley、J.、およびSakimura、「JSON Webトークン（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https：//www.rfc-editor.org/ info / rfc7519>。

[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>。

[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] SAKIMURA、N.、Bradley、J.、M. Jones、「OAuth 2.0認証フレームワーク：JWT担保認証要求（JAR）」、RFC 9101、DOI 10.17487 / RFC9101、<https：//www.rfc-editor.org/info/rfc9101>。

Acknowledgements

謝辞

We would like to thank Brian Campbell, Roman Danyliw, Vladimir Dzhuvinov, Joseph Heenan, Takahiko Kawasaki, Torsten Lodderstedt, Christian Mainka, Vladislav Mladenov, Warren Parad, Aaron Parecki, and Rifaat Shekh-Yusef for their valuable feedback on this document.

Brian Campbell、Roman Danyliw、Vladimir Dzhuvinov、Joseph Heenan、Kawahiko Kawahiko、Torsten Lodderstedt、Vladislav Mladenov、Warran Parad、Aaron Parcki、Rifaat Shekh-Yusef、Rifaat Shekh-Yusefこの文書でございます。

Authors' Addresses

著者の住所

Karsten Meyer zu Selhausen Hackmanit Email: karsten.meyerzuselhausen@hackmanit.de

Karsten Meyer Zu Selhausen Hackmanitメール：karsten.meyerzuselhausen@hackmanit.de.

Daniel Fett yes.com Email: mail@danielfett.de

Daniel Fett yes.comメール：mail@danielfett.de.