Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 9560 Verisign Labs
Category: Standards Track April 2024
ISSN: 2070-1721
The Registration Data Access Protocol (RDAP) provides Representational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect.
登録データアクセスプロトコル（RDAP）は、ドメイン名と地域のインターネットレジストリから登録メタデータを取得するための代表的な状態転送（RESTFUL）Webサービスを提供します。RDAPを使用すると、サーバーはクライアントのIDに基づいてアクセス制御の決定を行うことができます。そのため、HyperText Transfer Protocol（HTTP）が提供するクライアント識別機能のサポートが含まれます。クライアントがすべてのRDAPサーバーオペレーターから資格情報を取得および管理する必要がある識別方法は、クライアントとサーバーの両方に管理の課題を提示しますが、フェデレート認証システムは、サーバー固有のクライアント資格情報を維持する必要なくRDAPの操作と使用を容易にします。このドキュメントでは、OpenID Connectに基づいたRDAP用のフェデレート認証システムについて説明します。
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/rfc9560.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9560で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Problem Statement
1.2. Approach
2. Conventions Used in This Document
3. Federated Authentication for RDAP
3.1. RDAP and OpenID Connect
3.1.1. Terminology
3.1.2. Client Considerations
3.1.3. Overview
3.1.4. RDAP Authentication and Authorization Steps
3.1.4.1. Provider Discovery
3.1.4.2. Authentication Request
3.1.4.3. End User Authorization
3.1.4.4. Authorization Response and Validation
3.1.4.5. Token Processing
3.1.4.6. Delivery of User Information
3.1.5. Specialized Claims and Authorization Scope for RDAP
3.1.5.1. Stated Purposes
3.1.5.2. Do Not Track
4. Common Protocol Features
4.1. OpenID Connect Configuration
4.2. RDAP Query Parameters
4.2.1. RDAP Query Purpose
4.2.2. RDAP Do Not Track
4.2.3. Parameter Processing
5. Protocol Features for Session-Oriented Clients
5.1. Data Structures
5.1.1. Session
5.1.2. Device Info
5.2. Client Login
5.2.1. End-User Identifier
5.2.2. OP Issuer Identifier
5.2.3. Login Response
5.2.4. Clients with Limited User Interfaces
5.2.4.1. UI-Constrained Client Login
5.2.4.2. UI-Constrained Client Login Polling
5.3. Session Status
5.4. Session Refresh
5.5. Client Logout
5.6. Request Sequencing
6. Protocol Features for Token-Oriented Clients
6.1. Client Login
6.2. Client Queries
6.3. Access Token Validation
6.4. Token Exchange
7. RDAP Query Processing
8. RDAP Conformance
9. IANA Considerations
9.1. RDAP Extensions Registry
9.2. JSON Web Token Claims Registry
9.3. RDAP Query Purpose Registry
10. Security Considerations
10.1. Authentication and Access Control
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
The Registration Data Access Protocol (RDAP) provides Representational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP) [RFC9110].
登録データアクセスプロトコル（RDAP）は、ドメイン名と地域のインターネットレジストリから登録メタデータを取得するための代表的な状態転送（RESTFUL）Webサービスを提供します。RDAPを使用すると、サーバーはクライアントのIDに基づいてアクセス制御決定を行うことができます。そのため、HyperText Transfer Protocol（HTTP）[RFC9110]が提供するクライアント識別機能のサポートが含まれます。
RDAP is specified in multiple documents, including "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480], "Security Services for the Registration Data Access Protocol (RDAP)" [RFC7481], "Registration Data Access Protocol (RDAP) Query Format" [RFC9082], and "JSON Responses for the Registration Data Access Protocol (RDAP)" [RFC9083]. [RFC7481] describes client identification and authentication services that can be used with RDAP, but it does not specify how any of these services can (or should) be used with RDAP.
RDAPは、「登録データアクセスプロトコル（RDAP）のHTTP使用法」[RFC7480]、「RFC7480]」など、複数のドキュメントで指定されています。クエリ形式 "[RFC9082]、および「登録データアクセスプロトコル（RDAP）のJSON応答」[RFC9083]。[RFC7481]は、RDAPで使用できるクライアントの識別と認証サービスについて説明しますが、これらのサービスのいずれかをRDAPで使用する（または使用する）方法を指定していません。
The conventional "username and password" authentication method does not scale well in the RDAP ecosystem. Assuming that all domain name and address registries will eventually provide RDAP service, it is impractical and inefficient for users to secure login credentials from the hundreds of different server operators. Authentication methods based on usernames and passwords do not provide information that describes the user in sufficient detail (while protecting the personal privacy of the user) for server operators to make fine-grained access control decisions based on the user's identity. The authentication system used for RDAP needs to address all of these needs.
従来の「ユーザー名とパスワード」認証方法は、RDAPエコシステムではうまく拡張されません。すべてのドメイン名とアドレスレジストリが最終的にRDAPサービスを提供すると仮定すると、ユーザーが何百もの異なるサーバーオペレーターからログイン資格情報を保護することは非現実的で非効率的です。ユーザー名とパスワードに基づく認証方法は、ユーザーのアイデンティティに基づいてきめ細かいアクセス制御決定を行うために、ユーザーを十分に詳細に説明する情報を（ユーザーの個人的なプライバシーを保護しながら）提供しません。RDAPに使用される認証システムは、これらすべてのニーズに対処する必要があります。
A basic level of RDAP service can be provided to users who possess an identifier issued by a recognized provider who can authenticate and validate the user. For example, the identifiers issued by social media services can be used. Users who require higher levels of service (and who are willing to share more information about themselves to gain access to that service) can secure identifiers from specialized providers who are or will be able to provide more detailed information about the user. Server operators can then make access control decisions based on the identification information provided by the user.
RDAPサービスの基本レベルは、ユーザーを認証および検証できる認定プロバイダーによって発行された識別子を所有しているユーザーに提供できます。たとえば、ソーシャルメディアサービスによって発行された識別子を使用できます。より高いレベルのサービスを必要とするユーザー（およびそのサービスにアクセスするために自分自身に関するより多くの情報を共有する意思があるユーザー）は、ユーザーに関するより詳細な情報を提供できる、または提供できる専門的なプロバイダーから識別子を保護できます。サーバーオペレーターは、ユーザーが提供する識別情報に基づいてアクセス制御決定を行うことができます。
A federated authentication system in which an RDAP server outsources identification and authentication services to a trusted identity provider would make it easier to operate and use RDAP by reusing existing identifiers to provide a basic level of access. It can also provide the ability to collect additional user identification information, and that information can be shared with the RDAP server operator with the consent of the user in order to help the server operator make access control decisions. This type of system allows an RDAP server to make access control decisions based on the nature of a query and the identity, authentication, and authorization information that is received from the identity provider. This document describes a federated authentication system for RDAP based on OpenID Connect [OIDC] that meets these needs.
RDAPサーバーが信頼できるIDプロバイダーに識別と認証サービスを外部委託する連邦認証システムは、既存の識別子を再利用して基本レベルのアクセスを提供することにより、RDAPの操作と使用を容易にします。また、追加のユーザー識別情報を収集する機能を提供することができ、その情報は、サーバーオペレーターがアクセス制御の決定を下すのを支援するために、ユーザーの同意を得てRDAPサーバーオペレーターと共有できます。このタイプのシステムにより、RDAPサーバーは、クエリの性質とIDプロバイダーから受け取ったID、認証、および認証情報に基づいてアクセス制御決定を行うことができます。このドキュメントでは、これらのニーズを満たすOpenID Connect [OIDC]に基づいたRDAPのフェデレーション認証システムについて説明します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
All of the HTTP requests described in this document that are sent from an RDAP client to an RDAP server use the HTTP GET method as specified in [RFC9110].
RDAPクライアントからRDAPサーバーに送信されるこのドキュメントで説明されているすべてのHTTP要求は、[RFC9110]で指定されているようにHTTP GETメソッドを使用します。
Long lines in examples are wrapped using "The Single Backslash Strategy" described in [RFC8792].
例の長い行は、[RFC8792]で説明されている「単一のバックスラッシュ戦略」を使用して包まれています。
RDAP itself does not include built-in security services. Instead, RDAP relies on features that are available in other protocol layers to provide needed security services including access control, authentication, authorization, availability, data confidentiality, data integrity, and identification. A description of each of these security services can be found in "Internet Security Glossary, Version 2" [RFC4949]. This document focuses on a federated authentication system for RDAP that provides services for authentication, authorization, and identification, allowing a server operator to make access control decisions. Section 3 of [RFC7481] describes general considerations for RDAP access control, authentication, and authorization.
RDAP自体には、組み込みのセキュリティサービスは含まれていません。代わりに、RDAPは、他のプロトコルレイヤーで利用可能な機能に依存して、アクセス制御、認証、承認、可用性、データの機密性、データの整合性、識別など、必要なセキュリティサービスを提供します。これらの各セキュリティサービスの説明は、「インターネットセキュリティ用語集、バージョン2」[RFC4949]に記載されています。このドキュメントは、認証、承認、識別のためのサービスを提供するRDAP用のフェデレーション認証システムに焦点を当てており、サーバーオペレーターがアクセス制御の決定を行うことができます。[RFC7481]のセクション3では、RDAPアクセス制御、認証、および認可に関する一般的な考慮事項について説明します。
The conventional client-server authentication model requires clients to maintain distinct credentials for every RDAP server. This situation can become unwieldy as the number of RDAP servers increases. Federated authentication mechanisms allow clients to use one credential to access multiple RDAP servers and reduce client credential management complexity.
従来のクライアントサーバー認証モデルでは、クライアントがすべてのRDAPサーバーに対して異なる資格情報を維持する必要があります。この状況は、RDAPサーバーの数が増えるにつれて扱いにくい可能性があります。フェデレーション認証メカニズムにより、クライアントは1つの資格情報を使用して複数のRDAPサーバーにアクセスし、クライアントの資格管理の複雑さを削減できます。
OpenID Connect 1.0 [OIDCC] is a decentralized, Single Sign-On (SSO) federated authentication system that allows users to access multiple web resources with one identifier instead of having to create multiple server-specific identifiers. Users acquire identifiers from OpenID Providers (OPs). Relying Parties (RPs) are applications (such as RDAP) that outsource their user authentication function to an OP. OpenID Connect is built on top of the authorization framework provided by the OAuth 2.0 protocol [RFC6749].
OpenID Connect 1.0 [OIDCC]は、分散型のシングルサインオン（SSO）フェデレート認証システムで、複数のサーバー固有の識別子を作成する代わりに、ユーザーが1つの識別子を使用して複数のWebリソースにアクセスできるようにします。ユーザーは、OpenIDプロバイダー（OPS）から識別子を取得します。依存関係者（RPS）は、ユーザー認証機能をOPに外部委託するアプリケーション（RDAPなど）です。OpenID Connectは、OAUTH 2.0プロトコル[RFC6749]によって提供される承認フレームワークの上に構築されています。
The OAuth authorization framework describes a method for users to access protected web resources without having to hand out their credentials. Instead, clients are issued access tokens by OPs with the permission of the resource owners. Using OpenID Connect and OAuth, multiple RDAP servers can form a federation, and clients can access any server in the federation by providing one credential registered with any OP in that federation. The OAuth authorization framework is designed for use with HTTP and thus can be used with RDAP.
OAuth Authorizationフレームワークは、ユーザーが資格情報を配布せずに保護されたWebリソースにアクセスする方法を説明しています。代わりに、クライアントは、リソース所有者の許可を得て、OPSによってアクセストークンを発行されます。OpenID ConnectとOAuthを使用して、複数のRDAPサーバーがフェデレーションを形成することができ、クライアントはその連邦の任意のOPに登録された1つの資格情報を提供することにより、連邦内の任意のサーバーにアクセスできます。OAuth Authorizationフレームワークは、HTTPで使用するために設計されているため、RDAPで使用できます。
This document uses the following terminology.
このドキュメントでは、次の用語を使用します。
Terms defined by [RFC7480]:
[RFC7480]によって定義された用語：
* client
* クライアント顧客得意弁護依頼人消費者取引先取り引き先来訪者
* server
* サーバサーバー
Terms defined by [RFC6749]:
[RFC6749]によって定義された用語：
* access token
* アクセストークン
* authorization code
* 承認コード
* authorization endpoint
* 承認エンドポイント
* authorization grant
* 承認助成金
* client authentication
* クライアント認証
* client identifier
* クライアント識別子
* protected resource
* 保護されたリソース
* refresh token
* トークンを更新します
* resource owner
* リソース所有者
* resource server
* リソースサーバー
* token endpoint
* トークンエンドポイント
Terms defined by [RFC7519]:
[RFC7519]によって定義された用語：
* claim name
* クレーム名
* claim value
* 請求値
* JSON Web Token (JWT)
* JSON Webトークン（JWT）
Terms defined by [OIDCC]:
[oidcc]によって定義された用語：
* ID Token
* IDトークン
* UserInfo Endpoint
* userinfoエンドポイント
Term defined by [RFC9068]:
[RFC9068]によって定義された用語：
* JWT access token
* JWTアクセストークン
Additional terms from Section 1.2 of the OpenID Connect Core specification are incorporated by reference.
OpenID Connectコア仕様のセクション1.2からの追加項は、参照により組み込まれています。
This document uses the terms "remote" and "default" to describe the relationship between an RDAP server and the OPs that it interacts with. A "remote" OP is one that is identified by the RDAP client by providing either an Issuer Identifier or an end-user identifier in a login request. Whether an Issuer Identifier or end-user identifier can be provided in the login request for the purposes of selecting an OP can be determined by retrieving the RDAP server's OIDC configuration details (see Section 4.1). A "default" OP is one that the RDAP server will use when the RDAP client does not provide an Issuer Identifier or an end-user identifier in the login request.
このドキュメントでは、「リモート」と「デフォルト」という用語を使用して、RDAPサーバーと相互作用するOPSとの関係を記述します。「リモート」OPは、ログイン要求に発行者識別子またはエンドユーザー識別子のいずれかを提供することにより、RDAPクライアントによって識別されるものです。発行者識別子またはエンドユーザー識別子が、OPを選択する目的でログイン要求で提供できるかどうかは、RDAPサーバーのOIDC構成の詳細を取得することで決定できます（セクション4.1を参照）。「デフォルト」OPは、RDAPクライアントがログイン要求に発行者識別子またはエンドユーザー識別子を提供しない場合にRDAPサーバーが使用するものです。
This document uses the term "session" to describe a set of interactions between an RDAP client and an RDAP server during a given period of time. For session-oriented clients (see Section 3.1.2), the RDAP session is a typical HTTP session starting with a farv1_session/login request and ending with either a farv1_session/ logout request (see Section 5 for a description of both path segments) or a timeout. For token-oriented clients (see Sections 3.1.2 and 6), the RDAP session corresponds to the lifespan of an authorization obtained from an OP and the corresponding access token, including any refreshed access tokens.
このドキュメントでは、「セッション」という用語を使用して、特定の期間中にRDAPクライアントとRDAPサーバー間の一連の相互作用を記述します。セッション指向のクライアント（セクション3.1.2を参照）の場合、RDAPセッションは、FARV1_Session/ Loginリクエストから始まり、FARV1_Session/ログアウトリクエスト（両方のパスセグメントの説明についてはセクション5を参照）で終了する典型的なHTTPセッションです。タイムアウト。トークン指向のクライアントの場合（セクション3.1.2および6を参照）、RDAPセッションは、OPから得られた認証の寿命と、更新されたアクセストークンを含む対応するアクセストークンの寿命に対応しています。
Clients that delegate OIDC authentication to an RDAP server as part of session-oriented interactions and can accept and process HTTP cookies [RFC6265] to maintain the session are known as "session-oriented" clients. This type of RDAP client performs the role of a user agent [RFC9110]. An RDAP server performs the role of an OpenID Connect Core Relying Party (RP). A web browser used to send queries directly to an RDAP server is an example of a session-oriented client. Specifications for this type of client can be found in Section 5.
セッション指向のインタラクションの一部としてOIDC認証をRDAPサーバーに委任し、セッションを維持するためにHTTP Cookie [RFC6265]を受け入れて処理するクライアントは、「セッション指向の」クライアントとして知られています。このタイプのRDAPクライアントは、ユーザーエージェント[RFC9110]の役割を実行します。RDAPサーバーは、OpenID Connect Core Core Relying Party（RP）の役割を実行します。RDAPサーバーに直接クエリを送信するために使用されるWebブラウザは、セッション指向のクライアントの例です。このタイプのクライアントの仕様は、セクション5にあります。
Clients that perform OIDC authentication directly, taking the role of an RP in interactions with an OP and sending access tokens [RFC6749] to an RDAP server to authorize RDAP queries, are known as "token-oriented" clients. An RDAP server performs resource server [RFC6749] functions to verify the tokens received from the client and RP functions to retrieve information from the OP as necessary to make access control decisions. A web browser running JavaScript received from a web service that sends queries to an RDAP server directly or through its back-end web service is an example of a token-oriented client. Specifications for this type of client can be found in Section 6.
OIDC認証を直接実行するクライアントは、OPとの相互作用におけるRPの役割を引き受け、RDAPクエリを承認するためにRDAPサーバーにアクセストークン[RFC6749]を送信することは、「トークン指向」クライアントとして知られています。RDAPサーバーは、リソースサーバー[RFC6749]機能を実行してクライアントから受信したトークンを検証し、RP関数を検証して、アクセス制御の決定を行うために必要に応じてOPから情報を取得します。javaScriptを実行しているWebブラウザは、RDAPサーバーに直接またはバックエンドWebサービスを介してクエリを送信するWebサービスから受信したものです。これは、トークン指向のクライアントの例です。このタイプのクライアントの仕様は、セクション6にあります。
Clients MAY operate as either session-oriented or token-oriented clients, but they MUST do so consistently by not mixing token-oriented and session-oriented requests while interacting with an OP. Servers SHOULD support both types of client to maximize interoperability but MAY choose to support only one type of client as required by local policy or operating conditions. A server that does not support a particular client type will not support the protocol features (the data structures, path segments, parameters, and interactions) specified for that client type. Server signaling of supported client types is described in Section 4.1.
クライアントは、セッション指向またはトークン指向のクライアントとして動作する場合がありますが、OPとの対話中にトークン指向とセッション指向のリクエストを混合しないことにより、一貫してそうする必要があります。サーバーは、相互運用性を最大化するために両方のタイプのクライアントをサポートする必要がありますが、ローカルポリシーまたは操作条件で必要な1つのタイプのクライアントのみをサポートすることを選択できます。特定のクライアントタイプをサポートしていないサーバーは、そのクライアントタイプに指定されたプロトコル機能（データ構造、パスセグメント、パラメーター、およびインタラクション）をサポートしません。サポートされているクライアントタイプのサーバーシグナルは、セクション4.1で説明されています。
At a high level, RDAP authentication of a session-oriented client using OpenID Connect requires completion of the following steps:
高レベルでは、OpenID Connectを使用してセッション指向のクライアントのRDAP認証には、次の手順を完了する必要があります。
1. An RDAP client sends an RDAP "help" query to an RDAP server to determine the types and capabilities of the OPs that are used by the RDAP server. This information is returned in the "rdapConformance" section of the response. A value of "farv1" indicates support for the extension described in this specification. If one or more remote OPs are supported, the RDAP client SHOULD evaluate the additional information described in Section 4.1 in order to discover the capabilities of the RDAP server and optionally obtain the set of supported OPs unless that information is available from a trusted out-of-band source and has already been processed.
1. RDAPクライアントはRDAP「ヘルプ」クエリをRDAPサーバーに送信して、RDAPサーバーが使用するOPSのタイプと機能を決定します。この情報は、応答の「rdapconformance」セクションに返されます。「FARV1」の値は、この仕様で説明されている拡張機能のサポートを示します。1つ以上のリモートOPSがサポートされている場合、RDAPクライアントは、RDAPサーバーの機能を発見するために、セクション4.1で説明されている追加情報を評価し、その情報が信頼できる範囲から利用可能でない限り、サポートされているOPSのセットを取得する必要があります。 - バンドソースとすでに処理されています。
2. An RDAP client sends an RDAP "login" request to an RDAP server as described in Section 5.2.
2. RDAPクライアントは、セクション5.2で説明されているRDAP「ログイン」要求をRDAPサーバーに送信します。
3. The RDAP server prepares an Authentication Request containing the desired request parameters.
3. RDAPサーバーは、目的の要求パラメーターを含む認証要求を準備します。
4. The RDAP server sends an Authentication Request to an OP authorization endpoint and redirects the RDAP client to the OP using an HTTP redirect.
4. RDAPサーバーは、OP Authorization EndPointに認証要求を送信し、HTTPリダイレクトを使用してRDAPクライアントをOPにリダイレクトします。
5. The OP authenticates the end user.
5. OPはエンドユーザーを認証します。
6. The OP obtains end-user consent and authorization.
6. OPは、エンドユーザーの同意と承認を取得します。
7. The OP sends the RDAP client back to the RDAP server with an authorization code using an HTTP redirect.
7. OPは、HTTP Redirectを使用して認証コードを使用してRDAPクライアントをRDAPサーバーに送り返します。
8. The RDAP server requests tokens using the authorization code at the OP's token endpoint.
8. RDAPサーバーは、OPのトークンエンドポイントで承認コードを使用してトークンを要求します。
9. The RDAP server receives a response that contains an ID Token and access token in the response body.
9. RDAPサーバーは、IDトークンを含む応答を受信し、応答本体にトークンにアクセスします。
10. The RDAP server validates the tokens as described in [OIDCC] and retrieves the claims associated with the end user's identity from the OP's UserInfo Endpoint.
10. RDAPサーバーは、[OIDCC]で説明されているトークンを検証し、OPのuserInfoエンドポイントからエンドユーザーのIDに関連するクレームを取得します。
The steps above can be described in a sequence diagram:
上記の手順は、シーケンス図で説明できます。
End OpenID RDAP RDAP
User Provider Client Server
| | | |
| | |-----Help Query---->|
| | | |
| | |<---Help Response---|
| | | |
|-------Login Request------>| |
| | | |
| | |---Login Request--->|
| | | |
| |<-----Authentication Request------|
| | | |
| Credential--| | |
|<--Request | | |
| | | |
|--Credential | | |
| Response->| | |
| | | |
| |-----Authentication Response----->|
| | | |
| |<----------Token Request----------|
| | | |
| |-----------Token Response-------->|
| | | |
| |<----------Claim Request----------|
| | | |
| |-----------Claim Response-------->|
| | | |
| | |<--Login Response---|
| | | |
|<------Login Response------| |
| | | |
|----------RDAP Query------>| |
| | | |
| | |-----RDAP Query---->|
| | | |
| | |<---RDAP Response---|
| | | |
|<------RDAP Response-------| |
Figure 1
The RDAP server can then make identification, authorization, and access control decisions based on end-user identity information and local policies. Note that OpenID Connect describes different process flows for other types of clients, such as script-based or command-line clients.
RDAPサーバーは、エンドユーザーのID情報とローカルポリシーに基づいて、識別、承認、およびアクセス制御の決定を行うことができます。OpenID Connectは、スクリプトベースやコマンドラインクライアントなど、他のタイプのクライアントのさまざまなプロセスフローを記述していることに注意してください。
RDAP authentication of a token-oriented client using OpenID Connect requires completion of the following steps:
OpenID Connectを使用したトークン指向クライアントのRDAP認証には、次の手順が完了する必要があります。
1. An RDAP client sends an RDAP "help" query to an RDAP server to determine the type and capabilities of the OPs that are used by the RDAP server. This information is returned in the "rdapConformance" section of the response. A value of "farv1" indicates support for the extension described in this specification. If one or more remote OPs are supported, the RDAP client SHOULD evaluate the additional information described in Section 4.1 in order to discover the capabilities of the RDAP server and optionally obtain the set of supported OPs. Support for token-oriented clients requires a default OP.
1. RDAPクライアントはRDAP「ヘルプ」クエリをRDAPサーバーに送信して、RDAPサーバーが使用するOPSのタイプと機能を決定します。この情報は、応答の「rdapconformance」セクションに返されます。「FARV1」の値は、この仕様で説明されている拡張機能のサポートを示します。1つ以上のリモートOPSがサポートされている場合、RDAPクライアントは、RDAPサーバーの機能を発見し、オプションでサポートされているOPSのセットを取得するために、セクション4.1で説明されている追加情報を評価する必要があります。トークン指向のクライアントのサポートには、デフォルトのOPが必要です。
2. The RDAP client determines the end user's OP and confirms that it's supported by the RDAP server.
2. RDAPクライアントは、エンドユーザーのOPを決定し、RDAPサーバーによってサポートされていることを確認します。
3. The RDAP client sends an Authentication Request to the OP's authorization endpoint.
3. RDAPクライアントは、OPの承認エンドポイントに認証要求を送信します。
4. The OP authenticates the end user.
4. OPはエンドユーザーを認証します。
5. The OP obtains end-user consent or authorization.
5. OPは、エンドユーザーの同意または承認を取得します。
6. The OP returns an authorization code to the RDAP client.
6. OPは、RDAPクライアントに承認コードを返します。
7. The RDAP client requests tokens using the authorization code at the OP's token endpoint.
7. RDAPクライアントは、OPのトークンエンドポイントで承認コードを使用してトークンを要求します。
8. The RDAP client receives a response that contains an ID Token and an access token in the response body.
8. RDAPクライアントは、IDトークンと応答本体にアクセストークンを含む応答を受け取ります。
9. The RDAP client monitors the token validity period and either refreshes the token or requests new tokens as necessary.
9. RDAPクライアントは、トークンの有効期間を監視し、トークンを更新するか、必要に応じて新しいトークンを要求します。
10. The RDAP client sends queries that require user identification, authentication, and authorization to an RDAP server that include an access token in an HTTP "authorization" header using the "bearer" authentication scheme described in [RFC6750].
10. RDAPクライアントは、[RFC6750]で説明されている「Bearer」認証スキームを使用して、HTTP「認証」ヘッダーにアクセストークンを含むRDAPサーバーにユーザー識別、認証、および認証を必要とするクエリを送信します。
11. The RDAP server validates the access token and retrieves the claims associated with the end user's identity from the OP's UserInfo Endpoint.
11. RDAPサーバーは、アクセストークンを検証し、OPのuserInfoエンドポイントからエンドユーザーのIDに関連付けられたクレームを取得します。
12. The RDAP server determines the end user's authorization level and processes the query in accordance with server policies.
12. RDAPサーバーは、エンドユーザーの承認レベルを決定し、サーバーポリシーに従ってクエリを処理します。
The steps above can be described in a sequence diagram:
上記の手順は、シーケンス図で説明できます。
End OpenID RDAP RDAP
User Provider Client Server
| | | |
| | |-----Help Query---->|
| | | |
| | |<----Help Response--|
| | | |
|-------Login Request------>| |
| | | |
| |<-Authentication |
| | Request---| |
| | | |
|<-Credential | | |
| Request---| | |
| | | |
|--Credential | | |
| Response->| | |
| | | |
| |--Authentication |
| | Response--->| |
| | | |
| |<-Token | |
| | Request----| |
| | | |
| |--Token | |
| | Response-->| |
| | | |
|<------Login Response------| |
| | | |
|-----RDAP Query----------->| |
| | | |
| | |----RDAP Query----->|
| | | |
| |<------------Claim |
| | Request---------------|
| | | |
| |-------------Claim |
| | Response------------->|
| | | |
| | |<---RDAP Response---|
| | | |
|<----RDAP Response---------| |
Figure 2
End users MAY present an identifier (an OpenID) issued by an OP to use OpenID Connect with RDAP. If the RDAP server supports a default OP or if provider discovery is not supported, the end-user identifier MAY be omitted. An OP SHOULD include support for the claims described in Section 3.1.5 to provide additional information needed for RDAP end-user authorization; in the absence of these claims, clients and servers MAY make authorization and access control decisions as appropriate given any other information returned from the OP. OpenID Connect requires RPs to register with OPs to use OpenID Connect services for an end user. The registration process is often completed using out-of-band methods, but it is also possible to use the automated method described by the OpenID Connect Dynamic Client Registration protocol [OIDCR]. The parties involved can use any method that is mutually acceptable.
エンドユーザーは、OPによって発行された識別子（OpenID）を提示することができます。RDAPサーバーがデフォルトのOPをサポートする場合、またはプロバイダーの発見がサポートされていない場合、エンドユーザー識別子は省略できます。OPには、RDAPエンドユーザー承認に必要な追加情報を提供するために、セクション3.1.5に記載されているクレームのサポートを含める必要があります。これらのクレームがない場合、クライアントとサーバーは、OPから返された他の情報を考慮して、必要に応じて許可およびアクセス制御の決定を行う場合があります。OpenID Connectでは、RPSがOPSに登録して、エンドユーザーにOpenID Connectサービスを使用する必要があります。登録プロセスは、帯域外の方法を使用して完了することがよくありますが、OpenID Connect Dynamic Client登録プロトコル[OIDCR]で記述された自動化された方法を使用することもできます。関係者は、相互に受け入れられる方法を使用できます。
An RDAP server acting as an RP needs to be able to map an end user's identifier to an OP. This can be accomplished using the OPTIONAL OpenID Connect Discovery protocol [OIDCD], but that protocol is not widely implemented. Out-of-band methods are also possible and can be more dependable. For example, an RP can support a limited number of OPs and maintain internal associations of those identifiers with the OPs that issued them.
RPとして機能するRDAPサーバーは、エンドユーザーの識別子をOPにマッピングできる必要があります。これは、オプションのOpenID Connect Discovery Protocol [OIDCD]を使用して実現できますが、そのプロトコルは広く実装されていません。バンド外の方法も可能であり、より信頼できる可能性があります。たとえば、RPは限られた数のOPSをサポートし、それらを発行したOPSとの識別子の内部関連を維持できます。
Alternatively, if mapping an end user's identifier is not possible, or not supported by the RDAP server, the RDAP server SHOULD support explicit specification of a remote OP by the RDAP client in the form of a query parameter as described in Section 5.2.2 unless the remote OP has been identified using an out-of-band mechanism. An RDAP server MUST provide information about its capabilities and supported OPs in the "help" query response in the "farv1_openidcConfiguration" data structure described in Section 4.1. An RDAP server acting as an RP MUST support at least one of these methods of OP discovery.
または、エンドユーザーの識別子をマッピングすることが不可能であるか、RDAPサーバーによってサポートされていない場合、RDAPサーバーは、セクション5.2.2で説明されているように、RDAPクライアントによるリモートOPの明示的な指定をサポートする必要があります。リモートOPは、バンド外のメカニズムを使用して特定されています。RDAPサーバーは、セクション4.1で説明されている「FARV1_OPENIDCCONFIGURATION」データ構造の「ヘルプ」クエリ応答でその機能とサポートされたOPSに関する情報を提供する必要があります。RPとして機能するRDAPサーバーは、これらのOP発見方法の少なくとも1つをサポートする必要があります。
Once the OP is known, an RP MUST form an Authentication Request and send it to the OP as described in Section 3 of [OIDCC]. The authentication path followed (authorization, implicit, or hybrid) will depend on the Authentication Request response_type set by the RP. The remainder of the processing steps described here assume that the authorization code flow is being used by setting "response_type=code" in the Authentication Request.
OPがわかったら、RPは認証要求を形成し、[OIDCC]のセクション3で説明したようにOPに送信する必要があります。続く認証パス（認証、暗黙、またはハイブリッド）は、RPによって設定された認証要求Response_Typeに依存します。ここで説明する処理手順の残りは、認証要求に「Response_Type = code」を設定することにより、認証コードフローが使用されていると仮定します。
The benefits of using the authorization code flow for authenticating a human user are described in Section 3.1 of [OIDCC]. The Implicit Flow is more commonly used by clients implemented in a web browser using a scripting language; it is described in Section 3.2 of [OIDCC]. At the time of this writing, the Implicit Flow is considered insecure and efforts are being made to deprecate the flow. The Hybrid Flow (described in Section 3.3 of [OIDCC]) combines elements of the authorization code and Implicit Flows by returning some tokens from the authorization endpoint and others from the token endpoint.
Humanユーザーを認証するために認証コードフローを使用する利点は、[OIDCC]のセクション3.1で説明されています。暗黙的なフローは、スクリプト言語を使用してWebブラウザーに実装されたクライアントによってより一般的に使用されます。[OIDCC]のセクション3.2で説明しています。この執筆時点では、暗黙の流れは安全ではないと見なされ、流れを非難する努力がなされています。ハイブリッドフロー（[OIDCC]のセクション3.3で説明）は、承認コードの要素と、認証エンドポイントからいくつかのトークンを返すことにより、トークンエンドポイントから他のトークンを返すことにより、暗黙的なフローを組み合わせています。
An Authentication Request can contain several parameters. REQUIRED parameters are specified in Section 3.1.2.1 of [OIDCC]. Apart from these parameters, it is RECOMMENDED that the RP include the optional "login_hint" parameter in the request, with the value being that of the "farv1_id" query parameter of the end user's RDAP "login" request, if provided. Passing the "login_hint" parameter allows a client to pre-fill login form information, so logging in can be more convenient for users. Other parameters MAY be included.
認証要求には、いくつかのパラメーターを含めることができます。必要なパラメーターは、[OIDCC]のセクション3.1.2.1で指定されています。これらのパラメーターとは別に、RPにリクエストにオプションの「login_hint」パラメーターを含めることをお勧めします。値は、提供されている場合は、エンドユーザーのRDAP「ログイン」要求の「FARV1_ID」クエリパラメーターの値です。「login_hint」パラメーターを渡すと、クライアントがログインフォーム情報を事前に充填できるようになるため、ログインすることはユーザーにとってより便利です。他のパラメーターが含まれる場合があります。
The OP receives the Authentication Request and attempts to validate it as described in Section 3.1.2.2 of [OIDCC]. If the request is valid, the OP attempts to authenticate the end user as described in Section 3.1.2.3 of [OIDCC]. The OP returns an error response if the request is not valid or if any error is encountered.
OPは認証要求を受信し、[OIDCC]のセクション3.1.2.2で説明されているように検証しようとします。リクエストが有効な場合、OPは[OIDCC]のセクション3.1.2.3で説明されているように、エンドユーザーを認証しようとします。OPは、リクエストが有効でない場合、またはエラーが発生した場合にエラー応答を返します。
After the end user is authenticated, the OP MUST obtain consent from the end user to release authorization information to the RDAP server acting as an RP. This process is described in Section 3.1.2.4 of [OIDCC].
エンドユーザーが認証された後、OPはエンドユーザーから同意を取得して、RPとして機能するRDAPサーバーに承認情報をリリースする必要があります。このプロセスは、[OIDCC]のセクション3.1.2.4で説明されています。
After obtaining an authorization result, the OP will send a response to the RP that provides the result of the authorization process using an authorization code. The RP MUST validate the response. This process is described in Sections 3.1.2.5 - 3.1.2.7 of [OIDCC].
承認結果を取得した後、OPは承認コードを使用して承認プロセスの結果を提供するRPへの回答を送信します。RPは応答を検証する必要があります。このプロセスは、[OIDCC]のセクション3.1.2.5-3.1.2.7で説明されています。
The RP sends a token request using the authorization grant to a token endpoint to obtain a token response containing an access token, ID Token, and an OPTIONAL refresh token. The RP MUST validate the token response. This process is described in Section 3.1.3.5 [OIDCC].
RPは、承認助成金を使用してトークンエンドポイントにトークンリクエストを送信し、アクセストークン、IDトークン、およびオプションの更新トークンを含むトークン応答を取得します。RPはトークン応答を検証する必要があります。このプロセスは、セクション3.1.3.5 [OIDCC]で説明されています。
The set of claims can be retrieved by sending a request to a UserInfo Endpoint using the access token. The claims are returned in the ID Token. The process of retrieving claims from a UserInfo Endpoint is described in Section 5.3 of [OIDCC].
クレームのセットは、アクセストークンを使用してuserInfoエンドポイントにリクエストを送信することで取得できます。クレームはIDトークンで返されます。userInfoエンドポイントからクレームを取得するプロセスは、[oidcc]のセクション5.3で説明されています。
OpenID Connect specifies a set of standard claims in Section 5.1 of [OIDCC]. Additional claims for RDAP are described in Section 3.1.5.
OpenID Connectは、[OIDCC]のセクション5.1で一連の標準クレームを指定します。RDAPの追加の請求は、セクション3.1.5で説明されています。
OpenID Connect claims are pieces of information used to make assertions about an entity. Section 5 of [OIDCC] describes a set of standard claims. Section 5.1.2 of [OIDCC] notes that additional claims MAY be used, and it describes a method to create them. The set of claims that are specific to RDAP are associated with an OAuth scope request parameter value (see Section 3.3 of [RFC6749]) of "rdap".
OpenID Connectクレームは、エンティティに関する主張をするために使用される情報の一部です。[OIDCC]のセクション5では、一連の標準クレームについて説明します。[OIDCC]のセクション5.1.2は、追加のクレームが使用される可能性があることを指摘し、それらを作成する方法を説明しています。RDAPに固有の一連のクレームは、「RDAP」のOAUTHスコープ要求パラメーター値（[RFC6749]のセクション3.3を参照）に関連付けられています。
Communities of RDAP users and operators may wish to make and validate claims about a user's "need to know" when it comes to requesting access to a protected resource. For example, a law enforcement agent or a trademark attorney may wish to be able to assert that they have a legal right to access a protected resource, and a server operator may need to be able to receive and validate that claim. These needs can be met by defining and using an additional "rdap_allowed_purposes" claim.
RDAPユーザーとオペレーターのコミュニティは、保護されたリソースへのアクセスを要求する際に、ユーザーの「知る必要がある」という主張を作成し、検証したい場合があります。たとえば、法執行機関または商標弁護士は、保護されたリソースにアクセスする法的権利があることを主張したい場合があり、サーバーオペレーターはその請求を受け取り、検証できる必要がある場合があります。これらのニーズは、追加の「RDAP_ALLOWED_PURPOSES」クレームを定義および使用することで満たすことができます。
The "rdap_allowed_purposes" claim identifies the purposes for which access to a protected resource can be requested by an end user. Use of the "rdap_allowed_purposes" claim is OPTIONAL; processing of this claim is subject to server acceptance of the purposes, the trust level assigned to this claim by the server, and successful authentication of the end user. Unrecognized purpose values MUST be ignored, and the associated query MUST be processed as if the unrecognized purpose value was not present at all. See Section 9.3 for a description of the IANA considerations associated with this claim.
「RDAP_ALLOWED_PURPOSES」クレームは、エンドユーザーが保護されたリソースへのアクセスを要求できる目的を特定します。「rdap_allowed_purposes」クレームの使用はオプションです。このクレームの処理は、サーバーの目的、サーバーによるこの請求に割り当てられた信頼レベル、およびエンドユーザーの認証の成功の対象となります。認識されていない目的値は無視する必要があり、関連するクエリは、認識されていない目的値がまったく存在しないかのように処理する必要があります。この主張に関連するIANAの考慮事項の説明については、セクション9.3を参照してください。
The "rdap_allowed_purposes" claim is represented as an array of case-sensitive StringOrURI values as specified in Section 2 of [RFC7519]. An example:
[RDAP_ALLOWED_PURPOSES]クレームは、[RFC7519]のセクション2で指定されているように、ケースに敏感なstringoruri値の配列として表されます。例：
"rdap_allowed_purposes": ["domainNameControl","dnsTransparency"]
「rdap_allowed_purposes "：[" domainnamecontrol "、" dnstransparency "]]
Purpose values are assigned to an end user's credential by an identity provider. Identity providers MUST ensure that appropriate purpose values are only assigned to end user identities that are authorized to use them.
目的値は、IDプロバイダーによってエンドユーザーの資格情報に割り当てられます。IDプロバイダーは、適切な目的値が、それらを使用することが許可されているエンドユーザーIDにのみ割り当てられることを確認する必要があります。
Communities of RDAP users and operators may wish to make and validate claims about a user's wish to not have their queries logged, tracked, or recorded. For example, a law enforcement agent may wish to assert that their queries are part of a criminal investigation and should not be tracked due to a risk of query exposure compromising the investigation, and a server operator may need to be able to receive and validate that claim. These needs can be met by defining and using an additional "do not track" claim.
RDAPユーザーとオペレーターのコミュニティは、クエリを記録、追跡、または記録しないというユーザーの希望に関する主張を作成し、検証したい場合があります。たとえば、法執行エージェントは、質問が侵害されるクエリ露出のリスクがあるため、質問を追跡すべきではないことを断言することを望む場合があり、サーバーオペレーターは、そのことを受け取り、検証できる必要がある場合があります。請求。これらのニーズは、追加の「追跡しない」クレームを定義および使用することで満たすことができます。
The "do not track" ("rdap_dnt_allowed") claim can be used to identify an end user that is authorized to perform queries without the end user's association with those queries being logged, tracked, or recorded by the server. Client use of the "rdap_dnt_allowed" claim is OPTIONAL. Server operators MUST NOT log, track, or record any association of the query and the end user's identity if the end user is successfully identified and authorized, if the "rdap_dnt_allowed" claim is present, if the value of the claim is "true", and if accepting the claim complies with local regulations regarding logging and tracking.
「Do Not Track」（「RDAP_DNT_ALLOWED」）クレームを使用して、サーバーがログ、追跡、または記録されるクエリとエンドユーザーの関連付けなしにクエリを実行することが許可されているエンドユーザーを識別できます。「RDAP_DNT_ALLOWED」クレームのクライアントの使用はオプションです。サーバーオペレーターは、エンドユーザーが正常に識別および承認されている場合、「rdap_dnt_allowed」クレームが存在する場合、クレームの値が「真」である場合、クエリとエンドユーザーのアイデンティティの関連付けをログ、追跡、または記録してはなりません。また、クレームを受け入れる場合、ロギングと追跡に関する現地の規制に準拠しています。
The "rdap_dnt_allowed" value is represented as a JSON boolean literal. An example:
「RDAP_DNT_ALLOWED」値は、JSONブールのリテラルとして表されます。例：
rdap_dnt_allowed: true
rdap_dnt_allowed：true
No special query tracking processing is required if this claim is not present or if the value of the claim is "false". Use of this claim MUST be limited to end users who are granted "do not track" privileges in accordance with service policies and regulations. Specification of these policies and regulations is beyond the scope of this document.
このクレームが存在しない場合、またはクレームの価値が「虚偽」である場合、特別なクエリ追跡処理は必要ありません。この請求の使用は、サービスポリシーと規制に従って「追跡しない」特権を認められたエンドユーザーに限定されなければなりません。これらのポリシーと規制の仕様は、このドキュメントの範囲を超えています。
As described in Section 3.1.4.1, an RDAP server MUST provide information about its capabilities and supported OPs in a "help" query response. This specification describes a new "farv1_openidcConfiguration" data structure that describes the OpenID Connect configuration and related extension features supported by the RDAP server. This data structure is returned to all client types.
セクション3.1.4.1で説明されているように、RDAPサーバーは、「ヘルプ」クエリ応答でその機能とサポートされたOPSに関する情報を提供する必要があります。この仕様は、RDAPサーバーでサポートされているOpenID接続構成と関連する拡張機能を記述する新しい「FARV1_OPENIDCCONFIGURATION」データ構造について説明します。このデータ構造は、すべてのクライアントタイプに返されます。
The "farv1_openidcConfiguration" data structure is an object with the following members:
「farv1_openidcconfiguration」データ構造は、次のメンバーを持つオブジェクトです。
"sessionClientSupported":
「SessionClientsupported」：
(REQUIRED) a boolean value that describes RDAP server support for session-oriented clients (see Section 3.1.2).
（必須）セッション指向のクライアントのRDAPサーバーサポートを記述するブール値（セクション3.1.2を参照）。
"tokenClientSupported":
「tokenclientsupported」：
(REQUIRED) a boolean value that describes RDAP server support for token-oriented clients (see Section 3.1.2).
（必須）トークン指向のクライアントのRDAPサーバーサポートを記述するブール値（セクション3.1.2を参照）。
"dntSupported":
「dntsupported」：
(REQUIRED) a boolean value that describes RDAP server support for the "farv1_dnt" query parameter (see Section 4.2.2).
（必須）「FARV1_DNT」クエリパラメーターのRDAPサーバーサポートを記述するブール値（セクション4.2.2を参照）。
"providerDiscoverySupported":
「ProviderDiscoverySupported」：
(OPTIONAL) a boolean value that describes RDAP server support for discovery of providers of end-user identifiers. The default value is "true".
（オプション）エンドユーザー識別子のプロバイダーの発見のためのRDAPサーバーサポートを説明するブール値。デフォルト値は「true」です。
"issuerIdentifierSupported":
「発行条件がサポートされている」：
(OPTIONAL) a boolean value that describes RDAP server support for explicit client specification of an Issuer Identifier. The default value is "true".
（オプション）発行者識別子の明示的なクライアント仕様のRDAPサーバーサポートを記述するブール値。デフォルト値は「true」です。
"implicitTokenRefreshSupported":
「InflicittokenRefreshSupported」：
(OPTIONAL) a boolean value that describes RDAP server support for implicit token refresh. The default value is "false".
（オプション）暗黙のトークンリフレッシュのRDAPサーバーサポートを記述するブール値。デフォルト値は「false」です。
"openidcProviders":
「OpenIDCProviders」：
(OPTIONAL) a list of objects with the following members that describes the set of OPs that are supported by the RDAP server. This data is RECOMMENDED if the value of issuerIdentifierSupported is "true":
（オプション）RDAPサーバーによってサポートされているOPSのセットを記述する次のメンバーを持つオブジェクトのリスト。このデータは、発行条件がサポートされていることの値が「真」である場合に推奨されます。
"iss":
「ISS」：
(REQUIRED) a URI value that represents the Issuer Identifier of the OP as per the OpenID Connect Core specification [OIDCC].
（必須）OpenID Connectコア仕様[OIDCC]に従って、OPの発行者識別子を表すURI値。
"name":
"名前"：
(REQUIRED) a string value representing the human-friendly name of the OP.
（必須）OPの人間に優しい名前を表す文字列値。
"default":
"デフォルト"：
(OPTIONAL) a boolean value that describes RDAP server support for an OPTIONAL default OP that will be used when a client omits the "farv1_id" and "farv1_iss" query parameters from a "farv1_session/login" request. Only one member of this set can be identified as the default OP by setting a value of "true". The default value is "false".
（オプション）クライアントが「FARV1_SESS/LOGIN/LOGIN」リクエストから「FARV1_ID」および「FARV1_ISS」クエリパラメーターを省略したときに使用されるオプションのデフォルトOPのRDAPサーバーサポートを説明するブール値。「true」の値を設定することにより、このセットの1つのメンバーのみをデフォルトOPとして識別できます。デフォルト値は「false」です。
"additionalAuthorizationQueryParams":
「追加の承認queryparams」：
(OPTIONAL) an object where each member represents an OAuth authorization request parameter name-value pair supported by the OP. The name represents an OAuth query parameter, and the value is the query parameter value. A token-oriented RDAP client SHOULD add these query parameters and their corresponding values to the Authentication Request URL when requesting authorization by a specified OP through a proxy OP.
（オプション）各メンバーがOAUTH Authorizationリクエストパラメーター名valueペアをOPでサポートするオブジェクト。名前はOAuthクエリパラメーターを表し、値はクエリパラメーター値です。トークン指向のRDAPクライアントは、プロキシOPを介して指定されたOPによる承認を要求する際に、これらのクエリパラメーターと対応する値を認証要求URLに追加する必要があります。
An RDAP server MUST set either the "sessionClientSupported" or the "tokenClientSupported" value to "true". Both values MAY be set to "true" if an RDAP server supports both types of clients.
RDAPサーバーは、「sessionclientsupported」または「tokenclientsupted」値を「true」に設定する必要があります。RDAPサーバーが両方のタイプのクライアントをサポートする場合、両方の値を「真」に設定できます。
The "providerDiscoverySupported" value has a direct impact on the use of the "farv1_id" query parameter described in Sections 3.1.4.2 and 5.2.1. The value of "providerDiscoverySupported" MUST be "true" for an RDAP server to properly accept and process "farv1_id" query parameters. Similarly, the "issuerIdentifierSupported" value has a direct impact on the use of the "farv1_iss" query parameter described in Section 5.2.2. The value of "issuerIdentifierSupported" MUST be "true" for an RDAP server to properly accept and process "farv1_iss" query parameters.
「ProviderDiscoverySupted」値は、セクション3.1.4.2および5.2.1で説明されている「FARV1_ID」クエリパラメーターの使用に直接影響を与えます。RDAPサーバーが「FARV1_ID」クエリパラメーターを適切に受け入れて処理するには、「ProviderDiscoverySported」の値は「真」でなければなりません。同様に、「発行能力がサポートされている」値は、セクション5.2.2で説明されている「FARV1_ISS」クエリパラメーターの使用に直接影響を与えます。RDAPサーバーが「FARV1_ISS」クエリパラメーターを適切に受け入れて処理するには、「発行条件の支持」の値は「真」でなければなりません。
An example of a "farv1_openidcConfiguration" data structure:
「farv1_openidcconfiguration」データ構造の例：
"farv1_openidcConfiguration": {
"sessionClientSupported": true,
"tokenClientSupported": true,
"dntSupported": false,
"providerDiscoverySupported": true,
"issuerIdentifierSupported": true,
"openidcProviders":
[
{
"iss": "https://idp.example.com",
"name": "Example IDP"
},
{
"iss": "https://accounts.example.net",
"name": "Login with EXAMPLE",
"additionalAuthorizationQueryParams": {
"kc_idp_hint": "examplePublicIDP"
}
},
{
"iss": "https://auth.nic.example/auth/realms/rdap",
"name": "Default OP for the Example RDAP server",
"default": true
}
]
}
Figure 3
This specification describes two OPTIONAL query parameters for use with RDAP queries that request access to information associated with protected resources:
この仕様では、保護されたリソースに関連付けられた情報へのアクセスを要求するRDAPクエリで使用する2つのオプションのクエリパラメーターについて説明します。
"farv1_qp":
「FARV1_QP」：
A query parameter to identify the purpose of the query.
クエリの目的を識別するクエリパラメーター。
"farv1_dnt":
「FARV1_DNT」：
A query parameter to request that the server not log or otherwise record information about the identity associated with a query.
クエリパラメーターは、サーバーがクエリに関連付けられているIDに関する情報を記録するか、その他の方法で記録することを要求します。
One or both parameters MAY be added to an RDAP request URI using the syntax described in Section "application/x-www-form-urlencoded" of [HTMLURL].
[htmlurl]のセクション「アプリケーション/x-www-form-urlencoded」で説明されている構文を使用して、RDAP要求URIに片方または両方または両方を追加できます。
This query is represented as a "key=value" pair using a key value of "farv1_qp" and a value component that contains a single query purpose string from the set of allowed purposes associated with the end user's identity (see Section 3.1.5.1). If present, the server SHOULD compare the value of the parameter to the "rdap_allowed_purposes" claim values associated with the end user's identity and ensure that the requested purpose is present in the set of allowed purposes. The RDAP server MAY choose to ignore both the requested purpose and the "rdap_allowed_purposes" claim values if they are inconsistent with local server policy. The server MUST return an HTTP 403 (Forbidden) response if the requested purpose is not an allowed purpose. If the "farv1_qp" parameter is not present, the server MUST process the query and make an access control decision based on any other information known to the server about the end user and the information they are requesting. For example, a server MAY treat the request as one performed by an unidentified or unauthenticated user and return either an error or an appropriate subset of the available data. An example domain query using the "farv1_qp" query parameter:
このクエリは、「FARV1_QP」のキー値と、エンドユーザーのIDに関連付けられた許可された目的のセットからの単一のクエリ目的文字列を含む値コンポーネントを使用した「key = value」ペアとして表されます（セクション3.1.5.1を参照）。存在する場合、サーバーはパラメーターの値を「rdap_allowed_purposes」と比較して、エンドユーザーのIDに関連付けられた請求値を比較し、要求された目的が許可された目的のセットに存在することを確認する必要があります。RDAPサーバーは、要求された目的と「RDAP_ALLOWED_PURPOSES」の両方の請求値の両方を無視することを選択できます。要求された目的が許可された目的ではない場合、サーバーはHTTP 403（禁止）応答を返す必要があります。「FARV1_QP」パラメーターが存在しない場合、サーバーはクエリを処理し、エンドユーザーと要求している情報についてサーバーに既知の他の情報に基づいてアクセス制御決定を下す必要があります。たとえば、サーバーは、未確認または認証されていないユーザーによって実行されたものとしてリクエストを扱い、利用可能なデータのエラーまたは適切なサブセットを返すことができます。「FARV1_QP」クエリパラメーターを使用したドメインクエリの例：
https://example.com/rdap/domain/example.com?farv1_qp=legalActions
Figure 4
This query is represented as a "key=value" pair using a key value of "farv1_dnt" and a value component that contains a single boolean value. A value of "true" indicates that the end user is requesting that their query is not tracked or logged in accordance with server policy. A value of "false" indicates that the end user is accepting that their query can be tracked or logged in accordance with server policy. The server MUST return an HTTP 403 (Forbidden) response if the server is unable to perform the action requested by this query parameter. An example domain query using the "farv1_dnt" query parameter:
このクエリは、「FARV1_DNT」のキー値と単一のブール値を含む値コンポーネントを使用した「key = value」ペアとして表されます。「true」の値は、エンドユーザーがサーバーポリシーに従ってクエリが追跡またはログインされていないことを要求していることを示しています。「false」の値は、エンドユーザーがサーバーポリシーに従って追跡またはログに記録できることをエンドユーザーが受け入れていることを示しています。サーバーがこのクエリパラメーターによって要求されたアクションを実行できない場合、サーバーはHTTP 403（禁止）応答を返す必要があります。「FARV1_DNT」クエリパラメーターを使用したドメインクエリの例：
https://example.com/rdap/domain/example.com?farv1_dnt=true
Figure 5
Unrecognized query parameters MUST be ignored. An RDAP server that processes an authenticated query MUST determine if the end-user identification information is associated with an OP that is recognized and supported by the server. RDAP servers MUST reject queries that include identification information that is not associated with a supported OP by returning an HTTP 400 (Bad Request) response. An RDAP server that receives a query containing identification information associated with a recognized OP MUST perform the steps required to authenticate the user with the OP, process the query, and return an RDAP response that is appropriate for the end user's level of authorization and access.
認識されていないクエリパラメーターは無視する必要があります。認証されたクエリを処理するRDAPサーバーは、エンドユーザー識別情報がサーバーによって認識およびサポートされているOPに関連付けられているかどうかを判断する必要があります。RDAPサーバーは、HTTP 400（悪い要求）応答を返すことにより、サポートされているOPに関連付けられていない識別情報を含むクエリを拒否する必要があります。認識されたOPに関連付けられた識別情報を含むクエリを受信するRDAPサーバーは、OPでユーザーを認証し、クエリを処理し、エンドユーザーの認証とアクセスのレベルに適したRDAP応答を返すために必要な手順を実行する必要があります。
This specification adds the following features to RDAP that are commonly used by session-oriented clients:
この仕様は、セッション指向のクライアントが一般的に使用するRDAPに次の機能を追加します。
1. Data structures to return information that describes an established session and the information needed to establish a session for a UI-constrained device.
1. 確立されたセッションと、UIが制約したデバイスのセッションを確立するために必要な情報を説明する情報を返すデータ構造。
2. A query parameter to request authentication for a specific end-user identity.
2. 特定のエンドユーザーIDの認証を要求するクエリパラメーター。
3. A query parameter to support authentication for a specific end-user identity on a device with a constrained user interface.
3. 制約されたユーザーインターフェイスを備えたデバイス上の特定のエンドユーザーIDの認証をサポートするクエリパラメーター。
4. A query parameter to identify the purpose of the query.
4. クエリの目的を識別するクエリパラメーター。
5. A query parameter to request that the server not log or otherwise record information about the identity associated with a query.
5. クエリパラメーターは、サーバーがクエリに関連付けられているIDに関する情報を記録するか、その他の方法で記録することを要求します。
6. Path segments to start, stop, refresh, and determine the status of an authenticated session for a specific end-user identity.
6. 特定のエンドユーザーアイデンティティの認証セッションのステータスを開始、停止、更新、および決定するパスセグメント。
This specification describes two new data structures that are used to return information to a session-oriented client:
この仕様では、セッション指向のクライアントに情報を返すために使用される2つの新しいデータ構造について説明します。
"farv1_session":
「FARV1_SESSION」：
A data structure that contains information that describes an established session.
確立されたセッションを説明する情報を含むデータ構造。
"farv1_deviceInfo":
「FARV1_DEVICEINFO」：
A data structure that contains information that describes an active attempt to establish a session on a UI-constrained device.
UIが制約したデバイスでセッションを確立しようとする積極的な試みを説明する情報を含むデータ構造。
The "farv1_session" data structure is an object that contains the following members:
「FARV1_SESSION」データ構造は、次のメンバーを含むオブジェクトです。
"userID":
"ユーザーID"：
an OPTIONAL string value that represents the end-user identifier associated with the session.
セッションに関連付けられたエンドユーザー識別子を表すオプションの文字列値。
"iss":
「ISS」：
an OPTIONAL URI value that represents the issuer of the end-user identifier associated with the session.
セッションに関連付けられたエンドユーザー識別子の発行者を表すオプションのURI値。
"userClaims":
「userclaims」：
an OPTIONAL object that contains the set of claims associated with the end user's identity based on the user information provided by the OP as described in Section 3.1.4.6 and processed by the RDAP server in the authentication and authorization process. The set of possible values is determined by OP policy and RDAP server policy.
セクション3.1.4.6で説明され、認証および承認プロセスでRDAPサーバーによって処理されたOPが提供するユーザー情報に基づいて、エンドユーザーのIDに関連付けられた一連のクレームを含むオプションオブジェクト。可能な値のセットは、OPポリシーとRDAPサーバーポリシーによって決定されます。
"sessionInfo":
「sessioninfo」：
an OPTIONAL object that contains two members:
2人のメンバーを含むオプションのオブジェクト：
"tokenExpiration":
「tokenexpiration」：
an integer value that represents the number of seconds that remain in the lifetime of the access token.
アクセストークンの寿命に残っている秒数を表す整数値。
"tokenRefresh":
「tokenrefresh」：
a boolean value that indicates if the OP supports refresh tokens. As described in [RFC6749], support for refresh tokens is OPTIONAL.
OPが更新トークンをサポートするかどうかを示すブール値。[RFC6749]で説明されているように、更新トークンのサポートはオプションです。
Note that all of the members of the "farv1_session" data structure are OPTIONAL. See Section 5.2.3 for instructions describing when to return the minimum set of members.
「FARV1_Session」データ構造のすべてのメンバーはオプションであることに注意してください。メンバーの最小セットをいつ返すかを説明する手順については、セクション5.2.3を参照してください。
An example of a "farv1_session" data structure:
「FARV1_SESSION」データ構造の例：
"farv1_session": {
"userID": "user.idp.example",
"iss": "https://idp.example.com",
"userClaims": {
"sub": "103892603076825016132",
"name": "User Person",
"given_name": "User",
"family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"rdap_allowed_purposes": [
"domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
},
"sessionInfo": {
"tokenExpiration": 3599,
"tokenRefresh": true
}
}
Figure 6
The flow described in Section 3.1.4 requires an end user to interact with a server using a user interface that can process HTTP. This will not work well in situations where the client is automated or an end user is using a command-line user interface such as curl (https://curl.se/) or wget (https://www.gnu.org/software/wget/). This limitation can be addressed using a web browser on a second device. The information that needs to be entered using the web browser is contained in the "farv1_deviceInfo" data structure, an object that contains members as described in Section 3.2 of [RFC8628].
セクション3.1.4で説明されているフローでは、エンドユーザーがHTTPを処理できるユーザーインターフェイスを使用してサーバーと対話する必要があります。これは、クライアントが自動化されている場合やエンドユーザーがCurl（https://curl.se/）やwget（https://www.gnu.org/などのコマンドラインユーザーインターフェイスを使用している状況ではうまく機能しません。ソフトウェア/wget/）。この制限は、2番目のデバイスでWebブラウザを使用して対処できます。Webブラウザーを使用して入力する必要がある情報は、[RFC8628]のセクション3.2で説明されているメンバーを含むオブジェクトである「FARV1_DEVICEINFO」データ構造に含まれています。
An example of a "farv1_deviceInfo" data structure:
「FARV1_DEVICEINFO」データ構造の例：
"farv1_deviceInfo": {
"device_code": "AH-1ng2ezu",
"user_code": "NJJQ-GJFC",
"verification_uri": "https://www.example.com/device",
"verification_uri_complete":
"https://www.example.com/device?user_code=NJJQ-GJFC",
"expires_in": 1800,
"interval": 5
}
Figure 7
Client authentication is requested by sending a "farv1_session/login" request to an RDAP server. If the RDAP server supports only remote OPs, the "farv1_session/login" request MUST include at least one end-user identifier or OP Issuer Identifier.
クライアント認証は、RDAPサーバーに「FARV1_SESSION/LOGIN」要求を送信することにより要求されます。RDAPサーバーがリモートOPSのみをサポートする場合、「FARV1_SESSION/LOGIN」要求には、少なくとも1つのエンドユーザー識別子またはOP発行者識別子を含める必要があります。
The server sets an HTTP cookie as described in [RFC6265] when the "farv1_session/login" request is received and processed successfully. The client MUST include the session cookie received from the server in any RDAP request within the scope of that session, including "farv1_session/refresh", "farv1_session/status", and "farv1_session/ logout". A "farv1_session/login" followed by another "farv1_session/ login" that does not include an HTTP cookie MUST start a new session on the server that includes a new cookie. A server that receives a "farv1_session/login" followed by another "farv1_session/login" that includes an HTTP cookie MUST return an HTTP 409 (Conflict) response.
サーバーは、[FARV1_SESSION/LOGIN]リクエストが受信され、正常に処理されたときに[RFC6265]で説明されているようにHTTP Cookieを設定します。クライアントは、「FARV1_Session/Refresh」、「FARV1_SESSION/STATUS」、「FARV1_SESSION/LOGOUT」など、そのセッションの範囲内のRDAP要求でサーバーから受信したセッションCookieを含める必要があります。「FARV1_SESSION/ LOGIN」に続いて、HTTP Cookieが含まれていない別の「FARV1_SESSION/ LOGIN」が続き、新しいCookieを含むサーバー上の新しいセッションを開始する必要があります。HTTP Cookieを含む別の「FARV1_SESSION/LOGIN」が続く「FARV1_SESSION/LOGIN」を受信するサーバーは、HTTP 409（競合）応答を返す必要があります。
To help reduce the risk of resource starvation, a server MAY reject a "farv1_session/login" request and refuse to start a new session by returning an HTTP 409 (Conflict) response if a server-side maximum number of concurrent sessions per user exists and the client exceeds that limit. Additionally, an active session MAY be removed by the server due to timeout expiration or because a maximum session lifetime has been exceeded. Clients SHOULD proactively monitor the "tokenExpiration" value associated with an active session and refresh the session as appropriate to provide a positive user experience.
リソースの飢vのリスクを軽減するために、サーバーは「FARV1_SESSION/LOGIN」要求を拒否し、ユーザーごとにサーバー側の最大数の同時セッションが存在する場合、HTTP 409（競合）応答を返すことにより新しいセッションを開始することを拒否する場合があります。クライアントはその制限を超えています。さらに、タイムアウトの有効期限または最大セッションの寿命が超えたため、サーバーによってアクティブなセッションが削除される場合があります。クライアントは、アクティブなセッションに関連付けられた「トークンエクスピア」値を積極的に監視し、適切にセッションを更新して、ポジティブなユーザーエクスペリエンスを提供する必要があります。
The end-user identifier is delivered using one of two methods: by adding a query component to an RDAP request URI using the syntax described in Section "application/x-www-form-urlencoded" of [HTMLURL] or by including an HTTP "authorization" request header for the Basic authentication scheme as described in [RFC7617]. Clients can use either of these methods to deliver the end-user identifier to a server that supports remote OPs and provider discovery. Servers that support remote OPs and provider discovery MUST accept both methods. If the RDAP server supports a default OP or if provider discovery is not supported, the end-user identifier MAY be omitted.
エンドユーザー識別子は、2つの方法のいずれかを使用して配信されます。[htmlurl]のセクション「アプリケーション/x-www-form-urlencoded」のセクションで説明されている構文を使用して、rdap要求URIにクエリコンポーネントを追加するか、httpを含む」承認「[RFC7617]に記載されている基本認証スキームのヘッダーを要求します。クライアントは、これらのメソッドのいずれかを使用して、エンドユーザー識別子をリモートオペレーションとプロバイダーの発見をサポートするサーバーに配信できます。リモートOPSとプロバイダーの発見をサポートするサーバーは、両方の方法を受け入れる必要があります。RDAPサーバーがデフォルトのOPをサポートする場合、またはプロバイダーの発見がサポートされていない場合、エンドユーザー識別子は省略できます。
The query parameter used to deliver the end-user identifier is represented as an OPTIONAL "key=value" pair using a key value of "farv1_id" and a value component that contains the client identifier issued by an OP. An example for client identifier "user.idp.example":
エンドユーザー識別子の配信に使用されるクエリパラメーターは、「FARV1_ID」のキー値とOPによって発行されたクライアント識別子を含む値コンポーネントを使用して、オプションの「key = value」ペアとして表されます。クライアント識別子の例「user.idp.example」：
========== NOTE: '\' line wrapping per RFC 8792 ===========
https://example.com/rdap/farv1_session/\
login?farv1_id=user.idp.example
Figure 8
The authorization header for the Basic authentication scheme contains a base64-encoded representation of the client identifier issued by an OP. No password is provided. An example for client identifier "user.idp.example":
基本認証スキームの承認ヘッダーには、OPによって発行されたクライアント識別子のBase64エンコードされた表現が含まれています。パスワードは提供されていません。クライアント識別子の例「user.idp.example」：
https://example.com/rdap/farv1_session/login
Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==
Figure 9
An example for use with a default OP:
デフォルトOPで使用する例：
https://example.com/rdap/farv1_session/login
Figure 10
The OP's Issuer Identifier is delivered by adding a query component to an RDAP request URI using the syntax described in Section "application/x-www-form-urlencoded" of [HTMLURL]. If the RDAP server supports a default OP, the Issuer Identifier MAY be omitted.
OPの発行者識別子は、[htmlurl]の「アプリケーション/x-www-form-urlencoded」セクションで説明されている構文を使用して、RDAP要求URIにクエリコンポーネントを追加することにより配信されます。RDAPサーバーがデフォルトのOPをサポートする場合、発行者識別子は省略される場合があります。
The query parameter used to deliver the OP's Issuer Identifier is represented as an OPTIONAL "key=value" pair using a key value of "farv1_iss" and a value component that contains the Issuer Identifier associated with an OP. An RDAP server MAY accept Issuer Identifiers not specified in the "farv1_openidcConfiguration" data structure and MAY also decide to accept specific Issuer Identifiers only from specific clients. An example for Issuer Identifier "https://idp.example.com":
OPの発行者識別子を配信するために使用されるクエリパラメーターは、「FARV1_ISS」のキー値とOPに関連付けられた発行者識別子を含む値コンポーネントを使用して、オプションの「key = value」ペアとして表されます。RDAPサーバーは、「FARV1_OPENIDCCONFIGURATION」データ構造で指定されていない発行者識別子を受け入れる場合があり、特定のクライアントからのみ特定の発行者識別子を受け入れることもできます。発行者識別子の例「https://idp.example.com」：
========== NOTE: '\' line wrapping per RFC 8792 ===========
https://example.com/rdap/farv1_session/\
login?farv1_iss=https://idp.example.com
Figure 11
The response to this request MUST be a valid RDAP response per [RFC9083]. It MUST NOT include any members that relate to a specific RDAP object type (e.g., "events" or "status"). In addition, the response MAY include an indication of the requested operation's success or failure in the "notices" data structure. If successful, the response MUST include a "farv1_session" data structure that includes a "sessionInfo" object and an OPTIONAL "userClaims" object. If unsuccessful, the response MUST include a "farv1_session" data structure that omits the "userClaims" and "sessionInfo" objects.
この要求に対する応答は、[RFC9083]ごとに有効なRDAP応答でなければなりません。特定のRDAPオブジェクトタイプ（「イベント」または「ステータス」など）に関連するメンバーを含めてはなりません。さらに、応答には、「通知」データ構造における要求された操作の成功または失敗の兆候が含まれる場合があります。成功した場合、応答には、「sessioninfo」オブジェクトとオプションの「userclaims」オブジェクトを含む「farv1_session」データ構造を含める必要があります。失敗した場合、応答には、「userclaims」および「sessioninfo」オブジェクトを省略する「FARV1_SESSION」データ構造を含める必要があります。
An example of a successful "farv1_session/login" response:
成功した「FARV1_SESSION/LOGIN」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Login Result",
"description": [
"Login succeeded"
]
}
],
"farv1_session": {
"userID": "user.idp.example",
"iss": "https://idp.example.com",
"userClaims": {
"sub": "103892603076825016132",
"name": "User Person",
"given_name": "User",
"family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"rdap_allowed_purposes": [
"domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
},
"sessionInfo": {
"tokenExpiration": 3599,
"tokenRefresh": true
}
}
}
Figure 12
An example of a failed "farv1_session/login" response:
失敗した「FARV1_SESSION/LOGIN」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Login Result",
"description": [
"Login failed"
]
}
],
"farv1_session": {
"userID": "user.idp.example",
"iss": "https://idp.example.com"
}
}
Figure 13
"OAuth 2.0 Device Authorization Grant" [RFC8628] provides an OPTIONAL method to request user authorization from devices that have an Internet connection but lack a suitable browser for a more conventional OAuth flow. This method requires an end user to use a second device (such as a smartphone) that has access to a web browser for entry of a code sequence that is presented on the UI-constrained device.
「OAUTH 2.0デバイス認証助成金」[RFC8628]は、インターネット接続を備えたデバイスからユーザー認証を要求するオプションの方法を提供しますが、より一般的なOAuthフローには適したブラウザがありません。この方法では、エンドユーザーが、UIが制約したデバイスに表示されるコードシーケンスの入力のためにWebブラウザにアクセスできる2番目のデバイス（スマートフォンなど）を使用する必要があります。
Client authentication is requested by sending a "farv1_session/ device" request to an RDAP server. If the RDAP server supports only remote OPs, the "farv1_session/device" request MUST include either an end-user identifier as described in Section 5.2.1 or an OP Issuer Identifier as described in Section 5.2.2.
クライアント認証は、RDAPサーバーに「FARV1_Session/ Device」リクエストを送信することにより要求されます。RDAPサーバーがリモートOPSのみをサポートする場合、「FARV1_SESSION/デバイス」要求には、セクション5.2.1で説明されているエンドユーザー識別子またはセクション5.2.2で説明されているOP発行者識別子のいずれかを含める必要があります。
An example using wget for client identifier "user.idp.example":
クライアント識別子にWGETを使用する例 "user.idp.example"：
========== NOTE: '\' line wrapping per RFC 8792 ===========
wget -qO- "https://example.com/rdap/farv1_session/device\
?farv1_id=user.idp.example"
Figure 14
The authorization header for the Basic authentication scheme contains a base64-encoded representation of the client identifier issued by an OP. No password is provided.
基本認証スキームの承認ヘッダーには、OPによって発行されたクライアント識別子のBase64エンコードされた表現が含まれています。パスワードは提供されていません。
An example using curl and an authorization header:
Curlと承認ヘッダーを使用した例：
========== NOTE: '\' line wrapping per RFC 8792 ===========
curl -H "Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ=="\
"https://example.com/rdap/farv1_session/device"
Figure 15
The response to this request MUST be a valid RDAP response per [RFC9083]. It MUST NOT include any members that relate to a specific RDAP object type (e.g., "events" or "status"). In addition, the response MAY include an indication of the requested operation's success or failure in the "notices" data structure and, if successful, a "farv1_deviceInfo" data structure.
この要求に対する応答は、[RFC9083]ごとに有効なRDAP応答でなければなりません。特定のRDAPオブジェクトタイプ（「イベント」または「ステータス」など）に関連するメンバーを含めてはなりません。さらに、応答には、「通知」データ構造における要求された操作の成功または失敗の兆候と、成功した場合、「FARV1_DEVICEINFO」データ構造が含まれる場合があります。
An example of a "farv1_session/device" response:
「farv1_session/device」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Device Login Result",
"description": [
"Login succeeded"
]
}
],
"farv1_deviceInfo": {
"device_code": "AH-1ng2ezu",
"user_code": "NJJQ-GJFC",
"verification_uri": "https://www.example.com/device",
"verification_uri_complete":
"https://www.example.com/device?user_code=NJJQ-GJFC",
"expires_in": 1800,
"interval": 5
}
}
Figure 16
After successful processing of the "farv1_session/device" request, the client MUST send a "farv1_session/devicepoll" request to the RDAP server to continue the login process. This request initiates the polling function described in [RFC8628] on the RDAP server. The RDAP server polls the OP as described in Section 3.4 of [RFC8628], allowing the RDAP server to wait for the end user to enter the information returned from the "farv1_session/device" request using the interface on their second device. After the end user has completed that process, or if the process fails or times out, the OP will respond to the polling requests with an indication of success or failure. If the RDAP server supports only remote OPs, the "farv1_session/devicepoll" request MUST include either an end-user identifier as described in Section 5.2.1 or an OP Issuer Identifier as described in Section 5.2.2.
「FARV1_Session/Device」リクエストの処理が成功した後、クライアントはRDAPサーバーに「FARV1_SESSION/DEVICEPOLL」リクエストを送信して、ログインプロセスを継続する必要があります。この要求は、RDAPサーバーの[RFC8628]で説明されているポーリング機能を開始します。RDAPサーバーは、[RFC8628]のセクション3.4で説明されているようにOPを投票し、RDAPサーバーがエンドユーザーが2番目のデバイスのインターフェイスを使用して「FARV1_Session/デバイス」要求から返される情報を入力できるようにします。エンドユーザーがそのプロセスを完了した後、またはプロセスが失敗またはタイムアウトした場合、OPは成功または失敗を示してポーリングリクエストに応答します。RDAPサーバーがリモートOPSのみをサポートする場合、「FARV1_SESSION/DEVICEPOLL」要求には、セクション5.2.1で説明されているエンドユーザー識別子またはセクション5.2.2で説明されているOP発行者識別子のいずれかを含める必要があります。
The "farv1_session/devicepoll" request MUST also include a "farv1_dc" query parameter. The query parameter is represented as an OPTIONAL "key=value" pair using a key value of "farv1_dc" and a value component that contains the value of the device_code that was returned in the response to the "farv1_session/device" request.
「FARV1_SESSION/DEVICEPOLL」要求には、「FARV1_DC」クエリパラメーターも含める必要があります。クエリパラメーターは、「FARV1_DC」のキー値を使用したオプションの「key = value」ペアとして表現され、「farv1_session/device」リクエストへの応答で返されたdevice_codeの値を含む値コンポーネントとして表されます。
An example using wget:
WGETを使用した例：
========== NOTE: '\' line wrapping per RFC 8792 ===========
wget -qO- --keep-session-cookies --save-cookies cookie.txt\
"https://example.com/rdap/farv1_session/devicepoll\
?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"
Figure 17
An example using curl:
カールを使用した例：
========== NOTE: '\' line wrapping per RFC 8792 ===========
curl -c cookie.txt "https://example.com/rdap/farv1_session/\
devicepoll?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"
Figure 18
The response to this request MUST use the response structures described in Section 5.2. RDAP query processing can continue normally on the UI-constrained device once the device polling process has been completed successfully.
この要求に対する応答は、セクション5.2で説明されている応答構造を使用する必要があります。RDAPクエリ処理は、デバイスのポーリングプロセスが正常に完了すると、UI制御デバイスで正常に継続できます。
Clients MAY send a query to an RDAP server to determine the status of an existing login session using a "farv1_session/status" path segment. An example "farv1_session/status" request:
クライアントは、「FARV1_Session/Status」パスセグメントを使用して既存のログインセッションのステータスを決定するために、RDAPサーバーにクエリを送信できます。「FARV1_SESSION/STATUS」リクエストの例：
https://example.com/rdap/farv1_session/status
Figure 19
The response to this request MUST be a valid RDAP response per [RFC9083]. It MUST NOT include any members that relate to a specific RDAP object type (e.g., "events" or "status"). In addition, the response MAY include an indication of the requested operation's success or failure in the "notices" data structure. If the operation is successful and an active session exists, the response MUST include a "farv1_session" data structure that includes a "sessionInfo" object and an OPTIONAL "userClaims" object. If the operation is unsuccessful or if no active session exists, the response MUST NOT include a "farv1_session" object.
この要求に対する応答は、[RFC9083]ごとに有効なRDAP応答でなければなりません。特定のRDAPオブジェクトタイプ（「イベント」または「ステータス」など）に関連するメンバーを含めてはなりません。さらに、応答には、「通知」データ構造における要求された操作の成功または失敗の兆候が含まれる場合があります。操作が成功し、アクティブなセッションが存在する場合、応答には、「sessioninfo」オブジェクトとオプションの「userClaim」オブジェクトを含む「FARV1_SESSION」データ構造を含める必要があります。操作が失敗した場合、またはアクティブなセッションが存在しない場合、応答には「FARV1_SESSION」オブジェクトを含めてはなりません。
An example of a "farv1_session/status" response for an active session:
アクティブセッションの「FARV1_SESSION/STATUS」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Session Status Result",
"description": [
"Session status succeeded"
]
}
],
"farv1_session": {
"userID": "user.idp.example",
"iss": "https://idp.example.com",
"userClaims": {
"sub": "103892603076825016132",
"name": "User Person",
"given_name": "User",
"family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"rdap_allowed_purposes": [
"domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
},
"sessionInfo": {
"tokenExpiration": 3490,
"tokenRefresh": true
}
}
}
Figure 20
If the operation is successful and an active session does not exist, the response MAY note the lack of an active session in the "notices" data structure. The "farv1_session" data structure MUST be omitted.
操作が成功し、アクティブなセッションが存在しない場合、応答は「通知」データ構造にアクティブなセッションがないことに注意する場合があります。「FARV1_SESSION」データ構造は省略する必要があります。
An example of a "farv1_session/status" response with no active session:
アクティブセッションなしの「FARV1_SESSION/STATUS」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Session Status Result",
"description": [
"Session status succeeded",
"No active session"
]
}
]
}
Figure 21
Clients MAY send a request to an RDAP server to refresh or extend an existing login session using a "farv1_session/refresh" path segment. The RDAP server MAY attempt to refresh the access token associated with the current session as part of extending the session for a period of time determined by the RDAP server. As described in [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP server MUST determine if the OP supports token refresh and process the refresh request by either requesting refresh of the access token or returning a response that indicates that token refresh is not supported by the OP in the "notices" data structure. An example "farv1_session/refresh" request:
クライアントは、RDAPサーバーにリクエストを送信して、「FARV1_Session/更新」パスセグメントを使用して既存のログインセッションを更新または拡張できます。RDAPサーバーは、RDAPサーバーによって決定された期間セッションを延長する一環として、現在のセッションに関連付けられたアクセストークンを更新しようとする場合があります。[RFC6749]で説明されているように、更新トークンのOPサポートはオプションです。RDAPサーバーは、OPがトークンの更新をサポートし、アクセストークンの更新を要求するか、トークンの更新が「通知」データ構造のOPによってサポートされていないことを示す応答を返すことにより、更新リクエストを処理するかどうかを判断する必要があります。「FARV1_SESSION/REFRESH」リクエストの例：
https://example.com/rdap/farv1_session/refresh
Figure 22
The response to this request MUST be a valid RDAP response per [RFC9083]. It MUST NOT include any members that relate to a specific RDAP object type (e.g., "events" or "status"). In addition, the response MAY include an indication of the requested operation's success or failure in the "notices" data structure. The response MUST include a "farv1_session" data structure that includes a "sessionInfo" object and an OPTIONAL "userClaims" object. If unsuccessful but an active session exists, the response MUST include a "farv1_session" data structure that includes a "sessionInfo" object and an OPTIONAL "userClaims" object. If unsuccessful and no active session exists, the response MUST omit the "farv1_session" data structure.
この要求に対する応答は、[RFC9083]ごとに有効なRDAP応答でなければなりません。特定のRDAPオブジェクトタイプ（「イベント」または「ステータス」など）に関連するメンバーを含めてはなりません。さらに、応答には、「通知」データ構造における要求された操作の成功または失敗の兆候が含まれる場合があります。応答には、「sessioninfo」オブジェクトとオプションの「userclaims」オブジェクトを含む「farv1_session」データ構造を含める必要があります。失敗したがアクティブなセッションが存在する場合、応答には、「sessionInfo」オブジェクトとオプションの「usercraims」オブジェクトを含む「FARV1_SESSION」データ構造を含める必要があります。失敗し、アクティブなセッションが存在しない場合、応答は「FARV1_SESSION」データ構造を省略する必要があります。
An example of a successful "farv1_session/refresh" response:
成功した「FARV1_SESSION/REFRESH」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Session Refresh Result",
"description": [
"Session refresh succeeded",
"Token refresh succeeded."
]
}
],
"farv1_session": {
"userID": "user.idp.example",
"iss": "https://idp.example.com",
"userClaims": {
"sub": "103892603076825016132",
"name": "User Person",
"given_name": "User",
"family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"rdap_allowed_purposes": [
"domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
},
"sessionInfo": {
"tokenExpiration": 3599,
"tokenRefresh": true
}
}
}
Figure 23
Alternatively, an RDAP server MAY attempt to refresh an access token upon receipt of a query if the access token associated with an existing session has expired and the corresponding OP supports token refresh. The default RDAP server behavior is described in the "implicitTokenRefreshSupported" value that's included in the "farv1_openidcConfiguration" data structure (see Section 4.1).
あるいは、RDAPサーバーは、既存のセッションに関連付けられたアクセストークンが失効し、対応するOPがトークンの更新をサポートしている場合、クエリの受領時にアクセストークンを更新しようとする場合があります。デフォルトのRDAPサーバーの動作は、「FARV1_OPENIDCCONFIGURATION」データ構造に含まれる「InflicittokenRefreshSported」値で説明されています（セクション4.1を参照）。
If the value of "implicitTokenRefreshSupported" is "true", the client MAY either explicitly attempt to refresh the session using the "farv1_session/refresh" query or depend on the RDAP server to attempt to refresh the session as necessary when an RDAP query is received by the server. In this case, a server MUST attempt to refresh the access token upon receipt of a query if the access token associated with an existing session has expired and the corresponding OP supports token refresh. Servers MUST return an HTTP 401 (Unauthorized) response to a query if an attempt to implicitly refresh an existing session fails.
「InflicittokenRefreshSupported」の値が「真」である場合、クライアントは「FARV1_SESSION/更新」クエリを使用してセッションを明示的に更新しようとするか、RDAPサーバーに依存してRDAPクエリを受信したときに必要に応じてセッションを更新しようとすることができます。サーバーによって。この場合、サーバーは、既存のセッションに関連付けられたアクセストークンが有効になり、対応するOPがトークンの更新をサポートしている場合、クエリを受け取ったときにアクセストークンを更新しようと試みる必要があります。サーバーは、既存のセッションを暗黙的に更新しようとする試みが失敗した場合、クエリに対するHTTP 401（不正な）応答をクエリに返す必要があります。
If the value of "implicitTokenRefreshSupported" is "false", the client MUST explicitly attempt to refresh the session using the "farv1_session/refresh" query to extend an existing session. If a session cannot be extended for any reason, the client MUST establish a new session to continue authenticated query processing by submitting a "farv1_session/login" query. If the OP does not support token refresh, the client MUST submit a new "farv1_session/login" request to establish a new session once an access token has expired.
「InflicittokenRefreshSupported」の値が「false」である場合、クライアントは「FARV1_Session/更新」クエリを使用してセッションを明示的に更新して、既存のセッションを拡張する必要があります。何らかの理由でセッションを拡張できない場合、クライアントは「FARV1_SESSION/LOGIN」クエリを送信して、認証されたクエリ処理を継続するために新しいセッションを確立する必要があります。OPがトークンの更新をサポートしていない場合、クライアントは、アクセストークンが失効したら、新しいセッションを確立するために新しい「FARV1_SESSION/LOGIN」リクエストを送信する必要があります。
Clients SHOULD NOT send a "farv1_session/refresh" request in the absence of an active login session because the request conflicts with the current state of the server. Servers MUST return an HTTP 409 (Conflict) response if a "farv1_session/refresh" request is received in the absence of a session cookie.
クライアントは、リクエストがサーバーの現在の状態と競合するため、アクティブログインセッションがない場合は「FARV1_SESSION/更新」要求を送信しないでください。セッションCookieがない場合に「FARV1_SESSION/REFRESH」リクエストが受信された場合、サーバーはHTTP 409（競合）応答を返す必要があります。
Clients MAY send a request to an RDAP server to terminate an existing login session. Termination of a session is requested using a "farv1_session/logout" path segment. Access and refresh tokens can be revoked during the "farv1_session/logout" process as described in [RFC7009] if supported by the OP (token revocation endpoint support is OPTIONAL per [RFC8414]). If supported, this feature SHOULD be used to ensure that the tokens are not mistakenly associated with a future RDAP session. Alternatively, an RDAP server MAY attempt to log out from the OP using the OpenID Connect RP-Initiated Logout protocol [OIDCL] if that protocol is supported by the OP. In any case, to prevent abuse before the cookie times out, an RDAP server SHOULD invalidate the HTTP cookie associated with the session as part of terminating the session.
クライアントは、RDAPサーバーにリクエストを送信して、既存のログインセッションを終了できます。セッションの終了は、「FARV1_SESSION/LOGOUT」パスセグメントを使用して要求されます。OPでサポートされている場合、[RFC7009]で説明されている「FARV1_SESSION/LOGOUT」プロセス中に、アクセスと更新のトークンを取り消すことができます（トークン取消エンドポイントサポートは[RFC8414]ごとにオプションです）。サポートされている場合、この機能は、トークンが将来のRDAPセッションに誤って関連付けられていないことを確認するために使用する必要があります。あるいは、RDAPサーバーは、そのプロトコルがOPによってサポートされている場合、OpenID Connect RP開始ログアウトプロトコル[OIDCL]を使用してOPからログアウトしようとする場合があります。いずれにせよ、Cookieがタイムする前に乱用を防ぐために、RDAPサーバーは、セッションの終了の一環として、セッションに関連付けられたHTTP Cookieを無効にする必要があります。
An example "farv1_session/logout" request:
「FARV1_SESSION/LOGOUT」リクエストの例：
https://example.com/rdap/farv1_session/logout
Figure 24
The response to this request MUST be a valid RDAP response per [RFC9083]. It MUST NOT include any members that relate to a specific RDAP object type (e.g., "events" or "status"). In addition, the response MAY include an indication of the requested operation's success or failure in the "notices" data structure. The "notices" data structure MAY include an indication of the success or failure of any attempt to logout from the OP or to revoke the tokens issued by the OP.
この要求に対する応答は、[RFC9083]ごとに有効なRDAP応答でなければなりません。特定のRDAPオブジェクトタイプ（「イベント」または「ステータス」など）に関連するメンバーを含めてはなりません。さらに、応答には、「通知」データ構造における要求された操作の成功または失敗の兆候が含まれる場合があります。「通知」データ構造には、OPからログアウトしようとする試みの成功または失敗の兆候、またはOPが発行したトークンを取り消すことが含まれます。
An example of a "farv1_session/logout" response:
「farv1_session/logout」応答の例：
{
"rdapConformance": [
"farv1"
],
"lang": "en-US",
"notices": [
{
"title": "Logout Result",
"description": [
"Logout succeeded"
"Provider logout failed: Not supported by provider.",
"Token revocation successful."
]
}
]
}
Figure 25
In the absence of a "logout" request, an RDAP session MUST be terminated by the RDAP server after a server-defined period of time. The server SHOULD also take appropriate steps to ensure that the tokens associated with the terminated session cannot be reused. This SHOULD include revoking the tokens or logging out from the OP if either operation is supported by the OP.
「ログアウト」要求がない場合、RDAPセッションは、サーバー定義の期間後にRDAPサーバーによって終了する必要があります。また、サーバーは、終了セッションに関連付けられたトークンを再利用できないことを確認するために適切な措置を講じる必要があります。これには、いずれかの操作がOPによってサポートされている場合、トークンを取り消すか、OPからログアウトすることが含まれます。
The requests described in this document are typically performed in a specific sequence:
このドキュメントで説明されている要求は、通常、特定のシーケンスで実行されます。
1. "farv1_session/login" (or the related "farv1_session/device" and "farv1_session/devicepoll" requests) to start a session,
1. 「farv1_session/login」（または関連する「farv1_session/device」および「farv1_session/devicepoll」要求）セッションを開始するために、
2. "farv1_session/status" and/or "farv1_session/refresh" to manage a session,
2. セッションを管理するための「FARV1_SESSION/STATUS」および/または「FARV1_SESSION/更新」、
3. and "farv1_session/logout" to end a session.
3. セッションを終了するための「FARV1_SESSION/LOGOUT」。
If a client sends a "farv1_session/status", "farv1_session/refresh", or "farv1_session/logout" request in the absence of a session cookie, the server MUST return an HTTP 409 (Conflict) error.
クライアントがセッションCookieがない場合に「FARV1_SESSION/STATUS」、「FARV1_SESSION/REFRESH」、または「FARV1_Session/Logout」要求を送信する場合、サーバーはHTTP 409（競合）エラーを返す必要があります。
A client can end a session explicitly by sending a "farv1_session/ logout" request to the RDAP server. A session can also be ended implicitly by the server after a server-defined period of time. The status of a session can be determined at any time by sending a "farv1_session/status" query to the RDAP server.
クライアントは、RDAPサーバーに「FARV1_Session/ Logout」リクエストを送信することにより、セッションを明示的に終了できます。セッションは、サーバー定義の期間後にサーバーによって暗黙的に終了することもできます。セッションのステータスは、RDAPサーバーに「FARV1_Session/Status」クエリを送信することにより、いつでも決定できます。
An RDAP server MUST maintain session state information for the duration of an active session. This is commonly done using HTTP cookies as described in [RFC6265]. Doing so allows end users to submit queries without having to explicitly identify and authenticate themselves for every query.
RDAPサーバーは、アクティブセッションの期間中、セッション状態情報を維持する必要があります。これは、[RFC6265]で説明されているように、HTTP Cookieを使用して一般的に行われます。そうすることで、エンドユーザーは、すべてのクエリに対して明示的に識別および認証することなくクエリを送信できます。
An RDAP server can receive queries that include a session cookie where the associated session has expired or is otherwise unavailable (e.g., due to the user requesting explicit logout for the associated session). The server MUST return an HTTP 401 (Unauthorized) error in response to such queries.
RDAPサーバーは、関連するセッションの有効期限が切れている、または利用できないセッションCookieを含むクエリを受信できます（たとえば、ユーザーが関連するセッションの明示的なログアウトを要求するため）。サーバーは、そのようなクエリに応じてHTTP 401（不正）エラーを返す必要があります。
This specification adds additional processing steps for token-oriented clients as described in this section and Section 3.1.3. It does not define additional data structures or RDAP-specific protocol parameters specifically for token-oriented clients.
この仕様は、このセクションとセクション3.1.3で説明されているように、トークン指向のクライアントに追加の処理手順を追加します。トークン指向のクライアント向けに特に追加のデータ構造またはRDAP固有のプロトコルパラメーターを定義しません。
Clients identify and authenticate end users by exchanging information with an OP that is recognized by the RDAP server as described in Sections 3.1.4.2, 3.1.4.3, and 3.1.4.4. A client SHOULD append the "additionalAuthorizationQueryParams" values retrieved from the "openidcProviders" array described in Section 4.1 to the authorization endpoint URL when requesting authorization from the OP. Once these processes are completed successfully, the client can request tokens from the OP as described in Section 3.1.4.5. The OP SHOULD include the RDAP server's client_id in the "aud" claim value of an issued ID Token. The RDAP server MAY choose to ignore the value of the "aud" claim or exchange the token as described in Section 6.4. With these steps completed, the access token received from the OP can be passed to an RDAP server in an HTTP "authorization" request header [RFC6750] for RDAP queries that require end-user identification, authentication, and authorization.
クライアントは、セクション3.1.4.2、3.1.4.3、および3.1.4.4で説明されているように、RDAPサーバーによって認識されるOPと情報を交換することにより、エンドユーザーを特定して認証します。クライアントは、OPから認証を要求する際に、セクション4.1で説明されている「OpenIDCProviders」アレイから「OpenIDCProviders」アレイから取得された「OpenIDCProviders」アレイから取得された「追加の承認QueryParams」値を追加する必要があります。これらのプロセスが正常に完了すると、セクション3.1.4.5で説明されているように、クライアントはOPからトークンを要求できます。OPには、発行されたIDトークンの「aud」請求値にRDAPサーバーのclient_idを含める必要があります。RDAPサーバーは、セクション6.4で説明されているように、「AUD」請求の値を無視するか、トークンを交換することを選択できます。これらの手順が完了すると、OPから受信したアクセストークンを、エンドユーザーの識別、認証、および認証を必要とするRDAPクエリのHTTP「認証」要求ヘッダー[RFC6750]でRDAPサーバーに渡すことができます。
An RDAP server that receives a bearer token in an HTTP "authorization" request header as part of an RDAP object query MUST validate the token in accordance with local policy and confirm that the token is a legitimate access token. Once validated, the access token MAY be used to retrieve the claims associated with the end user's identity, including claims associated with the "rdap" scope that are not already included in the access token, as described in Section 3.1.4.6. The RDAP server can then evaluate the end user's identity information to determine the end user's authorization level and process the query in accordance with server policies. A client MUST include the "farv1_iss" query parameter and Issuer Identifier value with an RDAP query if the token was issued by a remote OP.
RDAPオブジェクトクエリの一部としてHTTP「認証」要求ヘッダーでBEARERトークンを受信するRDAPサーバーは、ローカルポリシーに従ってトークンを検証し、トークンが正当なアクセストークンであることを確認する必要があります。検証されたら、アクセストークンを使用して、セクション3.1.4.6で説明されているように、アクセストークンにまだ含まれていない「RDAP」スコープに関連付けられているクレームを含む、エンドユーザーの身元に関連するクレームを取得することができます。RDAPサーバーは、エンドユーザーのID情報を評価して、エンドユーザーの承認レベルを決定し、サーバーポリシーに従ってクエリを処理できます。クライアントは、トークンがリモートOPによって発行された場合、RDAPクエリに「FARV1_ISS」クエリパラメーターと発行者識別子値を含める必要があります。
An RDAP server MUST validate a received access token prior to using that token for access control purposes. Validation MAY include token introspection [RFC7662] using the issuing OP or analysis of the values included in a JWT access token. Once an access token is validated, an RDAP server MAY use that token to request user claims from the issuing OP.
RDAPサーバーは、アクセス制御の目的でそのトークンを使用する前に、受信したアクセストークンを検証する必要があります。検証には、JWTアクセストークンに含まれる値の発行OPまたは分析を使用したトークン内省[RFC7662]が含まれる場合があります。アクセストークンが検証されると、RDAPサーバーはそのトークンを使用して、発行opからユーザーのクレームを要求する場合があります。
There are performance considerations associated with the process of validating a token and requesting user claims as part of processing every received RDAP query. An RDAP server MAY cache validated information and use that cached information to reduce the amount of time needed to process subsequent RDAP queries associated with the same access token as long as the token has not expired. The client SHOULD monitor the token expiration time and refresh the token as needed.
トークンを検証し、受信したすべてのRDAPクエリの処理の一環としてユーザーのクレームを要求するプロセスに関連するパフォーマンスの考慮事項があります。RDAPサーバーは、検証済みの情報をキャッシュし、そのキャッシュされた情報を使用して、トークンが期限切れになっていない限り、同じアクセストークンに関連付けられた後続のRDAPクエリを処理するのに必要な時間を短縮できます。クライアントは、トークンの有効期限を監視し、必要に応じてトークンを更新する必要があります。
Tokens can include an "aud" (audience) claim that contains the OAuth 2.0 client_id of the RP as an audience value. In some operational scenarios (such as a client that is providing a proxy service), an RP can receive tokens with an "aud" claim value that does not include the RP's client_id. These tokens might not be trusted by the RP, and the RP might refuse to accept the tokens. This situation can be remedied by having the RP exchange the access token with the OP for a set of trusted tokens that reset the "aud" claim. The token exchange protocol is described in [RFC8693].
トークンには、RPのOAUTH 2.0 Client_IDをオーディエンスバリューとして含む「AUD」（オーディエンス）クレームを含めることができます。いくつかの運用シナリオ（プロキシサービスを提供しているクライアントなど）では、RPはRPのClient_IDを含まない「AUD」請求値を持つトークンを受信できます。これらのトークンはRPに信頼されていない可能性があり、RPはトークンの受け入れを拒否する可能性があります。この状況は、「AUD」クレームをリセットする一連の信頼できるトークンのOPでRP Exchange Accessトークンを交換することにより、改善できます。トークン交換プロトコルは[RFC8693]で説明されています。
Once an RDAP session is active, an RDAP server MUST determine if the end user is authorized to perform any queries that are received during the duration of the session. This MAY include rejecting queries outright, and it MAY include omitting or otherwise redacting information that the end user is not authorized to receive. Specific processing requirements are beyond the scope of this document.
RDAPセッションがアクティブになったら、RDAPサーバーは、セッション期間中に受信されたクエリを実行することをエンドユーザーが許可されているかどうかを判断する必要があります。これには、クエリの完全な拒否が含まれる場合があり、エンドユーザーが受け取る権限を与えられていない情報を省略または編集することも含まれます。特定の処理要件は、このドキュメントの範囲を超えています。
RDAP responses that contain values described in this document MUST indicate conformance with this specification by including an rdapConformance [RFC9083] value of "farv1" (federated authentication method for RDAP version 1). The information needed to register this value in the "RDAP Extensions" registry is described in Section 9.1.
このドキュメントで説明されている値を含むRDAP応答は、「FARV1」（RDAPバージョン1のフェデレーション認証方法）のRDAPCONFORMANCE [RFC9083]値を含めることにより、この仕様との適合性を示す必要があります。この値を「RDAP拡張機能」レジストリに登録するために必要な情報は、セクション9.1で説明されています。
Example rdapConformance structure with extension specified:
拡張を指定したrdapconformance構造の例：
"rdapConformance" :
[
"rdap_level_0",
"farv1"
]
Figure 26
IANA has registered the following value in the "RDAP Extensions" registry:
IANAは、「RDAP拡張機能」レジストリに次の値を登録しています。
Extension Identifier:
拡張識別子：
farv1
FARV1
Registry Operator:
レジストリオペレーター：
Any
どれでも
Specification:
仕様：
RFC 9560
RFC 9560
Contact:
接触：
IETF <iesg@ietf.org>
ietf <iesg@ietf.org>
Intended Usage:
意図された使用法：
This extension describes federated authentication method for RDAP version 1 using OAuth 2.0 and OpenID Connect.
この拡張機能は、OAUTH 2.0およびOpenID Connectを使用して、RDAPバージョン1のフェデレート認証方法について説明します。
IANA has registered the following values in the "JSON Web Token Claims" registry:
IANAは、「JSON Webトークンクレーム」レジストリに次の値を登録しています。
Claim Name:
クレーム名：
rdap_allowed_purposes
rdap_allowed_purposes
Claim Description:
クレームの説明：
This claim describes the set of RDAP query purposes that are available to an identity that is presented for access to a protected RDAP resource.
このクレームは、保護されたRDAPリソースにアクセスするために提示されるIDが利用可能なRDAPクエリ目的のセットについて説明します。
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 3.1.5.1 of RFC 9560.
RFC 9560のセクション3.1.5.1。
Claim Name:
クレーム名：
rdap_dnt_allowed
rdap_dnt_allowed
Claim Description:
クレームの説明：
This claim contains a JSON boolean literal that describes a "do not track" request for server-side tracking, logging, or recording of an identity that is presented for access to a protected RDAP resource.
このクレームには、保護されたRDAPリソースへのアクセスのために提示されるアイデンティティのサーバー側追跡、ログ、または記録の「追跡しない」要求を説明するJSONブールのリテラルが含まれています。
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 3.1.5.2 of RFC 9560.
RFC 9560のセクション3.1.5.2。
IANA has created a new protocol registry to manage RDAP query purpose values.
IANAは、RDAPクエリの目的値を管理するための新しいプロトコルレジストリを作成しました。
Section at https://www.iana.org/protocols:
https://www.iana.org/protocolsのセクション：
Registration Data Access Protocol (RDAP)
登録データアクセスプロトコル（RDAP）
Registry Name:
レジストリ名：
Registration Data Access Protocol (RDAP) Query Purpose Values
登録データアクセスプロトコル（RDAP）クエリ目的値
Registration Procedure(s):
登録手続き：
This registry is operated under the "Specification Required" policy defined in [RFC8126]. The designated expert must ensure that requests to add values to this registry meet the syntax, value, and description requirements described in this section.
このレジストリは、[RFC8126]で定義されている「必要な仕様」ポリシーの下で動作します。指定された専門家は、このレジストリに値を追加する要求が、このセクションで説明されている構文、値、および説明要件を満たすことを確認する必要があります。
Required Information:
必要な情報：
Registration requests are described in a specification that's consistent with the "Specification Required" policy defined in [RFC8126]. The specification must include one or more purpose values as described below.
登録要求は、[RFC8126]で定義されている「必要な仕様」ポリシーと一致する仕様で説明されています。仕様には、以下に説明するように、1つ以上の目的値を含める必要があります。
Individual purpose values are registered with IANA. Each entry in the registry contains the following fields:
個々の目的値はIANAに登録されています。レジストリ内の各エントリには、次のフィールドが含まれています。
Value:
値：
The purpose string value being registered. Value strings can contain uppercase ASCII characters from "A" to "Z", lowercase ASCII characters from "a" to "z", and the underscore ("_") character. Value strings contain at least one character and no more than 64 characters.
登録されている目的文字列値。Value文字列には、「A」から「Z」から大文字のASCII文字、「A」から「Z」から「ASCIIの小文字」文字、およびアンダースコア（「_」）文字が含まれます。Value文字列には、少なくとも1つの文字と64文字以下の文字が含まれています。
Description:
説明：
One or two sentences in English describing the meaning of the purpose value, how it might be used, and/or how it should be interpreted by clients and servers.
目的値の意味、使用方法、および/またはそれがクライアントとサーバーによってどのように解釈されるべきかを説明する英語の1つまたは2つの文。
Reference:
参照：
RFC 9560
RFC 9560
The set of initial values used to populate the registry as described below are derived from the final report produced by the Expert Working Group on gTLD Directory Services chartered by the Internet Corporation for Assigned Names and Numbers (ICANN) [gTLD].
以下のレジストリに登録するために使用される初期値のセットは、割り当てられた名前と数字（ICANN）[GTLD]についてインターネットコーポレーションがチャーターしたGTLDディレクトリサービスに関する専門家ワーキンググループが作成した最終レポートから派生しています。
Value:
値：
domainNameControl
DomainnameControl
Description:
説明：
Tasks within the scope of this purpose include, for a registrant's own domain name, creating the domain name, updating information about the domain name, transferring the domain name, renewing the domain name, deleting the domain name, maintaining a domain name portfolio, and detecting fraudulent use of the registrant's own contact information.
この目的の範囲内のタスクには、登録者自身のドメイン名の場合、ドメイン名の作成、ドメイン名に関する情報の更新、ドメイン名の転送、ドメイン名の更新、ドメイン名の削除、ドメイン名ポートフォリオの維持、および登録者自身の連絡先情報の不正使用の検出。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
personalDataProtection
PersonalDataProtection
Description:
説明：
Tasks within the scope of this purpose include identifying the accredited privacy or proxy provider associated with a domain name, reporting abuse, requesting reveal, or otherwise contacting the provider.
この目的の範囲内のタスクには、ドメイン名に関連付けられた認定プライバシーまたはプロキシプロバイダーの識別、乱用の報告、公開の要求、またはプロバイダーへの連絡が含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
technicalIssueResolution
TechnicalIssueresolution
Description:
説明：
Tasks within the scope of this purpose include (but are not limited to) working to resolve technical issues, including email delivery issues, DNS resolution failures, and website functionality issues.
この目的の範囲内のタスクには、電子メール配信の問題、DNS解決障害、ウェブサイトの機能の問題など、技術的な問題を解決するために作業する（ただし、これらに限定されない）が含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
domainNameCertification
domainnameCertification
Description:
説明：
Tasks within the scope of this purpose include a Certification Authority (CA) issuing an X.509 certificate to a subject identified by a domain name.
この目的の範囲内のタスクには、ドメイン名で識別された主題にX.509証明書を発行する認証機関（CA）が含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
individualInternetUse
InversureIntertuse
Description:
説明：
Tasks within the scope of this purpose include identifying the organization using a domain name to instill consumer trust or contacting that organization to raise a customer complaint to them or file a complaint about them.
この目的の範囲内のタスクには、ドメイン名を使用して消費者の信頼を植え付けるか、その組織に連絡して顧客に苦情を提起するか、それらについて苦情を申し立てるために組織を特定することが含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
businessDomainNamePurchaseOrSale
businessdomainnamepurchaseorsale
Description:
説明：
Tasks within the scope of this purpose include making purchase queries about a domain name, acquiring a domain name from a registrant, and enabling due diligence research.
この目的の範囲内のタスクには、ドメイン名に関する購入クエリの作成、登録者からドメイン名の取得、デューデリジェンス調査の実現が含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
academicPublicInterestDNSResearch
AcademicPublicInterestDnsResearch
Description:
説明：
Tasks within the scope of this purpose include academic public interest research studies about domain names published in the registration data service, including public information about the registrant and designated contacts, the domain name's history and status, and domain names registered by a given registrant (reverse query).
この目的の範囲内のタスクには、登録データサービスに公開されたドメイン名に関する学術的な公益調査研究には、登録者と指定された連絡先、ドメイン名の履歴とステータス、および特定の登録者が登録したドメイン名を含む（逆）クエリ）。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
legalActions
法的
Description:
説明：
Tasks within the scope of this purpose include investigating possible fraudulent use of a registrant's name or address by other domain names, investigating possible trademark infringement, contacting a registrant's or licensee's legal representative prior to taking legal action, and then taking a legal action if the concern is not satisfactorily addressed.
この目的の範囲内でのタスクには、他のドメイン名による登録者の名前または住所の不正使用の可能性のある使用の調査、可能性のある商標侵害の調査、法的措置を講じる前に登録者またはライセンシーの法定代理人に連絡し、懸念がある場合は法的措置を講じることが含まれます。十分に対処されていません。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
regulatoryAndContractEnforcement
規制および契約制御
Description:
説明：
Tasks within the scope of this purpose include investigating the tax authority of businesses with online presences, investigating Uniform Domain-Name Dispute-Resolution Policy (UDRP), investigating contractual compliance, and registering data escrow audits.
この目的の範囲内のタスクには、オンラインプレゼンスを持つ企業の税務当局の調査、統一ドメイン名紛争解決ポリシー（UDRP）の調査、契約上のコンプライアンスの調査、データエスクロー監査の登録が含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
criminalInvestigationAndDNSAbuseMitigation
犯罪投資およびdnsabusemitigation
Description:
説明：
Tasks within the scope of this purpose include reporting abuse to someone who can investigate and address that abuse or contacting entities associated with a domain name during an offline criminal investigation.
この目的の範囲内でのタスクには、オフラインの犯罪捜査中にドメイン名に関連する虐待または連絡先を調査および取り組むことができる人に虐待を報告することが含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Value:
値：
dnsTransparency
dnstransparency
Description:
説明：
Tasks within the scope of this purpose involve querying the registration data made public by registrants to satisfy a wide variety of use cases around informing the public.
この目的の範囲内でのタスクには、登録者が公開した登録データを照会して、一般の人々に通知することを中心にさまざまなユースケースを満たすことが含まれます。
Reference:
参照：
RFC 9560
RFC 9560
Security considerations for RDAP can be found in [RFC7481]. Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 [RFC6749] can be found in their reference specifications; best current security practice for OAuth 2.0 can be found in [OAUTH-SECURITY]. Additionally, the practices described in [RFC9325] MUST be followed when the Transport Layer Security (TLS) protocol is used.
RDAPのセキュリティ上の考慮事項は、[RFC7481]にあります。OpenID Connect Core [OIDCC]およびOAuth 2.0 [RFC6749]のセキュリティ上の考慮事項は、参照仕様にあります。OAUTH 2.0の最良のセキュリティプラクティスは、[OAuth-Security]にあります。さらに、[RFC9325]に記載されているプラクティスは、輸送層のセキュリティ（TLS）プロトコルを使用する場合に従う必要があります。
As described in Section 3.1.4.2, the OAuth 2.0 Implicit Flow [RFC6749] is considered insecure, and efforts are being made to deprecate the flow. It MUST NOT be used.
セクション3.1.4.2で説明されているように、OAUTH 2.0暗黙の流れ[RFC6749]は安全でないと考えられており、流れを非難する努力がなされています。使用してはなりません。
Some of the responses described in this specification return information to a client from an RDAP server that is intended to help the client match responses to queries and manage sessions. Some of that information, such as the "userClaims" described in Section 5.1.1, can be personally identifiable and considered sensitive if disclosed to unauthorized parties. An RDAP server operator must develop policies for information disclosure to ensure that personally identifiable information is disclosed only to clients that are authorized to process that information.
この仕様で説明されている応答のいくつかは、クライアントがクエリへの応答とセッションの管理を支援することを目的としたRDAPサーバーからクライアントに情報を返します。セクション5.1.1で説明されている「userClaims」などのその情報の一部は、不正な当事者に開示された場合、個人的に識別可能であり、敏感であると見なすことができます。RDAPサーバーオペレーターは、情報開示のポリシーを作成して、個人を特定できる情報がその情報の処理を許可されたクライアントにのみ開示されるようにする必要があります。
The "do not track" claim relies on the good will of the RDAP server and associated proxies. As such, using and processing this claim depends on out-of-band trust relationships that need to be established before the claim is used in practice. If used and accepted by the RDAP server, there is a risk of information loss that could seriously impair audit capabilities.
「Do Not Track」クレームは、RDAPサーバーと関連プロキシの善意に依存しています。そのため、このクレームを使用および処理することは、請求が実際に使用される前に確立する必要があるバンド外の信頼関係に依存します。RDAPサーバーによって使用および受け入れられた場合、監査機能を深刻に損なう可能性のある情報損失のリスクがあります。
Having completed the client identification, authorization, and validation process, an RDAP server can make access control decisions based on a comparison of client-provided information (such as the set of "userClaims" described in Section 5.1.1) and local policy. For example, a client who provides an email address (and nothing more) might be entitled to receive a subset of the information that would be available to a client who provides an email address, a full name, and a stated purpose. Development of these access control policies is beyond the scope of this document.
クライアントの識別、承認、および検証プロセスを完了した後、RDAPサーバーは、クライアントが提供する情報（セクション5.1.1で説明されている「UserClaims」のセットなど）およびローカルポリシーの比較に基づいて、アクセス制御決定を行うことができます。たとえば、電子メールアドレスを提供するクライアントは、電子メールアドレス、フルネーム、および指定された目的を提供するクライアントが利用できる情報のサブセットを受信する権利がある場合があります。これらのアクセス制御ポリシーの開発は、このドキュメントの範囲を超えています。
[HTMLURL] WHATWG, "URL (Living Standard)", March 2024,
<https://url.spec.whatwg.org/>.
[OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OIDCD] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0 incorporating errata set 2",
December 2023, <https://openid.net/specs/openid-connect-
discovery-1_0.html>.
[OIDCL] Jones, M., de Medeiros, B., Agarwal, N., Sakimura, N., and
J. Bradley, "OpenID Connect RP-Initiated Logout 1.0",
September 2022, <https://openid.net/specs/openid-connect-
rpinitiated-1_0.html>.
[OIDCR] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0 incorporating errata set
2", December 2023, <https://openid.net/specs/openid-
connect-registration-1_0.html>.
[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>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[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>.
[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>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[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>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/info/rfc8628>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[gTLD] Expert Working Group on gTLD Directory Services (EWG),
"Final Report from the Expert Working Group on gTLD
Directory Services: A Next-Generation Registration
Directory Service (RDS)", June 2014,
<https://www.icann.org/en/system/files/files/final-report-
06jun14-en.pdf>.
[OAUTH-SECURITY]
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-26, 21 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
security-topics-26>.
[OIDC] OpenID, "What is OpenID Connect",
<https://openid.net/developers/how-connect-works/>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
The author would like to acknowledge the following individuals for their contributions to the development of this document: Julien Bernard, Marc Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith, Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the Verisign Registry Services Lab development team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof of concept" implementation experience that helped demonstrate the validity of the concepts described in this document.
著者は、この文書の開発への貢献について、次の個人に、ジュリアン・バーナード、マーク・ブランシェ、トム・ハリソン、ラス・ハウリー、ジャスディップ・シン、リース・スミス、ジャロミール・タリール、リック・ウィルヘルム、アレッサンドロ・ベスリーです。さらに、ジョセフ・ハーベイ、アンドリュー・カイザー、セイ・モガリ、アヌラグ・サクセナ、スワプニール・シェス、ニティン・シン、ザオ・ザオのベリジャインレジストリサービスラボ開発チームは、記載されている概念の妥当性を実証するのに役立つ重要な「概念証明」実装経験を提供しましたこのドキュメントで。
Pawel Kowalik and Mario Loffredo provided significant text contributions that led to welcome improvements in several sections of this document. Their contributions are greatly appreciated.
Pawel KowalikとMario Loffredoは、この文書のいくつかのセクションで改善を歓迎することにつながった重要なテキスト貢献を提供しました。彼らの貢献は大歓迎です。
Scott Hollenbeck
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/