idnits 2.17.1 draft-ietf-regext-rdap-openid-06.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 (January 5, 2021) is 1199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1143 -- Looks like a reference, but probably isn't: '2' on line 1146 -- Looks like a reference, but probably isn't: '3' on line 1148 -- 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. 'OIDCR' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082) ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 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 January 5, 2021 5 Expires: July 9, 2021 7 Federated Authentication for the Registration Data Access Protocol 8 (RDAP) using OpenID Connect 9 draft-ietf-regext-rdap-openid-06 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 July 9, 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4 65 3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5 66 3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.3. RDAP Authentication and Authorization Steps . . . . . 6 69 3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 6 70 3.1.3.2. Authentication Request . . . . . . . . . . . . . 6 71 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7 72 3.1.3.4. Authorization Response and Validation . . . . . . 7 73 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7 74 3.1.3.6. Delivery of User Information . . . . . . . . . . 7 75 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8 76 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8 77 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9 78 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. Client Authentication Request and Response . . . . . . . 10 80 4.2. Token Request and Response . . . . . . . . . . . . . . . 10 81 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11 82 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 83 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14 84 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15 85 5. Clients with Limited User Interfaces . . . . . . . . . . . . 15 86 5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16 87 5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17 90 6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17 91 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 17 92 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 93 7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21 94 7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 8.1. Authentication and Access Control . . . . . . . . . . . . 22 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 100 10.2. Informative References . . . . . . . . . . . . . . . . . 24 101 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 The Registration Data Access Protocol (RDAP) provides "RESTful" web 108 services to retrieve registration metadata from domain name and 109 regional internet registries. RDAP allows a server to make access 110 control decisions based on client identity, and as such it includes 111 support for client identification features provided by the Hypertext 112 Transfer Protocol (HTTP) [RFC7230]. 114 RDAP is specified in multiple documents, including "HTTP Usage in the 115 Registration Data Access Protocol (RDAP)" [RFC7480], "Security 116 Services for the Registration Data Access Protocol (RDAP)" [RFC7481], 117 "Registration Data Access Protocol Query Format" [RFC7482], and "JSON 118 Responses for the Registration Data Access Protocol (RDAP)" 119 [RFC7483]. RFC 7481 describes client identification and 120 authentication services that can be used with RDAP, but it does not 121 specify how any of these services can (or should) be used with RDAP. 123 1.1. Problem Statement 125 The traditional "user name and password" authentication method does 126 not scale well in the RDAP ecosystem. Assuming that all domain name 127 and address registries will eventually provide RDAP service, it is 128 impractical and inefficient for users to secure login credentials 129 from the hundreds of different server operators. Authentication 130 methods based on user names and passwords do not provide information 131 that describes the user in sufficient detail (while protecting the 132 personal privacy of the user) for server operators to make fine- 133 grained access control decisions based on the user's identity. The 134 authentication system used for RDAP needs to address all of these 135 needs. 137 1.2. Proposal 139 A basic level of RDAP service can be provided to users who possess an 140 identifier issued by a recognized provider who is able to 141 authenticate and validate the user. The identifiers issued by social 142 media services, for example, can be used. Users who require higher 143 levels of service (and who are willing to share more information 144 about them self to gain access to that service) can secure 145 identifiers from specialized providers who are or will be able to 146 provide more detailed information about the user. Server operators 147 can then make access control decisions based on the identification 148 information provided by the user. 150 A federated authentication system would make it easier to operate and 151 use RDAP by re-using existing identifiers to provide a basic level of 152 access. It can also provide the ability to collect additional user 153 identification information, and that information can be shared with 154 the consent of the user. This document describes a federated 155 authentication system for RDAP based on OpenID Connect [OIDC] that 156 meets all of these needs. 158 2. Conventions Used in This Document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Federated Authentication for RDAP 168 RDAP itself does not include native security services. Instead, RDAP 169 relies on features that are available in other protocol layers to 170 provide needed security services including access control, 171 authentication, authorization, availability, data confidentiality, 172 data integrity, and identification. A description of each of these 173 security services can be found in "Internet Security Glossary, 174 Version 2" [RFC4949]. This document focuses on a federated 175 authentication system for RDAP that provides services for 176 authentication, authorization, and identification, allowing a server 177 operator to make access control decisions. Section 3 of RFC 7481 178 [RFC7481] describes general considerations for RDAP access control, 179 authentication, and authorization. 181 The traditional client-server authentication model requires clients 182 to maintain distinct credentials for every RDAP server. This 183 situation can become unwieldy as the number of RDAP servers 184 increases. Federated authentication mechanisms allow clients to use 185 one credential to access multiple RDAP servers and reduce client 186 credential management complexity. 188 3.1. RDAP and OpenID Connect 190 OpenID Connect 1.0 [OIDCC] is a decentralized, single sign-on (SSO) 191 federated authentication system that allows users to access multiple 192 web resources with one identifier instead of having to create 193 multiple server-specific identifiers. Users acquire identifiers from 194 OpenID Providers, or OPs. Relying Parties, or RPs, are applications 195 (such as RDAP) that outsource their user authentication function to 196 an OP. OpenID Connect is built on top of the authorization framework 197 provided by the OAuth 2.0 [RFC6749] protocol. 199 The OAuth authorization framework describes a method for users to 200 access protected web resources without having to hand out their 201 credentials. Instead, clients are issued Access Tokens by 202 authorization servers with the permission of the resource owners. 203 Using OpenID Connect and OAuth, multiple RDAP servers can form a 204 federation and clients can access any server in the federation by 205 providing one credential registered with any OP in that federation. 206 The OAuth authorization framework is designed for use with HTTP and 207 thus can be used with RDAP. 209 3.1.1. Terminology 211 This document uses the terms "client" and "server" defined by RDAP 212 [RFC7480]. An RDAP client performs the role of an OpenID Connect 213 Core [OIDCC] Entity or End-User. An RDAP server performs the role of 214 an OpenID Connect Core Relying Party (RP). Additional terms from 215 Section 1.2 of the OpenID Connect Core specification are incorporated 216 by reference. 218 3.1.2. Overview 220 At a high level, RDAP authentication of a browser-based client using 221 OpenID Connect requires completion of the following steps: 223 1. An RDAP client (acting as an OpenID End-User) sends an HTTP (or 224 HTTPS) query containing OAuth 2.0 request parameters to an RDAP 225 server. 226 2. The RDAP server (acting as an OpenID Relying Party (RP)) prepares 227 an Authentication Request containing the desired request 228 parameters. 229 3. The RDAP server sends the RDAP client and Authentication Request 230 to an Authorization Server operated by an OpenID Provider (OP) 231 using an HTTP redirect. 232 4. The Authorization Server authenticates the RDAP Client. 233 5. The Authorization Server obtains RDAP Client consent/ 234 authorization. 236 6. The Authorization Server sends the RDAP Client back to the RDAP 237 server with an Authorization Code using an HTTP redirect. 238 7. The RDAP server requests a response using the Authorization Code 239 at the Token Endpoint. 240 8. The RDAP server receives a response that contains an ID Token and 241 Access Token in the response body. 242 9. The RDAP server validates the ID Token and retrieves the RDAP 243 client's Subject Identifier. 245 The RDAP server can then make identification, authorization, and 246 access control decisions based on local policies, the ID Token 247 received from the OP, and the received Claims. Note that OpenID 248 Connect describes different process flows for other types of clients, 249 such as script-based or command line clients. 251 3.1.3. RDAP Authentication and Authorization Steps 253 End-Users MUST possess an identifier (an OpenID) issued by an OP to 254 use OpenID Connect with RDAP. An OP MUST include support for the 255 claims described in Section 3.1.4 to provide additional information 256 needed for RDAP End-User authorization. OpenID Connect requires RPs 257 to register with OPs to use OpenID Connect services for an End-User. 258 That process is described by the "OpenID Connect Dynamic Client 259 Registration" protocol [OIDCR]. 261 3.1.3.1. Provider Discovery 263 An RDAP server/RP needs to receive an identifier from an End-User 264 that can be used to discover the End-User's OP. That process is 265 required and is documented in the "OpenID Connect Discovery" protocol 266 [OIDCD]. 268 3.1.3.2. Authentication Request 270 Once the OP is known, an RP MUST form an Authentication Request and 271 send it to the OP as described in Section 3 of the OpenID Connect 272 Core protocol [OIDCC]. The authentication path followed 273 (authorization, implicit, or hybrid) will depend on the 274 Authentication Request response_type set by the RP. The remainder of 275 the processing steps described here assume that the Authorization 276 Code Flow is being used by setting "response_type=code" in the 277 Authentication Request. 279 The benefits of using the Authorization Code Flow for authenticating 280 a human user are described in Section 3.1 of the OpenID Connect Core 281 protocol. The Implicit Flow is more commonly used by clients 282 implemented in a web browser using a scripting language; it is 283 described in Section 3.2 of the OpenID Connect Core protocol. The 284 Hybrid Flow (described in Section 3.3 of the OpenID Connect Core 285 protocol) combines elements of the Authorization and Implicit Flows 286 by returning some tokens from the Authorization Endpoint and others 287 from the Token Endpoint. 289 An Authentication Request can contain several parameters. REQUIRED 290 parameters are specified in Section 3.1.2.1 of the OpenID Connect 291 Core protocol [OIDCC]. Other parameters MAY be included. 293 The OP receives the Authentication Request and attempts to validate 294 it as described in Section 3.1.2.2 of the OpenID Connect Core 295 protocol [OIDCC]. If the request is valid, the OP attempts to 296 authenticate the End-User as described in Section 3.1.2.3 of the 297 OpenID Connect Core protocol [OIDCC]. The OP returns an error 298 response if the request is not valid or if any error is encountered. 300 3.1.3.3. End-User Authorization 302 After the End-User is authenticated, the OP MUST obtain authorization 303 information from the End-User before releasing information to the 304 RDAP Server/RP. This process is described in Section 3.1.2.4 of the 305 OpenID Connect Core protocol [OIDCC]. 307 3.1.3.4. Authorization Response and Validation 309 After the End-User is authenticated, the OP will send a response to 310 the RP that describes the result of the authorization process in the 311 form of an Authorization Grant. The RP MUST validate the response. 312 This process is described in Sections 3.1.2.5 - 3.1.2.7 of the OpenID 313 Connect Core protocol [OIDCC]. 315 3.1.3.5. Token Processing 317 The RP sends a Token Request using the Authorization Grant to a Token 318 Endpoint to obtain a Token Response containing an Access Token, ID 319 Token, and an OPTIONAL Refresh Token. The RP MUST validate the Token 320 Response. This process is described in Section 3.1.3 of the OpenID 321 Connect Core protocol [OIDCC]. 323 3.1.3.6. Delivery of User Information 325 The set of Claims can be retrieved by sending a request to a UserInfo 326 Endpoint using the Access Token. The Claims MAY be returned in the 327 ID Token. The process of retrieving Claims from a UserInfo Endpoint 328 is described in Section 5.3 of the OpenID Connect Core protocol 329 [OIDCC]. 331 OpenID Connect specified a set of standard Claims in Section 5.1. 332 Additional Claims for RDAP are described in Section 3.1.4. 334 3.1.4. Specialized Claims for RDAP 336 OpenID Connect claims are pieces of information used to make 337 assertions about an entity. Section 5 of the OpenID Connect Core 338 protocol [OIDCC] describes a set of standard claims that can be used 339 to identify a person. Section 5.1.2 notes that additional claims MAY 340 be used, and it describes a method to create them. 342 3.1.4.1. Stated Purpose 344 There are communities of RDAP users and operators who wish to make 345 and validate claims about a user's "need to know" when it comes to 346 requesting access to a resource. For example, a law enforcement 347 agent or a trademark attorney may wish to be able to assert that they 348 have a legal right to access a protected resource, and a server 349 operator will need to be able to receive and validate that claim. 350 These needs can be met by defining and using an additional "purpose" 351 claim. 353 The "purpose" claim identifies the purpose for which access to a 354 protected resource is being requested. Use of the "purpose" claim is 355 OPTIONAL; processing of this claim is subject to server acceptance of 356 the purpose and successful authentication of the End-User. 357 Unrecognized purpose values MUST be ignored and the associated query 358 MUST be processed as if the unrecognized purpose value was not 359 present at all. 361 The "purpose" value is a case-sensitive string containing a 362 StringOrURI value as specified in Section 2 of the JSON Web Token 363 (JWT) specification ([RFC7519]). An example: 365 {"purpose" : "domainNameControl"} 367 Purpose values are themselves registered with IANA. Each entry in 368 the registry contains the following fields: 370 Value: the purpose string value being registered. Value strings can 371 contain upper case characters from "A" to "Z", lower case ASCII 372 characters from "a" to "z", and the underscore ("_") character. 373 Value strings contain at least one character and no more than 64 374 characters. 376 Description: a one- or two-sentence description of the meaning of the 377 purpose value, how it might be used, and/or how it should be 378 interpreted by clients and servers. 380 This registry is operated under the "Specification Required" policy 381 defined in RFC 5226 ([RFC5226]). The set of initial values used to 382 populate the registry as described in Section 6.3 are taken from the 383 final report [1] produced by the Expert Working Group on gTLD 384 Directory Services chartered by the Internet Corporation for Assigned 385 Names and Numbers (ICANN). 387 3.1.4.2. Do Not Track 389 There are also communities of RDAP users and operators who wish to 390 make and validate claims about a user's wish to not have their 391 queries logged, tracked, or recorded. For example, a law enforcement 392 agent may wish to be able to assert that their queries are part of a 393 criminal investigation and should not be tracked due to a risk of 394 query exposure compromising the investigation, and a server operator 395 will need to be able to receive and validate that claim. These needs 396 can be met by defining and using an additional "do not track" claim. 398 The "do not track" ("dnt") claim can be used to identify an End-User 399 that is authorized to perform queries without the End-User's 400 association with those queries being logged, tracked, or recorded by 401 the server. Client use of the "dnt" claim is OPTIONAL. Server 402 operators MUST NOT log, track, or record any association of the query 403 and the End-User's identity if the End-User is successfully 404 identified and authorized, the "dnt" claim is present, and the value 405 of the claim is "true". 407 The "dnt" value is represented as a JSON boolean literal. An 408 example: 410 {"dnt" : true} 412 No special query tracking processing is required if this claim is not 413 present or if the value of the claim is "false". Use of this claim 414 MUST be limited to End-Users who are granted "do not track" 415 priviliges in accordance with service policies and regulations. 416 Specification of these policies and regulations is beyond the scope 417 of this document. 419 4. Protocol Parameters 421 This specification adds the following protocol parameters to RDAP: 423 1. A query parameter to request authentication for a specific end- 424 user identity. 425 2. A path segment to request an ID Token and an Access Token for a 426 specific end-user identity. 428 3. A query parameter to deliver an ID Token and an Access Token for 429 use with an RDAP query. 431 4.1. Client Authentication Request and Response 433 Client authentication is requested by adding a query component to an 434 RDAP request URI using the syntax described in Section 3.4 of RFC 435 3986 [RFC3986]. The query used to request client authentication is 436 represented as a "key=value" pair using a key value of "id" and a 437 value component that contains the client identifier issued by an OP. 438 An example: 440 https://example.com/rdap/domain/example.com?id=user.idp.example 442 The response to an authenticated query MUST use the response 443 structures specified in RFC 7483 [RFC7483]. Information that the 444 end-user is not authorized to receive MUST be omitted from the 445 response. 447 4.2. Token Request and Response 449 Clients MAY send a request to an RDAP server to authenticate an end- 450 user and return an ID Token and an Access Token from an OP that can 451 be then be passed to the RP/RDAP server to authenticate and process 452 subsequent queries. Identity provider authentication is requested 453 using a "tokens" path segment and a query parameter with key value of 454 "id" and a value component that contains the client identifier issued 455 by an OP. An example: 457 https://example.com/rdap/tokens?id=user.idp.example 459 In addition to any core RDAP response elements, the response to this 460 query MUST contain four name-value pairs, in any order, representing 461 the returned ID Token and Access Token. The ID Token is represented 462 using a key value of "id_token". The Access Token is represented 463 using a key value of "access_token". The access token type is 464 represented using a key value of "token_type" and a value of "bearer" 465 as described in Sections 4.2.2 and 7.1 of RFC 6749 [RFC6749]. The 466 lifetime of the access token is represented using a key value of 467 "expires_in" and a numerical value that describes the lifetime in 468 seconds of the access token as described in Section 4.2.2 of RFC 6749 469 [RFC6749]. The token values returned in the RDAP server response 470 MUST be Base64url encoded as described in RFCs 7515 [RFC7515] and 471 7519 [RFC7519]. 473 An example (the encoded tokens have been abbreviated for clarity): 475 { 476 "access_token" : "eyJ0...NiJ9", 477 "id_token" : "eyJ0...EjXk", 478 "token_type" : "bearer", 479 "expires_in" : "3600" 480 } 482 Figure 1 484 An RDAP server that processes this type of query MUST determine if 485 the identifier is associated with an OP that is recognized and 486 supported by the server. Servers MUST reject queries that include an 487 identifier associated with an unsupported OP with an HTTP 501 (Not 488 Implemented) response. An RDAP server that receives a query 489 containing an identifier associated with a recognized OP MUST perform 490 the steps required to authenticate the user with the OP using a 491 browser or browser-like client and return encoded tokens to the 492 client. Note that tokens are typically valid for a limited period of 493 time and new tokens will be required when an existing token's 494 validity period has expired. 496 The tokens can then be passed to the server for use with an RDAP 497 query by passing the encoded ID Token as a query parameter with a key 498 value of "id_token" and the encoded Access Token in an HTTP Bearer 499 authorization header [RFC6750]. An example (the encoded tokens have 500 been abbreviated and the URI split across multiple lines for 501 clarity): 503 https://example.com/rdap/domain/example.com?id_token=eyJ0...EjXk 505 Authorization: Bearer eyJ0...NiJ9 507 The response to an authenticated query MUST use the response 508 structures specified in RFC 7483 [RFC7483]. Information that the 509 end-user is not authorized to receive MUST be omitted from the 510 response. 512 4.3. Token Refresh and Revocation 514 An access token can be refreshed as described in Section 12 of the 515 OpenID Connect Core protocol [OIDCC] and Section 6 of OAuth 2.0 516 [RFC6749]. Clients can take advantage of this functionality if it is 517 supported by the OP and accepted by the RDAP server. 519 A refresh token is requested using a "tokens" path segment and two 520 query parameters. The first query parameter includes a key value of 521 "id" and a value component that contains the client identifier issued 522 by an OP. The second query parameter includes a key value of 523 "refresh" and a value component of "true". A value component of 524 "false" MUST be processed to return a result that is consistent with 525 not including a "refresh" parameter at all as described in 526 Section 4.2. An example using "refresh=true": 528 https://example.com/rdap/tokens?id=user.idp.example 529 &refresh=true 531 The response to this query MUST contain all of the response elements 532 described in Section 4.2. In addition, the response MUST contain a 533 name-value pair that represents a refresh token. The name-value pair 534 includes a key value of "refresh_token" and a Base64url-encoded value 535 that represents the refresh token. 537 Example refresh token request response (the encoded tokens have been 538 abbreviated for clarity): 540 { 541 "access_token" : "eyJ0...NiJ9", 542 "id_token" : "eyJ0...EjXk", 543 "token_type" : "bearer", 544 "expires_in" : "3600", 545 "refresh_token" : "eyJ0...c8da" 546 } 548 Figure 2 550 Once acquired, a refresh token can be used to refresh an access 551 token. An access token is refreshed using a "tokens" path segment 552 and two query parameters. The first query parameter includes a key 553 value of "id" and a value component that contains the client 554 identifier issued by an OP. The second query parameter includes a 555 key value of "refresh_token" and a Base64url-encoded value that 556 represents the refresh token. An example: 558 https://example.com/rdap/tokens?id=user.idp.example 559 &refresh_token=eyJ0...f3jE 561 In addition to any core RDAP response elements, the response to this 562 query MUST contain four name-value pairs, in any order, representing 563 a returned Refresh Token and Access Token. The Refresh Token is 564 represented using a key value of "refresh_token". The Access Token 565 is represented using a key value of "access_token". The access token 566 type is represented using a key value of "token_type" and a value of 567 "bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749 568 [RFC6749]. The lifetime of the access token is represented using a 569 key value of "expires_in" and a numerical value that describes the 570 lifetime in seconds of the access token as described in Section 4.2.2 571 of RFC 6749 [RFC6749]. The token values returned in the RDAP server 572 response MUST be Base64url encoded as described in RFCs 7515 573 [RFC7515] and 7519 [RFC7519]. 575 Example access token refresh response (the encoded tokens have been 576 abbreviated for clarity): 578 { 579 "access_token" : "0dac...13b0", 580 "refresh_token" : "f735...d30c", 581 "token_type" : "bearer", 582 "expires_in" : "3600" 583 } 585 Figure 3 587 Access and refresh tokens can be revoked as described in RFC 7009 588 [RFC7009] by sending a request to an RDAP server that contains a 589 "tokens/revoke" path segment and two query parameters. The first 590 query parameter includes a key value of "id" and a value component 591 that contains the client identifier issued by an OP. The second 592 query parameter includes a key value of "token" and a Base64url- 593 encoded value that represents either the current refresh token or the 594 associated access token. An example: 596 https://example.com/rdap/tokens/revoke?id=user.idp.example 597 &token=f735...d30c 599 Note that this command will revoke both access and refresh tokens at 600 the same time. In addition to any core RDAP response elements, the 601 response to this query MUST contain a description of the result of 602 processing the revocation request within the RDAP "notices" data 603 structure. 605 Example token revocation success: 607 "notices" : 608 [ 609 { 610 "title" : "Token Revocation Result", 611 "description" : "Token revocation succeeded.", 612 } 613 ], 614 "lang" : "en-US" 616 Figure 4 618 Example token revocation failure: 620 "notices" : 621 [ 622 { 623 "title" : "Token Revocation Result", 624 "description" : "Token revocation failed.", 625 } 626 ], 627 "errorCode" : 400, 628 "lang" : "en-US" 630 Figure 5 632 4.4. Token Exchange 634 ID tokens include an audience parameter that contains the OAuth 2.0 635 client_id of the RP as an audience value. In some operational 636 scenarios (such as a client that is providing a proxy service), an RP 637 can receive tokens with an audience value that does not include the 638 RP's client_id. These tokens might not be trusted by the RP, and the 639 RP might refuse to accept the tokens. This situation can be remedied 640 by having the RP exchange these tokens with the OP for a set of 641 trusted tokens that reset the audience parameter. This token 642 exchange protocol is described in RFC 8693 [RFC8693]. 644 4.5. Parameter Processing 646 Unrecognized query parameters MUST be ignored. An RDAP request that 647 does not include an "id" query component MUST be processed as an 648 unauthenticated query. An RDAP server that processes an 649 authenticated query MUST determine if the identifier is associated 650 with an OP that is recognized and supported by the server. Servers 651 MUST reject queries that include an identifier associated with an 652 unsupported OP with an HTTP 501 (Not Implemented) response. An RDAP 653 server that receives a query containing an identifier associated with 654 a recognized OP MUST perform the steps required to authenticate the 655 user with the OP, process the query, and return an RDAP response that 656 is appropriate for the end user's level of authorization and access. 658 An RDAP server that receives a query containing tokens associated 659 with a recognized OP and authenticated end user MUST process the 660 query and return an RDAP response that is appropriate for the end 661 user's level of authorization and access. Errors based on processing 662 either the ID Token or the Access Token MUST be signaled with an 663 appropriate HTTP status code as described in Section 3.1 of RFC 6750 664 [RFC6750]. 666 On receiving a query containing tokens, the RDAP server MUST validate 667 the ID Token. It can do this independently of the OP, because the ID 668 Token is a JWT that contains all the data necessary for validation. 669 The Access Token, however, is an opaque value, and can only be 670 validated by sending a request using it to the UserInfo Endpoint and 671 confirming that a successful response is received. This is different 672 from the OpenID Connect Authorization Code and Implicit flows, where 673 the Access Token can be validated against the at_hash claim from the 674 ID Token. With a query containing tokens, the Access Token might not 675 validate against the at_hash claim because the Access Token may have 676 been refreshed since the ID Token was issued. 678 An RDAP server that processes requests without needing the UserInfo 679 claims does not need to retrieve the claims merely in order to 680 validate the Access Token. Similarly, an RDAP server that has cached 681 the UserInfo claims for an end user, in accordance with the HTTP 682 headers of a previous UserInfo Endpoint response, does not need to 683 retrieve those claims again in order to revalidate the Access Token. 685 4.6. RDAP Conformance 687 RDAP responses that contain values described in this document MUST 688 indicate conformance with this specification by including an 689 rdapConformance ([RFC7483]) value of "rdap_openidc_level_0". The 690 information needed to register this value in the RDAP Extensions 691 Registry is described in Section 6.1. 693 Example rdapConformance structure with extension specified: 695 "rdapConformance" : 696 [ 697 "rdap_level_0", 698 "rdap_openidc_level_0" 699 ] 701 Figure 6 703 5. Clients with Limited User Interfaces 705 The flow described in Section 3.1.3 requires a client to interact 706 with a server using a web browser. This will not work well in 707 situations where the client is automated or an end-user is using a 708 command line user interface such as curl [2] or wget [3]. There are 709 multiple ways to address this limitation using a web browser on a 710 second device. Two are described here. 712 5.1. OAuth 2.0 Device Authorization Grant 714 The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides one 715 method to request user authorization from devices that have an 716 Internet connection, but lack a suitable browser for a more 717 traditional OAuth flow. This method requires a client to use a 718 second device (such as a smart telephone) that has access to a web 719 browser for entry of a code sequence that is presented on the 720 constrained device. 722 5.2. Manual Token Management 724 A second method of requesting user authorization from a constrained 725 device is possible by producing and managing tokens manually as 726 follows: 728 1. Authenticate with the OP as described in Section 4.2 using a 729 browser or browser-like client. 730 2. Store the returned ID Token and Access Token locally. 731 3. Send a request to the content provider/RP along with the ID Token 732 and Access Token received from the OP. 734 The Access Token MAY be passed to the RP in an HTTP "Authorization" 735 header [RFC7235] or as a query parameter. The Access Token MUST be 736 specified using the "Bearer" authentication scheme [RFC6750] if it is 737 passed in an "Authorization" header. The ID Token MUST be passed to 738 the RP as a query parameter. 740 Here are two examples using the curl and wget utilities. Start by 741 authenticating with the OP: 743 https://example.com/rdap/tokens?id=user.idp.example 745 Save the token information and pass it to the RP along with the URI 746 representing the RDAP query. Using curl (encoded tokens have been 747 abbreviated for clarity: 749 curl -H "Authorization: Bearer eyJ0...NiJ9"\ 750 -k https://example.com/rdap/domain/example.com\ 751 ?id_token=eyJ0...EjXk 753 curl -k https://example.com/rdap/domain/example.com\ 754 ?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 756 Using wget: 758 wget --header="Authorization: Bearer eyJ0...NiJ9"\ 759 https://example.com/rdap/domain/example.com\ 760 ?id_token=eyJ0...EjXk 762 wget https://example.com/rdap/domain/example.com\ 763 ?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 765 Refresh tokens can be useful to automated or command line clients who 766 wish to continue a session without explicitly re-authenticating an 767 end user. See Section 4.3 for more information. 769 6. IANA Considerations 771 6.1. RDAP Extensions Registry 773 IANA is requested to register the following value in the RDAP 774 Extensions Registry: 776 Extension identifier: rdap_openidc_level_0 777 Registry operator: Any 778 Published specification: This document. 779 Contact: IESG 780 Intended usage: This extension describes a federated 781 authentication method for RDAP using OAuth 2.0 and OpenID Connect. 783 6.2. JSON Web Token Claims Registry 785 IANA is requested to register the following values in the JSON Web 786 Token Claims Registry: 788 Claim Name: "purpose" 789 Claim Description: This claim describes the stated purpose for 790 submitting a request to access a protected RDAP resource. 791 Change Controller: IESG 792 Specification Document(s): Section 3.1.4.1 of this document. 794 Claim Name: "dnt" 795 Claim Description: This claim contains a JSON boolean literal that 796 describes an End-User's "do not track" preference for identity 797 tracking, logging, or recording when accessing a protected RDAP 798 resource. 799 Change Controller: IESG 800 Specification Document(s): Section 3.1.4.2 of this document. 802 6.3. RDAP Query Purpose Registry 804 IANA is requested to create a new protocol registry to manage RDAP 805 query purpose values. This registry should appear under its own 806 heading on IANA's protocol listings, using the same title as the name 807 of the registry. The information to be registered and the procedures 808 to be followed in populating the registry are described in 809 Section 3.1.4.1. 811 Name of registry: Registration Data Access Protocol (RDAP) Query 812 Purpose Values 814 Section at http://www.iana.org/protocols: 816 Registry Title: Registration Data Access Protocol (RDAP) Query 817 Purpose Values 819 Registry Name: Registration Data Access Protocol (RDAP) Query Purpose 820 Values 822 Registration Procedure: Specification Required 824 Reference: This draft 826 Required information: See Section 3.1.4.1. 828 Review process: "Specification Required" as described in RFC 5226 829 [RFC5226]. 831 Size, format, and syntax of registry entries: See Section 3.1.4.1. 833 Initial assignments and reservations: 835 -----BEGIN FORM----- 836 Value: domainNameControl 837 Description: Tasks within the scope of this purpose include creating 838 and managing and monitoring a registrant's own domain name, including 839 creating the domain name, updating information about the domain name, 840 transferring the domain name, renewing the domain name, deleting the 841 domain name, maintaining a domain name portfolio, and detecting 842 fraudulent use of the Registrant's own contact information. 843 -----END FORM----- 845 -----BEGIN FORM----- 846 Value: personalDataProtection 847 Description: Tasks within the scope of this purpose include 848 identifying the accredited privacy/proxy provider associated with a 849 domain name and reporting abuse, requesting reveal, or otherwise 850 contacting the provider. 851 -----END FORM----- 853 -----BEGIN FORM----- 854 Value: technicalIssueResolution 855 Description: Tasks within the scope of this purpose include (but are 856 not limited to) working to resolve technical issues, including email 857 delivery issues, DNS resolution failures, and web site functional 858 issues. 859 -----END FORM----- 861 -----BEGIN FORM----- 862 Value: domainNameCertification 863 Description: Tasks within the scope of this purpose include a 864 Certification Authority (CA) issuing an X.509 certificate to a 865 subject identified by a domain name. 866 -----END FORM----- 868 -----BEGIN FORM----- 869 Value: individualInternetUse 870 Description: Tasks within the scope of this purpose include 871 identifying the organization using a domain name to instill consumer 872 trust, or contacting that organization to raise a customer complaint 873 to them or file a complaint about them. 874 -----END FORM----- 876 -----BEGIN FORM----- 877 Value: businessDomainNamePurchaseOrSale 878 Description: Tasks within the scope of this purpose include making 879 purchase queries about a domain name, acquiring a domain name from a 880 registrant, and enabling due diligence research. 881 -----END FORM----- 883 -----BEGIN FORM----- 884 Value: academicPublicInterestDNSRResearch 885 Description: Tasks within the scope of this purpose include academic 886 public interest research studies about domain names published in the 887 registration data service, including public information about the 888 registrant and designated contacts, the domain name's history and 889 status, and domain names registered by a given registrant (reverse 890 query). 891 -----END FORM----- 893 -----BEGIN FORM----- 894 Value: legalActions 895 Description: Tasks within the scope of this purpose include 896 investigating possible fraudulent use of a registrant's name or 897 address by other domain names, investigating possible trademark 898 infringement, contacting a registrant/licensee's legal representative 899 prior to taking legal action and then taking a legal action if the 900 concern is not satisfactorily addressed. 901 -----END FORM----- 902 -----BEGIN FORM----- 903 Value: regulatoryAndContractEnforcement 904 Description: Tasks within the scope of this purpose include tax 905 authority investigation of businesses with online presence, Uniform 906 Dispute Resolution Policy (UDRP) investigation, contractual 907 compliance investigation, and registration data escrow audits. 908 -----END FORM----- 910 -----BEGIN FORM----- 911 Value: criminalInvestigationAndDNSAbuseMitigation 912 Description: Tasks within the scope of this purpose include reporting 913 abuse to someone who can investigate and address that abuse, or 914 contacting entities associated with a domain name during an offline 915 criminal investigation. 916 -----END FORM----- 918 -----BEGIN FORM----- 919 Value: dnsTransparency 920 Description: Tasks within the scope of this purpose involve querying 921 the registration data made public by registrants to satisfy a wide 922 variety of use cases around informing the general public. 923 -----END FORM----- 925 7. Implementation Status 927 NOTE: Please remove this section and the reference to RFC 7942 prior 928 to publication as an RFC. 930 This section records the status of known implementations of the 931 protocol defined by this specification at the time of posting of this 932 Internet-Draft, and is based on a proposal described in RFC 7942 933 [RFC7942]. The description of implementations in this section is 934 intended to assist the IETF in its decision processes in progressing 935 drafts to RFCs. Please note that the listing of any individual 936 implementation here does not imply endorsement by the IETF. 937 Furthermore, no effort has been spent to verify the information 938 presented here that was supplied by IETF contributors. This is not 939 intended as, and must not be construed to be, a catalog of available 940 implementations or their features. Readers are advised to note that 941 other implementations may exist. 943 According to RFC 7942, "this will allow reviewers and working groups 944 to assign due consideration to documents that have the benefit of 945 running code, which may serve as evidence of valuable experimentation 946 and feedback that have made the implemented protocols more mature. 947 It is up to the individual working groups to use this information as 948 they see fit". 950 7.1. Verisign Labs 952 Responsible Organization: Verisign Labs 953 Location: https://rdap.verisignlabs.com/ 954 Description: This implementation includes support for domain 955 registry RDAP queries using live data from the .cc and .tv country 956 code top-level domains and the .career generic top-level domain. 957 Three access levels are provided based on the authenticated 958 identity of the client: 960 1. Unauthenticated: Limited information is returned in response 961 to queries from unauthenticated clients. 962 2. Basic: Clients who authenticate using a publicly available 963 identity provider like Google Gmail or Microsoft Hotmail will 964 receive all of the information available to an unauthenticated 965 client plus additional registration metadata, but no 966 personally identifiable information associated with entities. 967 3. Advanced: Clients who authenticate using a more restrictive 968 identity provider will receive all of the information 969 available to a Basic client plus whatever information the 970 server operator deems appropriate for a fully authorized 971 client. Currently supported identity providers include those 972 developed by Verisign Labs 973 (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC 974 (https://www.mojeid.cz/). 975 Level of Maturity: This is a "proof of concept" research 976 implementation. 977 Coverage: This implementation includes all of the features 978 described in this specification. 979 Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 981 7.2. Viagenie 983 Responsible Organization: Viagenie 984 Location: https://auth.viagenie.ca 985 Description: This implementation is an OpenID identity provider 986 enabling users and registries to connect to the federation. It 987 also includes a barebone RDAP client and RDAP server in order to 988 test the authentication framework. Various level of purposes are 989 available for testing. 990 Level of Maturity: This is a "proof of concept" research 991 implementation. 992 Coverage: This implementation includes most features described in 993 this specification as an identity provider. 994 Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca 996 8. Security Considerations 998 Security considerations for RDAP can be found in RFC 7481 [RFC7481]. 999 Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 1000 [RFC6749] can be found in their reference specifications. OpenID 1001 Connect defines optional mechanisms for robust signing and encryption 1002 that can be used to provide data integrity and data confidentiality 1003 services as needed. Security services for ID Tokens and Access 1004 Tokens (with references to the JWT specification) are described in 1005 the OpenID Connect Core protocol. 1007 8.1. Authentication and Access Control 1009 Having completed the client identification, authorization, and 1010 validation process, an RDAP server can make access control decisions 1011 based on a comparison of client-provided information and local 1012 policy. For example, a client who provides an email address (and 1013 nothing more) might be entitled to receive a subset of the 1014 information that would be available to a client who provides an email 1015 address, a full name, and a stated purpose. Development of these 1016 access control policies is beyond the scope of this document. 1018 9. Acknowledgements 1020 The author would like to acknowledge the following individuals for 1021 their contributions to the development of this document: Tom 1022 Harrison, Russ Housley, Rhys Smith, Jaromir Talir, and Alessandro 1023 Vesely. In addition, the Verisign Registry Services Lab development 1024 team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, 1025 Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof 1026 of concept" implementation experience that helped demonstrate the 1027 validity of the concepts described in this document. 1029 10. References 1031 10.1. Normative References 1033 [OIDC] OpenID Foundation, "OpenID Connect", 1034 . 1036 [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating 1037 errata set 1", November 2014, 1038 . 1040 [OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0 1041 incorporating errata set 1", November 2014, 1042 . 1045 [OIDCR] OpenID Foundation, "OpenID Connect Dynamic Client 1046 Registration 1.0 incorporating errata set 1", November 1047 2014, . 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, 1052 DOI 10.17487/RFC2119, March 1997, 1053 . 1055 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1056 Resource Identifier (URI): Generic Syntax", STD 66, 1057 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1058 . 1060 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1061 IANA Considerations Section in RFCs", RFC 5226, 1062 DOI 10.17487/RFC5226, May 2008, 1063 . 1065 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1066 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1067 . 1069 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1070 Framework: Bearer Token Usage", RFC 6750, 1071 DOI 10.17487/RFC6750, October 2012, 1072 . 1074 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 1075 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 1076 August 2013, . 1078 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1079 Protocol (HTTP/1.1): Message Syntax and Routing", 1080 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1081 . 1083 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1084 Protocol (HTTP/1.1): Authentication", RFC 7235, 1085 DOI 10.17487/RFC7235, June 2014, 1086 . 1088 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1089 Registration Data Access Protocol (RDAP)", RFC 7480, 1090 DOI 10.17487/RFC7480, March 2015, 1091 . 1093 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 1094 Registration Data Access Protocol (RDAP)", RFC 7481, 1095 DOI 10.17487/RFC7481, March 2015, 1096 . 1098 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 1099 Protocol (RDAP) Query Format", RFC 7482, 1100 DOI 10.17487/RFC7482, March 2015, 1101 . 1103 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 1104 Registration Data Access Protocol (RDAP)", RFC 7483, 1105 DOI 10.17487/RFC7483, March 2015, 1106 . 1108 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1109 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1110 2015, . 1112 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1113 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1114 . 1116 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1117 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1118 May 2017, . 1120 [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, 1121 "OAuth 2.0 Device Authorization Grant", RFC 8628, 1122 DOI 10.17487/RFC8628, August 2019, 1123 . 1125 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., 1126 and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, 1127 DOI 10.17487/RFC8693, January 2020, 1128 . 1130 10.2. Informative References 1132 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1133 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1134 . 1136 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1137 Code: The Implementation Status Section", BCP 205, 1138 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1139 . 1141 10.3. URIs 1143 [1] https://www.icann.org/en/system/files/files/final-report- 1144 06jun14-en.pdf 1146 [2] http://curl.haxx.se/ 1148 [3] https://www.gnu.org/software/wget/ 1150 Appendix A. Change Log 1152 00: Initial working group version ported from draft-hollenbeck- 1153 regext-rdap-openid-10. 1154 01: Modified ID Token delivery approach to note proper use of an 1155 HTTP bearer authorization header. 1156 02: Modified token delivery approach (access token is the bearer 1157 token) to note proper use of an HTTP bearer authorization header, 1158 fixing the change made in -01. 1159 03: Updated OAuth 2.0 Device Authorization Grant description and 1160 reference due to publication of RFC 8628. 1161 04: Updated OAuth 2.0 token exchange description and reference due 1162 to publication of RFC 8693. Corrected the RDAP conformance 1163 identifier to be registered with IANA. 1164 05: Keepalive refresh. 1165 06: Keepalive refresh. 1167 Author's Address 1169 Scott Hollenbeck 1170 Verisign Labs 1171 12061 Bluemont Way 1172 Reston, VA 20190 1173 USA 1175 Email: shollenbeck@verisign.com 1176 URI: http://www.verisignlabs.com/