idnits 2.17.1 draft-ietf-regext-rdap-openid-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 February 2022) is 792 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDC' -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCC' -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCL' -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCR' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REGEXT Working Group S. Hollenbeck 3 Internet-Draft Verisign Labs 4 Intended status: Standards Track 24 February 2022 5 Expires: 28 August 2022 7 Federated Authentication for the Registration Data Access Protocol 8 (RDAP) using OpenID Connect 9 draft-ietf-regext-rdap-openid-11 11 Abstract 13 The Registration Data Access Protocol (RDAP) provides "RESTful" web 14 services to retrieve registration metadata from domain name and 15 regional internet registries. RDAP allows a server to make access 16 control decisions based on client identity, and as such it includes 17 support for client identification features provided by the Hypertext 18 Transfer Protocol (HTTP). Identification methods that require 19 clients to obtain and manage credentials from every RDAP server 20 operator present management challenges for both clients and servers, 21 whereas a federated authentication system would make it easier to 22 operate and use RDAP without the need to maintain server-specific 23 client credentials. This document describes a federated 24 authentication system for RDAP based on OpenID Connect. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 28 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 63 3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4 64 3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5 65 3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.3. RDAP Authentication and Authorization Steps . . . . . 6 68 3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 7 69 3.1.3.2. Authentication Request . . . . . . . . . . . . . 7 70 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 8 71 3.1.3.4. Authorization Response and Validation . . . . . . 8 72 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 8 73 3.1.3.6. Delivery of User Information . . . . . . . . . . 8 74 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 9 75 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 9 76 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 77 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 78 4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12 81 4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13 82 4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 83 4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 84 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 16 85 4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 86 4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 87 4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 88 4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 89 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 90 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 91 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 94 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 95 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 97 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 98 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 26 99 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 26 100 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 27 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 10.1. Authentication and Access Control . . . . . . . . . . . 28 103 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 106 12.2. Informative References . . . . . . . . . . . . . . . . . 30 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 110 1. Introduction 112 The Registration Data Access Protocol (RDAP) provides "RESTful" web 113 services to retrieve registration metadata from domain name and 114 regional internet registries. RDAP allows a server to make access 115 control decisions based on client identity, and as such it includes 116 support for client identification features provided by the Hypertext 117 Transfer Protocol (HTTP) [RFC7230]. 119 RDAP is specified in multiple documents, including "HTTP Usage in the 120 Registration Data Access Protocol (RDAP)" [RFC7480], "Security 121 Services for the Registration Data Access Protocol (RDAP)" [RFC7481], 122 "Registration Data Access Protocol Query Format" [RFC9082], and "JSON 123 Responses for the Registration Data Access Protocol (RDAP)" 124 [RFC9083]. RFC 7481 describes client identification and 125 authentication services that can be used with RDAP, but it does not 126 specify how any of these services can (or should) be used with RDAP. 128 1.1. Problem Statement 130 The traditional "user name and password" authentication method does 131 not scale well in the RDAP ecosystem. Assuming that all domain name 132 and address registries will eventually provide RDAP service, it is 133 impractical and inefficient for users to secure login credentials 134 from the hundreds of different server operators. Authentication 135 methods based on user names and passwords do not provide information 136 that describes the user in sufficient detail (while protecting the 137 personal privacy of the user) for server operators to make fine- 138 grained access control decisions based on the user's identity. The 139 authentication system used for RDAP needs to address all of these 140 needs. 142 1.2. Proposal 144 A basic level of RDAP service can be provided to users who possess an 145 identifier issued by a recognized provider who is able to 146 authenticate and validate the user. The identifiers issued by social 147 media services, for example, can be used. Users who require higher 148 levels of service (and who are willing to share more information 149 about them self to gain access to that service) can secure 150 identifiers from specialized providers who are or will be able to 151 provide more detailed information about the user. Server operators 152 can then make access control decisions based on the identification 153 information provided by the user. 155 A federated authentication system in which an RDAP server outsources 156 identification and authentication services to a trusted OpenID 157 Provider would make it easier to operate and use RDAP by re-using 158 existing identifiers to provide a basic level of access. It can also 159 provide the ability to collect additional user identification 160 information, and that information can be shared with the consent of 161 the user. This type of system allows an RDAP server to make access 162 control decisions based on the nature of a query and the identity, 163 authentication, and authorization information that is received from 164 the OpenID Provider. This document describes a federated 165 authentication system for RDAP based on OpenID Connect [OIDC] that 166 meets all of these needs. 168 2. Conventions Used in This Document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 3. Federated Authentication for RDAP 178 RDAP itself does not include native security services. Instead, RDAP 179 relies on features that are available in other protocol layers to 180 provide needed security services including access control, 181 authentication, authorization, availability, data confidentiality, 182 data integrity, and identification. A description of each of these 183 security services can be found in "Internet Security Glossary, 184 Version 2" [RFC4949]. This document focuses on a federated 185 authentication system for RDAP that provides services for 186 authentication, authorization, and identification, allowing a server 187 operator to make access control decisions. Section 3 of RFC 7481 188 [RFC7481] describes general considerations for RDAP access control, 189 authentication, and authorization. 191 The traditional client-server authentication model requires clients 192 to maintain distinct credentials for every RDAP server. This 193 situation can become unwieldy as the number of RDAP servers 194 increases. Federated authentication mechanisms allow clients to use 195 one credential to access multiple RDAP servers and reduce client 196 credential management complexity. 198 3.1. RDAP and OpenID Connect 200 OpenID Connect 1.0 [OIDCC] is a decentralized, single sign-on (SSO) 201 federated authentication system that allows users to access multiple 202 web resources with one identifier instead of having to create 203 multiple server-specific identifiers. Users acquire identifiers from 204 OpenID Providers, or OPs. Relying Parties, or RPs, are applications 205 (such as RDAP) that outsource their user authentication function to 206 an OP. OpenID Connect is built on top of the authorization framework 207 provided by the OAuth 2.0 [RFC6749] protocol. 209 The OAuth authorization framework describes a method for users to 210 access protected web resources without having to hand out their 211 credentials. Instead, clients are issued Access Tokens by 212 authorization servers with the permission of the resource owners. 213 Using OpenID Connect and OAuth, multiple RDAP servers can form a 214 federation and clients can access any server in the federation by 215 providing one credential registered with any OP in that federation. 216 The OAuth authorization framework is designed for use with HTTP and 217 thus can be used with RDAP. 219 3.1.1. Terminology 221 This document uses the terms "client" and "server" defined by RDAP 222 [RFC7480]. An RDAP client performs the role of an OpenID Connect 223 Core [OIDCC] Entity or End-User. An RDAP server performs the role of 224 an OpenID Connect Core Relying Party (RP). Additional terms from 225 Section 1.2 of the OpenID Connect Core specification are incorporated 226 by reference. 228 3.1.2. Overview 230 At a high level, RDAP authentication of a browser-like client using 231 OpenID Connect requires completion of the following steps: 233 1. An RDAP client sends an RDAP "help" query to an RDAP server to 234 determine the type of OpenID Authorization Server that's used by 235 the RDAP server. This information is returned in the 236 rdapConformance section of the response. A value of 237 "rdap_openidc_local_level_0" indicates that the server uses a 238 local Authorization Server. A value of 239 "rdap_openidc_remote_level_0" indicates that the server uses a 240 remote Authorization Server. 241 2. An RDAP client (acting as an OpenID End-User) sends an RDAP 242 "login" request to an RDAP server as described in Section 4.2. 243 3. The RDAP server (acting as an OpenID Relying Party (RP)) 244 prepares an Authentication Request containing the desired 245 request parameters. 246 4. The RDAP server sends the RDAP client and Authentication Request 247 to an Authorization Server operated by an OpenID Provider (OP) 248 using an HTTP redirect. 249 5. The Authorization Server authenticates the End-User. 250 6. The Authorization Server obtains End-User consent/authorization. 251 7. The Authorization Server sends the RDAP Client back to the RDAP 252 server with an Authorization Code using an HTTP redirect. 253 8. The RDAP server requests a response using the Authorization Code 254 at the Token Endpoint. 255 9. The RDAP server receives a response that contains an ID Token 256 and Access Token in the response body. 257 10. The RDAP server validates the ID Token and retrieves the claims 258 associated with the End-User's identity. 260 The RDAP server can then make identification, authorization, and 261 access control decisions based on End-User identity information and 262 local policies. Note that OpenID Connect describes different process 263 flows for other types of clients, such as script-based or command 264 line clients. 266 3.1.3. RDAP Authentication and Authorization Steps 268 End-Users MUST possess an identifier (an OpenID) issued by an OP to 269 use OpenID Connect with RDAP. An OP SHOULD include support for the 270 claims described in Section 3.1.4 to provide additional information 271 needed for RDAP End-User authorization. OpenID Connect requires RPs 272 to register with OPs to use OpenID Connect services for an End-User. 273 The registration process is often completed using out-of-band 274 methods, but it is also possible to use the automated method 275 described by the "OpenID Connect Dynamic Client Registration" 276 protocol [OIDCR]. The parties involved can use any method that is 277 mutually acceptable. 279 3.1.3.1. Provider Discovery 281 An RDAP server/RP needs to be able to map an End-User's identifier to 282 an OP. This can be accomplished using the OPTIONAL "OpenID Connect 283 Discovery" protocol [OIDCD], but that protocol is not widely 284 implemented. Out-of-band methods are also possible and can be more 285 dependable. For example, an RP can support a limited number of OPs 286 and maintain internal associations of those identifiers with the OPs 287 that issued them. An RP can also ask an End-User to identify the OP 288 that issued their identifier as part of an RDAP query workflow. In 289 this case, the RP will need to maintain state for the association 290 between the user's identifier and the OP in order to process later 291 queries that rely on passing the access token and user identifier as 292 authorization parameters. An RP MAY use any provider discovery 293 approach that is suitable for its operating environment. 295 3.1.3.2. Authentication Request 297 Once the OP is known, an RP MUST form an Authentication Request and 298 send it to the OP as described in Section 3 of the OpenID Connect 299 Core protocol [OIDCC]. The authentication path followed 300 (authorization, implicit, or hybrid) will depend on the 301 Authentication Request response_type set by the RP. The remainder of 302 the processing steps described here assume that the Authorization 303 Code Flow is being used by setting "response_type=code" in the 304 Authentication Request. 306 The benefits of using the Authorization Code Flow for authenticating 307 a human user are described in Section 3.1 of the OpenID Connect Core 308 protocol. The Implicit Flow is more commonly used by clients 309 implemented in a web browser using a scripting language; it is 310 described in Section 3.2 of the OpenID Connect Core protocol. The 311 Hybrid Flow (described in Section 3.3 of the OpenID Connect Core 312 protocol) combines elements of the Authorization and Implicit Flows 313 by returning some tokens from the Authorization Endpoint and others 314 from the Token Endpoint. 316 An Authentication Request can contain several parameters. REQUIRED 317 parameters are specified in Section 3.1.2.1 of the OpenID Connect 318 Core protocol [OIDCC]. Apart from these parameters, it is 319 RECOMMENDED that the RP include the optional "login_hint" parameter 320 in the request, with the value being that of the "id" query parameter 321 of the End-User's RDAP "login" request. Passing the "login_hint" 322 parameter allows a client to pre-fill login form information, so 323 logging in can be more convenient for users. Other parameters MAY be 324 included. 326 The OP receives the Authentication Request and attempts to validate 327 it as described in Section 3.1.2.2 of the OpenID Connect Core 328 protocol [OIDCC]. If the request is valid, the OP attempts to 329 authenticate the End-User as described in Section 3.1.2.3 of the 330 OpenID Connect Core protocol [OIDCC]. The OP returns an error 331 response if the request is not valid or if any error is encountered. 333 3.1.3.3. End-User Authorization 335 After the End-User is authenticated, the OP MUST obtain authorization 336 information from the End-User before releasing information to the 337 RDAP Server/RP. This process is described in Section 3.1.2.4 of the 338 OpenID Connect Core protocol [OIDCC]. 340 3.1.3.4. Authorization Response and Validation 342 After the End-User is authenticated, the OP will send a response to 343 the RP that describes the result of the authorization process in the 344 form of an Authorization Grant. The RP MUST validate the response. 345 This process is described in Sections 3.1.2.5 - 3.1.2.7 of the OpenID 346 Connect Core protocol [OIDCC]. 348 3.1.3.5. Token Processing 350 The RP sends a Token Request using the Authorization Grant to a Token 351 Endpoint to obtain a Token Response containing an Access Token, ID 352 Token, and an OPTIONAL Refresh Token. The RP MUST validate the Token 353 Response. This process is described in Section 3.1.3 of the OpenID 354 Connect Core protocol [OIDCC]. 356 3.1.3.6. Delivery of User Information 358 The set of claims can be retrieved by sending a request to a UserInfo 359 Endpoint using the Access Token. The claims MAY be returned in the 360 ID Token. The process of retrieving claims from a UserInfo Endpoint 361 is described in Section 5.3 of the OpenID Connect Core protocol 362 [OIDCC]. 364 OpenID Connect specifies a set of standard claims in Section 5.1. 365 Additional claims for RDAP are described in Section 3.1.4. 367 3.1.4. Specialized Claims for RDAP 369 OpenID Connect claims are pieces of information used to make 370 assertions about an entity. Section 5 of the OpenID Connect Core 371 protocol [OIDCC] describes a set of standard claims that can be used 372 to identify a person. Section 5.1.2 notes that additional claims MAY 373 be used, and it describes a method to create them. The set of claims 374 that are specific to RDAP are associated with an OAuth scope request 375 parameter value (see Section 3.3 of RFC 6749 ([RFC6749])) of "rdap". 377 3.1.4.1. Stated Purpose 379 There are communities of RDAP users and operators who wish to make 380 and validate claims about a user's "need to know" when it comes to 381 requesting access to a resource. For example, a law enforcement 382 agent or a trademark attorney may wish to be able to assert that they 383 have a legal right to access a protected resource, and a server 384 operator will need to be able to receive and validate that claim. 385 These needs can be met by defining and using an additional "purpose" 386 claim. 388 The "purpose" claim identifies the purpose for which access to a 389 protected resource is being requested. Use of the "purpose" claim is 390 OPTIONAL; processing of this claim is subject to server acceptance of 391 the purpose and successful authentication of the End-User. 392 Unrecognized purpose values MUST be ignored and the associated query 393 MUST be processed as if the unrecognized purpose value was not 394 present at all. 396 The "purpose" value is a case-sensitive string containing a 397 StringOrURI value as specified in Section 2 of the JSON Web Token 398 (JWT) specification ([RFC7519]). An example: 400 {"purpose" : "domainNameControl"} 402 Purpose values are themselves registered with IANA. Each entry in 403 the registry contains the following fields: 405 Value: the purpose string value being registered. Value strings can 406 contain upper case characters from "A" to "Z", lower case ASCII 407 characters from "a" to "z", and the underscore ("_") character. 408 Value strings contain at least one character and no more than 64 409 characters. 411 Description: a one- or two-sentence description of the meaning of the 412 purpose value, how it might be used, and/or how it should be 413 interpreted by clients and servers. 415 This registry is operated under the "Specification Required" policy 416 defined in RFC 5226 ([RFC5226]). The set of initial values used to 417 populate the registry as described in Section 8.3 are taken from the 418 final report (https://www.icann.org/en/system/files/files/final- 419 report-06jun14-en.pdf) produced by the Expert Working Group on gTLD 420 Directory Services chartered by the Internet Corporation for Assigned 421 Names and Numbers (ICANN). 423 3.1.4.2. Do Not Track 425 There are also communities of RDAP users and operators who wish to 426 make and validate claims about a user's wish to not have their 427 queries logged, tracked, or recorded. For example, a law enforcement 428 agent may wish to be able to assert that their queries are part of a 429 criminal investigation and should not be tracked due to a risk of 430 query exposure compromising the investigation, and a server operator 431 will need to be able to receive and validate that claim. These needs 432 can be met by defining and using an additional "do not track" claim. 434 The "do not track" ("dnt") claim can be used to identify an End-User 435 that is authorized to perform queries without the End-User's 436 association with those queries being logged, tracked, or recorded by 437 the server. Client use of the "dnt" claim is OPTIONAL. Server 438 operators MUST NOT log, track, or record any association of the query 439 and the End-User's identity if the End-User is successfully 440 identified and authorized, the "dnt" claim is present, the value of 441 the claim is "true", and accepting the claim complies with local 442 regulations regarding logging and tracking. 444 The "dnt" value is represented as a JSON boolean literal. An 445 example: 447 {"dnt" : true} 449 No special query tracking processing is required if this claim is not 450 present or if the value of the claim is "false". Use of this claim 451 MUST be limited to End-Users who are granted "do not track" 452 privileges in accordance with service policies and regulations. 453 Specification of these policies and regulations is beyond the scope 454 of this document. 456 4. Protocol Parameters 458 This specification adds the following protocol parameters to RDAP: 460 1. Data structures to return information that describes an 461 established session and the information needed to establish a 462 session for a UI-constrained device. 464 2. A query parameter to request authentication for a specific End- 465 User identity. 466 3. Path segments to start, stop, refresh, and determine the status 467 of an authenticated session for a specific End-User identity. 469 4.1. Data Structures 471 This specification describes two new data structures that are used to 472 return information to a client: a "session" data structure that 473 contains information that describes an established session, and a 474 "deviceInfo" data structure that contains information that describes 475 an active attempt to establish a session on a UI-constrained device. 477 4.1.1. Session 479 The "session" data structure is an array that contains two sub- 480 arrays: 482 1. A "userClaims" array that contains the set of claims associated 483 with the End-User's identity, with each claim represented as a 484 name-value pair in string format. The set of possible values is 485 determined by OP policy. 486 2. A "sessionInfo" array that contains two name-value pairs: 487 a. "tokenExpiration": an integer value that represents the 488 number of seconds from the current time for which the Access 489 Token remains valid, and 490 b. "tokenRefresh": A boolean value that indicates if the OP 491 supports refresh tokens. As described in RFC 6749 [RFC6749], 492 support for refresh tokens is OPTIONAL. 494 An example of a "session" data structure: 496 "session": { 497 "userClaims": { 498 "sub": "103892603076825016132", 499 "name": "User Person", 500 "given_name": "User", 501 "family_name": "Person", 502 "picture": "https://lh3.example.com/a-/AOh14=s96-c", 503 "email": "user@example.com", 504 "email_verified": true, 505 "locale": "en", 506 "purpose": "domainNameControl", 507 "dnt": false 508 }, 509 "sessionInfo": { 510 "tokenExpiration": 3599, 511 "tokenRefresh": true 512 } 513 } 515 Figure 1 517 4.1.2. Device Info 519 The flow described in Section 3.1.3 requires an End-User to interact 520 with a server using a user interface that can process HTTP. This 521 will not work well in situations where the client is automated or an 522 End-User is using a command line user interface such as curl 523 (http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/). 524 This limitation can be addressed using a web browser on a second 525 device. The information that needs to be entered using the web 526 browser is contained in the "deviceInfo" data structure. 528 The "deviceInfo" data structure is an array that contains three name- 529 value pairs: 531 1. "verification_url": the URL that the End-User needs to visit 532 using the web browser, 533 2. "user_code": the string value that the End-User needs to enter on 534 the form presented in the web browser, and 535 3. "expires_in": an integer value that represents the number of 536 seconds after which the opportunity to visit the URL and enter 537 the user_code will expire. 539 An example of a "deviceInfo" data structure: 541 "deviceInfo": { 542 "verification_url": "https://www.example.com/device", 543 "user_code": "NJJQ-GJFC", 544 "expires_in": "1800" 545 } 547 Figure 2 549 4.2. Client Login 551 Client authentication is requested by sending a "session/login" 552 request to an RDAP server. If the RDAP server supports only remote 553 Authorization Servers, the "session/login" request MUST include an 554 End-User identifier that's delivered using one of two methods: by 555 adding a query component to an RDAP request URI using the syntax 556 described in Section 3.4 of RFC 3986 [RFC3986], or by including an 557 HTTP authorization header for the Basic authentication scheme as 558 described in RFC 7617 [RFC7617]. Clients can use either of these 559 methods to deliver the End-User identifier to a server that supports 560 remote Authorization Servers. Servers that support remote 561 Authorization Servers MUST accept both methods. If the RDAP server 562 supports a local Authorization Server, the End-User identifier MAY be 563 omitted. 565 The query used to request client authentication is represented as an 566 OPTIONAL "key=value" pair using a key value of "id" and a value 567 component that contains the client identifier issued by an OP. An 568 example for client identifier "user.idp.example": 570 https://example.com/rdap/session/login?id=user.idp.example 572 The authorization header for the Basic authentication scheme contains 573 a Base64-encoded representation of the client identifier issued by an 574 OP. No password is provided. An example for client identifier 575 "user.idp.example": 577 https://example.com/rdap/session/login 579 Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ== 581 An example for use with a local Authorization Server: 583 https://example.com/rdap/session/login 584 The response to this request MUST use the response structures 585 specified in RFC 9083 [RFC9083]. In addition, the response MUST 586 include an indication of the requested operation's success or failure 587 in the "notices" data structure (including the client identifier), 588 and, if successful, a "session" data structure. 590 An example of a successful "session/login" response: 592 { 593 "rdapConformance": [ 594 "rdap_openidc_remote_level_0" 595 ], 596 "lang": "en-US", 597 "notices": { 598 "title": "Login Result", 599 "description": [ 600 "Login succeeded", 601 "user.idp.example" 602 ], 603 }, 604 "session": { 605 "userClaims": { 606 "sub": "103892603076825016132", 607 "name": "User Person", 608 "given_name": "User", 609 "family_name": "Person", 610 "picture": "https://lh3.example.com/a-/AOh14=s96-c", 611 "email": "user@example.com", 612 "email_verified": true, 613 "locale": "en", 614 "purpose": "domainNameControl", 615 "dnt": false 616 }, 617 "sessionInfo": { 618 "tokenExpiration": 3599, 619 "tokenRefresh": true 620 } 621 } 622 } 624 Figure 3 626 An example of a failed "session/login" response: 628 { 629 "rdapConformance": [ 630 "rdap_openidc_remote_level_0" 631 ], 632 "lang": "en-US", 633 "notices": { 634 "title": "Login Result", 635 "description": [ 636 "Login failed", 637 "user.idp.example" 638 ] 639 } 640 } 642 Figure 4 644 4.2.1. Clients with Limited User Interfaces 646 The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an 647 OPTIONAL method to request user authorization from devices that have 648 an Internet connection, but lack a suitable browser for a more 649 traditional OAuth flow. This method requires an End-User to use a 650 second device (such as a smart telephone) that has access to a web 651 browser for entry of a code sequence that is presented on the UI- 652 constrained device. 654 4.2.1.1. UI-constrained Client Login 656 Client authentication is requested by sending a "session/device" 657 request to an RDAP server. If the RDAP server supports only remote 658 Authorization Servers, the "session/device" request MUST include an 659 End-User identifier that's delivered using one of two methods: by 660 adding a query component to an RDAP request URI using the syntax 661 described in Section 3.4 of RFC 3986 [RFC3986], or by including an 662 HTTP authorization header for the Basic authentication scheme as 663 described in RFC 7617 [RFC7617]. If the RDAP server supports a local 664 Authorization Server, the End-User identifier MAY be omitted. 665 Clients can use either of these methods. Servers MUST support both 666 methods. 668 The query used to request client authentication is represented as an 669 OPTIONAL "key=value" pair using a key value of "id" and a value 670 component that contains the client identifier issued by an OP. An 671 example using wget for client identifier "user.idp.example": 673 wget -qO- --keep-session-cookies --save- 674 cookies\https://example.com/rdap/session/device?id=user.idp.example 675 The authorization header for the Basic authentication scheme contains 676 a Base64-encoded representation of the client identifier issued by an 677 OP. No password is provided. An example using curl and an 678 authorization header: 680 curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\-c 681 cookies.txt https://example.com/rdap/session/device 683 The response to this request MUST use the response structures 684 specified in RFC 9083 [RFC9083]. In addition, the response MUST 685 include an indication of the requested operation's success or failure 686 in the "notices" data structure (including the client identifier), 687 and, if successful, a "deviceInfo" data structure. 689 An example of a "session/device" response: 691 { 692 "rdapConformance": [ 693 "rdap_openidc_remote_level_0" 694 ], 695 "lang": "en-US", 696 "notices": { 697 "title": "Device Login Result", 698 "description": [ 699 "Login succeeded", 700 "user.idp.example" 701 ] 702 }, 703 "deviceInfo": { 704 "verification_url": "https://www.example.com/device", 705 "user_code": "NJJQ-GJFC", 706 "expires_in": "1800" 707 } 708 } 710 Figure 5 712 4.2.1.2. UI-constrained Client Login Polling 714 After successful processing of the "session/device" request, the 715 client MUST send a "session/devicepoll" request to the RDAP server to 716 continue the login process. This request performs the polling 717 function described in RFC 8628 [RFC8628], allowing the RDAP server to 718 wait for the End-User to enter the information returned from the 719 "session/device" request using the interface on their second device. 720 After the End-User has completed that process, or if the process 721 fails or times out, the OP will respond to the polling requests with 722 an indication of success or failure. An example using wget: 724 wget -qO- --load-cookies 725 cookies.txt\https://example.com/rdap/session/devicepoll 727 An example using curl: 729 curl -b cookies.txt https://example.com/rdap/session/devicepoll 731 The response to this request MUST use the response structures 732 described in Section 4.2. RDAP query processing can continue 733 normally on the UI-constrained device once the "login" process has 734 been completed. 736 4.3. Session Status 738 Clients MAY send a query to an RDAP server to determine the status of 739 an existing login session using a "session/status" path segment. An 740 example "session/status" request: 742 https://example.com/rdap/session/status 744 The response to this query MUST use the response structures specified 745 in RFC 9083 [RFC9083]. In addition, the response MUST include an 746 indication of the requested operation's success or failure in the 747 "notices" data structure (including the client identifier), and, if 748 successful, a "session" data structure. 750 An example of a "session/status" response: 752 { 753 "rdapConformance": [ 754 "rdap_openidc_remote_level_0" 755 ], 756 "lang": "en-US", 757 "notices": { 758 "title": "Session Status Result", 759 "description": [ 760 "Session status succeeded", 761 "user.idp.example" 762 ] 763 }, 764 "session": { 765 "userClaims": { 766 "sub": "103892603076825016132", 767 "name": "User Person", 768 "given_name": "User", 769 "family_name": "Person", 770 "picture": "https://lh3.example.com/a-/AOh14=s96-c", 771 "email": "user@example.com", 772 "email_verified": true, 773 "locale": "en", 774 "purpose": "domainNameControl", 775 "dnt": false 776 }, 777 "sessionInfo": { 778 "tokenExpiration": 3490, 779 "tokenRefresh": true 780 } 781 } 782 } 784 Figure 6 786 4.4. Session Refresh 788 Clients MAY send a request to an RDAP server to refresh, or extend, 789 an existing login session using a "session/refresh" path segment. 790 The RDAP server MAY attempt to refresh the access token associated 791 with the current session as part of extending the session for a 792 period of time determined by the RDAP server. As described in RFC 793 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP 794 server MUST determine if the OP supports token refresh and process 795 the refresh request by either requesting refresh of the access token 796 or by returning a response that indicates that token refresh is not 797 supported by the OP in the "notices" data structure. An example 798 "session/refresh" request: 800 https://example.com/rdap/session/refresh 802 The response to this request MUST use the response structures 803 specified in RFC 9083 [RFC9083]. In addition, the response MUST 804 include an indication of the requested operation's success or failure 805 in the "notices" data structure (including the client identifier), 806 and, if successful, a "session" data structure. 808 An example of a "session/refresh" response: 810 { 811 "rdapConformance": [ 812 "rdap_openidc_remote_level_0" 813 ], 814 "lang": "en-US", 815 "notices": { 816 "title": "Session Refresh Result", 817 "description": [ 818 "Session refresh succeeded", 819 "user.idp.example", 820 "Token refresh succeeded." 821 ] 822 }, 823 "session": { 824 "userClaims": { 825 "sub": "103892603076825016132", 826 "name": "User Person", 827 "given_name": "User", 828 "family_name": "Person", 829 "picture": "https://lh3.example.com/a-/AOh14=s96-c", 830 "email": "user@example.com", 831 "email_verified": true, 832 "locale": "en", 833 "purpose": "domainNameControl", 834 "dnt": false 835 }, 836 "sessionInfo": { 837 "tokenExpiration": 3599, 838 "tokenRefresh": true 839 } 840 } 841 } 843 Figure 7 845 4.5. Client Logout 847 Clients MAY send a request to an RDAP server to terminate an existing 848 login session. Termination of a session is requested using a 849 "session/logout" path segment. Access and refresh tokens can be 850 revoked during the "session/logout" process as described in RFC 7009 851 [RFC7009] if supported by the OP (token revocation endpoint support 852 is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature 853 SHOULD be used to ensure that the tokens are not mistakenly 854 associated with a future RDAP session. Alternatively, an RDAP server 855 MAY attempt to logout from the OP using the "OpenID Connect RP- 856 Initiated Logout" protocol ([OIDCL]) if that protocol is supported by 857 the OP. 859 An example "session/logout" request: 861 https://example.com/rdap/session/logout 863 The response to this request MUST use the response structures 864 specified in RFC 9083 [RFC9083]. In addition, the response MUST 865 include an indication of the requested operation's success or failure 866 in the "notices" data structure (including the client identifier). 867 The "notices" data structure MUST also include an indication of the 868 success or failure of any attempt to logout from the OP or to revoke 869 the tokens issued by the OP. 871 An example of a "session/logout" response: 873 { 874 "rdapConformance": [ 875 "rdap_openidc_remote_level_0" 876 ], 877 "lang": "en-US", 878 "notices": { 879 "title": "Logout Result", 880 "description": [ 881 "Logout succeeded", 882 "user.idp.example", 883 "Provider logout failed: Not supported by provider.", 884 "Token revocation successful." 885 ] 886 } 887 } 889 Figure 8 891 In the absence of a "logout" request, an RDAP session MUST be 892 terminated by the RDAP server after a server-defined period of time. 893 The server should also take appropriate steps to ensure that the 894 tokens associated with the terminated session cannot be reused. This 895 SHOULD include revoking the tokens or logging out from the OP if 896 either operation is supported by the OP. 898 4.6. Parameter Processing 900 Unrecognized query parameters MUST be ignored. An RDAP server that 901 processes an authenticated query MUST determine if the End-User 902 identification information is associated with an OP that is 903 recognized and supported by the server. Servers MUST reject queries 904 that include identification information that is not associated with a 905 supported OP by returning an HTTP 501 (Not Implemented) response. An 906 RDAP server that receives a query containing identification 907 information associated with a recognized OP MUST perform the steps 908 required to authenticate the user with the OP, process the query, and 909 return an RDAP response that is appropriate for the End-User's level 910 of authorization and access. 912 5. Token Exchange 914 ID tokens include an audience parameter that contains the OAuth 2.0 915 client_id of the RP as an audience value. In some operational 916 scenarios (such as a client that is providing a proxy service), an RP 917 can receive tokens with an audience value that does not include the 918 RP's client_id. These tokens might not be trusted by the RP, and the 919 RP might refuse to accept the tokens. This situation can be remedied 920 by having the RP exchange these tokens with the OP for a set of 921 trusted tokens that reset the audience parameter. This token 922 exchange protocol is described in RFC 8693 [RFC8693]. This issue is 923 not visible to the RDAP client and should be managed by the OpenID 924 implementation used by the RDAP server. 926 6. RDAP Query Processing 928 Once an RDAP session is active, an RDAP server MUST determine if the 929 End-User is authorized to perform any queries that are received 930 during the duration of the session. This MAY include rejecting 931 queries outright, and it MAY include omitting or otherwise redacting 932 information that the End-User is not authorized to receive. Specific 933 processing requirements are beyond the scope of this document. A 934 client can end a session explicitly by sending a "session/logout" 935 request to the RDAP server. A session can also be ended implicitly 936 by the server after a server-defined period of time. The status of a 937 session can be determined at any time by sending a "session/status" 938 query to the RDAP server. 940 An RDAP server MUST maintain session state information for the 941 duration of an active session. This is commonly done using HTTP 942 cookies as described in RFC 6265 [RFC6265]. Doing so allows End-User 943 to submit queries without having to explicitly identify and 944 authenticate themselves for each and every query. 946 7. RDAP Conformance 948 RDAP responses that contain values described in this document MUST 949 indicate conformance with this specification by including an 950 rdapConformance ([RFC9083]) value of "rdap_openidc_remote_level_0" 951 (to indicate support for one or more remote Authorization Servers), 952 "rdap_openidc_local_level_0" (to indicate support for a local 953 Authorization Server), or both values if the server supports both 954 remote and local OpenID Authorization Servers. The information 955 needed to register these values in the RDAP Extensions Registry is 956 described in Section 8.1. 958 Example rdapConformance structure with extension specified: 960 "rdapConformance" : 961 [ 962 "rdap_level_0", 963 "rdap_openidc_remote_level_0" 964 ] 966 Figure 9 968 8. IANA Considerations 970 8.1. RDAP Extensions Registry 972 IANA is requested to register the following values in the RDAP 973 Extensions Registry: 975 * Extension identifier: rdap_openidc_remote_level_0 976 * Registry operator: Any 977 * Published specification: This document. 978 * Contact: IESG 979 * Intended usage: This extension describes a federated 980 authentication method for RDAP using OAuth 2.0, OpenID Connect, 981 and a remote Authorization Server. 983 * Extension identifier: rdap_openidc_local_level_0 984 * Registry operator: Any 985 * Published specification: This document. 986 * Contact: IESG 987 * Intended usage: This extension describes a federated 988 authentication method for RDAP using OAuth 2.0, OpenID Connect, 989 and a local Authorization Server. 991 8.2. JSON Web Token Claims Registry 993 IANA is requested to register the following values in the JSON Web 994 Token Claims Registry: 996 * Claim Name: "purpose" 997 * Claim Description: This claim describes the stated purpose for 998 submitting a request to access a protected RDAP resource. 999 * Change Controller: IESG 1000 * Specification Document(s): Section 3.1.4.1 of this document. 1002 * Claim Name: "dnt" 1003 * Claim Description: This claim contains a JSON boolean literal that 1004 describes an End-User's "do not track" preference for identity 1005 tracking, logging, or recording when accessing a protected RDAP 1006 resource. 1007 * Change Controller: IESG 1008 * Specification Document(s): Section 3.1.4.2 of this document. 1010 8.3. RDAP Query Purpose Registry 1012 IANA is requested to create a new protocol registry to manage RDAP 1013 query purpose values. This registry should appear under its own 1014 heading on IANA's protocol listings, using the same title as the name 1015 of the registry. The information to be registered and the procedures 1016 to be followed in populating the registry are described in 1017 Section 3.1.4.1. 1019 Name of registry: Registration Data Access Protocol (RDAP) Query 1020 Purpose Values 1022 Section at http://www.iana.org/protocols: 1024 Registry Title: Registration Data Access Protocol (RDAP) Query 1025 Purpose Values 1027 Registry Name: Registration Data Access Protocol (RDAP) Query Purpose 1028 Values 1030 Registration Procedure: Specification Required 1032 Reference: This draft 1034 Required information: See Section 3.1.4.1. 1036 Review process: "Specification Required" as described in RFC 5226 1037 [RFC5226]. 1039 Size, format, and syntax of registry entries: See Section 3.1.4.1. 1041 Initial assignments and reservations: 1043 -----BEGIN FORM----- Value: domainNameControl Description: Tasks 1044 within the scope of this purpose include creating and managing and 1045 monitoring a registrant's own domain name, including creating the 1046 domain name, updating information about the domain name, transferring 1047 the domain name, renewing the domain name, deleting the domain name, 1048 maintaining a domain name portfolio, and detecting fraudulent use of 1049 the Registrant's own contact information. -----END FORM----- 1051 -----BEGIN FORM----- Value: personalDataProtection Description: Tasks 1052 within the scope of this purpose include identifying the accredited 1053 privacy/proxy provider associated with a domain name and reporting 1054 abuse, requesting reveal, or otherwise contacting the provider. 1055 -----END FORM----- 1057 -----BEGIN FORM----- Value: technicalIssueResolution Description: 1058 Tasks within the scope of this purpose include (but are not limited 1059 to) working to resolve technical issues, including email delivery 1060 issues, DNS resolution failures, and web site functional issues. 1061 -----END FORM----- 1063 -----BEGIN FORM----- Value: domainNameCertification Description: 1064 Tasks within the scope of this purpose include a Certification 1065 Authority (CA) issuing an X.509 certificate to a subject identified 1066 by a domain name. -----END FORM----- 1068 -----BEGIN FORM----- Value: individualInternetUse Description: Tasks 1069 within the scope of this purpose include identifying the organization 1070 using a domain name to instill consumer trust, or contacting that 1071 organization to raise a customer complaint to them or file a 1072 complaint about them. -----END FORM----- 1074 -----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale 1075 Description: Tasks within the scope of this purpose include making 1076 purchase queries about a domain name, acquiring a domain name from a 1077 registrant, and enabling due diligence research. -----END FORM----- 1078 -----BEGIN FORM----- Value: academicPublicInterestDNSRResearch 1079 Description: Tasks within the scope of this purpose include academic 1080 public interest research studies about domain names published in the 1081 registration data service, including public information about the 1082 registrant and designated contacts, the domain name's history and 1083 status, and domain names registered by a given registrant (reverse 1084 query). -----END FORM----- 1086 -----BEGIN FORM----- Value: legalActions Description: Tasks within 1087 the scope of this purpose include investigating possible fraudulent 1088 use of a registrant's name or address by other domain names, 1089 investigating possible trademark infringement, contacting a 1090 registrant/licensee's legal representative prior to taking legal 1091 action and then taking a legal action if the concern is not 1092 satisfactorily addressed. -----END FORM----- 1094 -----BEGIN FORM----- Value: regulatoryAndContractEnforcement 1095 Description: Tasks within the scope of this purpose include tax 1096 authority investigation of businesses with online presence, Uniform 1097 Dispute Resolution Policy (UDRP) investigation, contractual 1098 compliance investigation, and registration data escrow audits. 1099 -----END FORM----- 1101 -----BEGIN FORM----- Value: 1102 criminalInvestigationAndDNSAbuseMitigation Description: Tasks within 1103 the scope of this purpose include reporting abuse to someone who can 1104 investigate and address that abuse, or contacting entities associated 1105 with a domain name during an offline criminal investigation. 1106 -----END FORM----- 1108 -----BEGIN FORM----- Value: dnsTransparency Description: Tasks within 1109 the scope of this purpose involve querying the registration data made 1110 public by registrants to satisfy a wide variety of use cases around 1111 informing the general public. -----END FORM----- 1113 9. Implementation Status 1115 NOTE: Please remove this section and the reference to RFC 7942 prior 1116 to publication as an RFC. 1118 This section records the status of known implementations of the 1119 protocol defined by this specification at the time of posting of this 1120 Internet-Draft, and is based on a proposal described in RFC 7942 1121 [RFC7942]. The description of implementations in this section is 1122 intended to assist the IETF in its decision processes in progressing 1123 drafts to RFCs. Please note that the listing of any individual 1124 implementation here does not imply endorsement by the IETF. 1125 Furthermore, no effort has been spent to verify the information 1126 presented here that was supplied by IETF contributors. This is not 1127 intended as, and must not be construed to be, a catalog of available 1128 implementations or their features. Readers are advised to note that 1129 other implementations may exist. 1131 According to RFC 7942, "this will allow reviewers and working groups 1132 to assign due consideration to documents that have the benefit of 1133 running code, which may serve as evidence of valuable experimentation 1134 and feedback that have made the implemented protocols more mature. 1135 It is up to the individual working groups to use this information as 1136 they see fit". 1138 Version -09 of this specification introduced changes that are 1139 incompatible with earlier implementations. Implementations that are 1140 consistent with this specification will be added as they are 1141 identified. 1143 9.1. Editor Implementation 1145 * Location: https://procuratus.net/rdap/ 1146 * Description: This implementation is a functionally-limited RDAP 1147 server that supports only the path segments described in this 1148 specification. It uses the "jumbojett/OpenID-Connect-PHP" library 1149 found on GitHub, which appears to no longer be under active 1150 development. The library was modified to add support for the 1151 device authorization grant. Session variable management is still 1152 a little buggy. Supported OPs include Google (Gmail) and Yahoo. 1153 * Level of Maturity: This is a "proof of concept" research 1154 implementation. 1155 * Coverage: This implementation includes all of the features 1156 described in this specification. 1157 * Version compatibility: Version -11 of this specification. 1158 * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 1160 9.2. Verisign Labs 1162 * Responsible Organization: Verisign Labs 1163 * Location: https://rdap.verisignlabs.com/ 1164 * Description: This implementation includes support for domain 1165 registry RDAP queries using live data from the .cc and .tv country 1166 code top-level domains and the .career generic top-level domain. 1167 Three access levels are provided based on the authenticated 1168 identity of the client: 1169 1. Unauthenticated: Limited information is returned in response 1170 to queries from unauthenticated clients. 1172 2. Basic: Clients who authenticate using a publicly available 1173 identity provider like Google Gmail or Microsoft Hotmail will 1174 receive all of the information available to an unauthenticated 1175 client plus additional registration metadata, but no 1176 personally identifiable information associated with entities. 1177 3. Advanced: Clients who authenticate using a more restrictive 1178 identity provider will receive all of the information 1179 available to a Basic client plus whatever information the 1180 server operator deems appropriate for a fully authorized 1181 client. Currently supported identity providers include those 1182 developed by Verisign Labs 1183 (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC 1184 (https://www.mojeid.cz/). 1185 * Level of Maturity: This is a "proof of concept" research 1186 implementation. 1187 * Coverage: This implementation includes all of the features 1188 described in this specification. 1189 * Version compatibility: Version -07 of this specification. 1190 * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 1192 9.3. Viagenie 1194 * Responsible Organization: Viagenie 1195 * Location: https://auth.viagenie.ca 1196 * Description: This implementation is an OpenID identity provider 1197 enabling users and registries to connect to the federation. It 1198 also includes a barebone RDAP client and RDAP server in order to 1199 test the authentication framework. Various level of purposes are 1200 available for testing. 1201 * Level of Maturity: This is a "proof of concept" research 1202 implementation. 1203 * Coverage: This implementation includes most features described in 1204 this specification as an identity provider. 1205 * Version compatibility: Version -07 of this specification. 1206 * Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca 1208 10. Security Considerations 1210 Security considerations for RDAP can be found in RFC 7481 [RFC7481]. 1211 Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 1212 [RFC6749] can be found in their reference specifications. OpenID 1213 Connect defines optional mechanisms for robust signing and encryption 1214 that can be used to provide data integrity and data confidentiality 1215 services as needed. 1217 10.1. Authentication and Access Control 1219 Having completed the client identification, authorization, and 1220 validation process, an RDAP server can make access control decisions 1221 based on a comparison of client-provided information and local 1222 policy. For example, a client who provides an email address (and 1223 nothing more) might be entitled to receive a subset of the 1224 information that would be available to a client who provides an email 1225 address, a full name, and a stated purpose. Development of these 1226 access control policies is beyond the scope of this document. 1228 11. Acknowledgments 1230 The author would like to acknowledge the following individuals for 1231 their contributions to the development of this document: Marc 1232 Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith, 1233 Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the 1234 Verisign Registry Services Lab development team of Joseph Harvey, 1235 Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin 1236 Singh, and Zhao Zhao provided critical "proof of concept" 1237 implementation experience that helped demonstrate the validity of the 1238 concepts described in this document. 1240 Mario Loffredo provided significant feedback based on implementation 1241 experience that led to welcome improvements in several sections of 1242 this document. His contributions are greatly appreciated. 1244 12. References 1246 12.1. Normative References 1248 [OIDC] OpenID Foundation, "OpenID Connect", 1249 . 1251 [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating 1252 errata set 1", November 2014, 1253 . 1255 [OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0 1256 incorporating errata set 1", November 2014, 1257 . 1260 [OIDCL] OpenID Foundation, "OpenID Connect RP-Initiated Logout 1.0 1261 - draft 01", August 2020, . 1264 [OIDCR] OpenID Foundation, "OpenID Connect Dynamic Client 1265 Registration 1.0 incorporating errata set 1", November 1266 2014, . 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, 1271 DOI 10.17487/RFC2119, March 1997, 1272 . 1274 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1275 Resource Identifier (URI): Generic Syntax", STD 66, 1276 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1277 . 1279 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1280 IANA Considerations Section in RFCs", RFC 5226, 1281 DOI 10.17487/RFC5226, May 2008, 1282 . 1284 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1285 DOI 10.17487/RFC6265, April 2011, 1286 . 1288 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1289 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1290 . 1292 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 1293 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 1294 August 2013, . 1296 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1297 Protocol (HTTP/1.1): Message Syntax and Routing", 1298 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1299 . 1301 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1302 Registration Data Access Protocol (RDAP)", STD 95, 1303 RFC 7480, DOI 10.17487/RFC7480, March 2015, 1304 . 1306 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 1307 Registration Data Access Protocol (RDAP)", STD 95, 1308 RFC 7481, DOI 10.17487/RFC7481, March 2015, 1309 . 1311 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1312 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1313 . 1315 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1316 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1317 . 1319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1321 May 2017, . 1323 [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, 1324 "OAuth 2.0 Device Authorization Grant", RFC 8628, 1325 DOI 10.17487/RFC8628, August 2019, 1326 . 1328 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., 1329 and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, 1330 DOI 10.17487/RFC8693, January 2020, 1331 . 1333 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 1334 Protocol (RDAP) Query Format", STD 95, RFC 9082, 1335 DOI 10.17487/RFC9082, June 2021, 1336 . 1338 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 1339 Registration Data Access Protocol (RDAP)", STD 95, 1340 RFC 9083, DOI 10.17487/RFC9083, June 2021, 1341 . 1343 12.2. Informative References 1345 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1346 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1347 . 1349 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1350 Code: The Implementation Status Section", BCP 205, 1351 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1352 . 1354 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1355 Authorization Server Metadata", RFC 8414, 1356 DOI 10.17487/RFC8414, June 2018, 1357 . 1359 Appendix A. Change Log 1361 00: Initial working group version ported from draft-hollenbeck- 1362 regext-rdap-openid-10. 1363 01: Modified ID Token delivery approach to note proper use of an 1364 HTTP bearer authorization header. 1365 02: Modified token delivery approach (Access Token is the bearer 1366 token) to note proper use of an HTTP bearer authorization header, 1367 fixing the change made in -01. 1368 03: Updated OAuth 2.0 Device Authorization Grant description and 1369 reference due to publication of RFC 8628. 1370 04: Updated OAuth 2.0 token exchange description and reference due 1371 to publication of RFC 8693. Corrected the RDAP conformance 1372 identifier to be registered with IANA. 1373 05: Keepalive refresh. 1374 06: Keepalive refresh. 1375 07: Added "login_hint" description to Section 3.1.3.2. Added some 1376 text to Section 3.1.4.2 to note that "do not track" requires 1377 compliance with local regulations. 1378 08: Rework of token management processing in Sections 4 and 5. 1379 09: Updated RDAP specification references. Added text to describe 1380 both local and remote Authorization Server processing. Removed 1381 text that described passing of ID Tokens as query parameters. 1382 10: Updated Section 3.1.3.1. Replaced token processing queries with 1383 "login", "session", and "logout" queries. 1384 11: Replaced queries with "session/*" queries. Added description of 1385 "rdap" OAuth scope. Added implementation status information. 1387 Author's Address 1389 Scott Hollenbeck 1390 Verisign Labs 1391 12061 Bluemont Way 1392 Reston, VA 20190 1393 United States of America 1394 Email: shollenbeck@verisign.com 1395 URI: http://www.verisignlabs.com/