1 Internet Engineering Task Force (IETF) S. Hollenbeck
2 Request for Comments: 9560 Verisign Labs
3 Category: Standards Track April 2024
4 ISSN: 2070-1721
5
6
7 Federated Authentication for the Registration Data Access Protocol
8 (RDAP) Using OpenID Connect
9
10 Abstract
11
12 The Registration Data Access Protocol (RDAP) provides
13 Representational State Transfer (RESTful) web services to retrieve
14 registration metadata from domain name and regional internet
15 registries. RDAP allows a server to make access control decisions
16 based on client identity, and as such, it includes support for client
17 identification features provided by the Hypertext Transfer Protocol
18 (HTTP). Identification methods that require clients to obtain and
19 manage credentials from every RDAP server operator present management
20 challenges for both clients and servers, whereas a federated
21 authentication system would make it easier to operate and use RDAP
22 without the need to maintain server-specific client credentials.
23 This document describes a federated authentication system for RDAP
24 based on OpenID Connect.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 7841.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 https://www.rfc-editor.org/info/rfc9560.
39
40 Copyright Notice
41
42 Copyright (c) 2024 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
44
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Revised BSD License text as described in Section 4.e of the
52 Trust Legal Provisions and are provided without warranty as described
53 in the Revised BSD License.
54
55 Table of Contents
56
57 1. Introduction
58 1.1. Problem Statement
59 1.2. Approach
60 2. Conventions Used in This Document
61 3. Federated Authentication for RDAP
62 3.1. RDAP and OpenID Connect
63 3.1.1. Terminology
64 3.1.2. Client Considerations
65 3.1.3. Overview
66 3.1.4. RDAP Authentication and Authorization Steps
67 3.1.4.1. Provider Discovery
68 3.1.4.2. Authentication Request
69 3.1.4.3. End User Authorization
70 3.1.4.4. Authorization Response and Validation
71 3.1.4.5. Token Processing
72 3.1.4.6. Delivery of User Information
73 3.1.5. Specialized Claims and Authorization Scope for RDAP
74 3.1.5.1. Stated Purposes
75 3.1.5.2. Do Not Track
76 4. Common Protocol Features
77 4.1. OpenID Connect Configuration
78 4.2. RDAP Query Parameters
79 4.2.1. RDAP Query Purpose
80 4.2.2. RDAP Do Not Track
81 4.2.3. Parameter Processing
82 5. Protocol Features for Session-Oriented Clients
83 5.1. Data Structures
84 5.1.1. Session
85 5.1.2. Device Info
86 5.2. Client Login
87 5.2.1. End-User Identifier
88 5.2.2. OP Issuer Identifier
89 5.2.3. Login Response
90 5.2.4. Clients with Limited User Interfaces
91 5.2.4.1. UI-Constrained Client Login
92 5.2.4.2. UI-Constrained Client Login Polling
93 5.3. Session Status
94 5.4. Session Refresh
95 5.5. Client Logout
96 5.6. Request Sequencing
97 6. Protocol Features for Token-Oriented Clients
98 6.1. Client Login
99 6.2. Client Queries
100 6.3. Access Token Validation
101 6.4. Token Exchange
102 7. RDAP Query Processing
103 8. RDAP Conformance
104 9. IANA Considerations
105 9.1. RDAP Extensions Registry
106 9.2. JSON Web Token Claims Registry
107 9.3. RDAP Query Purpose Registry
108 10. Security Considerations
109 10.1. Authentication and Access Control
110 11. References
111 11.1. Normative References
112 11.2. Informative References
113 Acknowledgments
114 Author's Address
115
116 1. Introduction
117
118 The Registration Data Access Protocol (RDAP) provides
119 Representational State Transfer (RESTful) web services to retrieve
120 registration metadata from domain name and regional internet
121 registries. RDAP allows a server to make access control decisions
122 based on client identity, and as such, it includes support for client
123 identification features provided by the Hypertext Transfer Protocol
124 (HTTP) [RFC9110].
125
126 RDAP is specified in multiple documents, including "HTTP Usage in the
127 Registration Data Access Protocol (RDAP)" [RFC7480], "Security
128 Services for the Registration Data Access Protocol (RDAP)" [RFC7481],
129 "Registration Data Access Protocol (RDAP) Query Format" [RFC9082],
130 and "JSON Responses for the Registration Data Access Protocol (RDAP)"
131 [RFC9083]. [RFC7481] describes client identification and
132 authentication services that can be used with RDAP, but it does not
133 specify how any of these services can (or should) be used with RDAP.
134
135 1.1. Problem Statement
136
137 The conventional "username and password" authentication method does
138 not scale well in the RDAP ecosystem. Assuming that all domain name
139 and address registries will eventually provide RDAP service, it is
140 impractical and inefficient for users to secure login credentials
141 from the hundreds of different server operators. Authentication
142 methods based on usernames and passwords do not provide information
143 that describes the user in sufficient detail (while protecting the
144 personal privacy of the user) for server operators to make fine-
145 grained access control decisions based on the user's identity. The
146 authentication system used for RDAP needs to address all of these
147 needs.
148
149 1.2. Approach
150
151 A basic level of RDAP service can be provided to users who possess an
152 identifier issued by a recognized provider who can authenticate and
153 validate the user. For example, the identifiers issued by social
154 media services can be used. Users who require higher levels of
155 service (and who are willing to share more information about
156 themselves to gain access to that service) can secure identifiers
157 from specialized providers who are or will be able to provide more
158 detailed information about the user. Server operators can then make
159 access control decisions based on the identification information
160 provided by the user.
161
162 A federated authentication system in which an RDAP server outsources
163 identification and authentication services to a trusted identity
164 provider would make it easier to operate and use RDAP by reusing
165 existing identifiers to provide a basic level of access. It can also
166 provide the ability to collect additional user identification
167 information, and that information can be shared with the RDAP server
168 operator with the consent of the user in order to help the server
169 operator make access control decisions. This type of system allows
170 an RDAP server to make access control decisions based on the nature
171 of a query and the identity, authentication, and authorization
172 information that is received from the identity provider. This
173 document describes a federated authentication system for RDAP based
174 on OpenID Connect [OIDC] that meets these needs.
175
176 2. Conventions Used in This Document
177
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
180 "OPTIONAL" in this document are to be interpreted as described in BCP
181 14 [RFC2119] [RFC8174] when, and only when, they appear in all
182 capitals, as shown here.
183
184 All of the HTTP requests described in this document that are sent
185 from an RDAP client to an RDAP server use the HTTP GET method as
186 specified in [RFC9110].
187
188 Long lines in examples are wrapped using "The Single Backslash
189 Strategy" described in [RFC8792].
190
191 3. Federated Authentication for RDAP
192
193 RDAP itself does not include built-in security services. Instead,
194 RDAP relies on features that are available in other protocol layers
195 to provide needed security services including access control,
196 authentication, authorization, availability, data confidentiality,
197 data integrity, and identification. A description of each of these
198 security services can be found in "Internet Security Glossary,
199 Version 2" [RFC4949]. This document focuses on a federated
200 authentication system for RDAP that provides services for
201 authentication, authorization, and identification, allowing a server
202 operator to make access control decisions. Section 3 of [RFC7481]
203 describes general considerations for RDAP access control,
204 authentication, and authorization.
205
206 The conventional client-server authentication model requires clients
207 to maintain distinct credentials for every RDAP server. This
208 situation can become unwieldy as the number of RDAP servers
209 increases. Federated authentication mechanisms allow clients to use
210 one credential to access multiple RDAP servers and reduce client
211 credential management complexity.
212
213 3.1. RDAP and OpenID Connect
214
215 OpenID Connect 1.0 [OIDCC] is a decentralized, Single Sign-On (SSO)
216 federated authentication system that allows users to access multiple
217 web resources with one identifier instead of having to create
218 multiple server-specific identifiers. Users acquire identifiers from
219 OpenID Providers (OPs). Relying Parties (RPs) are applications (such
220 as RDAP) that outsource their user authentication function to an OP.
221 OpenID Connect is built on top of the authorization framework
222 provided by the OAuth 2.0 protocol [RFC6749].
223
224 The OAuth authorization framework describes a method for users to
225 access protected web resources without having to hand out their
226 credentials. Instead, clients are issued access tokens by OPs with
227 the permission of the resource owners. Using OpenID Connect and
228 OAuth, multiple RDAP servers can form a federation, and clients can
229 access any server in the federation by providing one credential
230 registered with any OP in that federation. The OAuth authorization
231 framework is designed for use with HTTP and thus can be used with
232 RDAP.
233
234 3.1.1. Terminology
235
236 This document uses the following terminology.
237
238 Terms defined by [RFC7480]:
239
240 * client
241
242 * server
243
244 Terms defined by [RFC6749]:
245
246 * access token
247
248 * authorization code
249
250 * authorization endpoint
251
252 * authorization grant
253
254 * client authentication
255
256 * client identifier
257
258 * protected resource
259
260 * refresh token
261
262 * resource owner
263
264 * resource server
265
266 * token endpoint
267
268 Terms defined by [RFC7519]:
269
270 * claim name
271
272 * claim value
273
274 * JSON Web Token (JWT)
275
276 Terms defined by [OIDCC]:
277
278 * ID Token
279
280 * UserInfo Endpoint
281
282 Term defined by [RFC9068]:
283
284 * JWT access token
285
286 Additional terms from Section 1.2 of the OpenID Connect Core
287 specification are incorporated by reference.
288
289 This document uses the terms "remote" and "default" to describe the
290 relationship between an RDAP server and the OPs that it interacts
291 with. A "remote" OP is one that is identified by the RDAP client by
292 providing either an Issuer Identifier or an end-user identifier in a
293 login request. Whether an Issuer Identifier or end-user identifier
294 can be provided in the login request for the purposes of selecting an
295 OP can be determined by retrieving the RDAP server's OIDC
296 configuration details (see Section 4.1). A "default" OP is one that
297 the RDAP server will use when the RDAP client does not provide an
298 Issuer Identifier or an end-user identifier in the login request.
299
300 This document uses the term "session" to describe a set of
301 interactions between an RDAP client and an RDAP server during a given
302 period of time. For session-oriented clients (see Section 3.1.2),
303 the RDAP session is a typical HTTP session starting with a
304 farv1_session/login request and ending with either a farv1_session/
305 logout request (see Section 5 for a description of both path
306 segments) or a timeout. For token-oriented clients (see Sections
307 3.1.2 and 6), the RDAP session corresponds to the lifespan of an
308 authorization obtained from an OP and the corresponding access token,
309 including any refreshed access tokens.
310
311 3.1.2. Client Considerations
312
313 Clients that delegate OIDC authentication to an RDAP server as part
314 of session-oriented interactions and can accept and process HTTP
315 cookies [RFC6265] to maintain the session are known as "session-
316 oriented" clients. This type of RDAP client performs the role of a
317 user agent [RFC9110]. An RDAP server performs the role of an OpenID
318 Connect Core Relying Party (RP). A web browser used to send queries
319 directly to an RDAP server is an example of a session-oriented
320 client. Specifications for this type of client can be found in
321 Section 5.
322
323 Clients that perform OIDC authentication directly, taking the role of
324 an RP in interactions with an OP and sending access tokens [RFC6749]
325 to an RDAP server to authorize RDAP queries, are known as "token-
326 oriented" clients. An RDAP server performs resource server [RFC6749]
327 functions to verify the tokens received from the client and RP
328 functions to retrieve information from the OP as necessary to make
329 access control decisions. A web browser running JavaScript received
330 from a web service that sends queries to an RDAP server directly or
331 through its back-end web service is an example of a token-oriented
332 client. Specifications for this type of client can be found in
333 Section 6.
334
335 Clients MAY operate as either session-oriented or token-oriented
336 clients, but they MUST do so consistently by not mixing token-
337 oriented and session-oriented requests while interacting with an OP.
338 Servers SHOULD support both types of client to maximize
339 interoperability but MAY choose to support only one type of client as
340 required by local policy or operating conditions. A server that does
341 not support a particular client type will not support the protocol
342 features (the data structures, path segments, parameters, and
343 interactions) specified for that client type. Server signaling of
344 supported client types is described in Section 4.1.
345
346 3.1.3. Overview
347
348 At a high level, RDAP authentication of a session-oriented client
349 using OpenID Connect requires completion of the following steps:
350
351 1. An RDAP client sends an RDAP "help" query to an RDAP server to
352 determine the types and capabilities of the OPs that are used by
353 the RDAP server. This information is returned in the
354 "rdapConformance" section of the response. A value of "farv1"
355 indicates support for the extension described in this
356 specification. If one or more remote OPs are supported, the
357 RDAP client SHOULD evaluate the additional information described
358 in Section 4.1 in order to discover the capabilities of the RDAP
359 server and optionally obtain the set of supported OPs unless
360 that information is available from a trusted out-of-band source
361 and has already been processed.
362
363 2. An RDAP client sends an RDAP "login" request to an RDAP server
364 as described in Section 5.2.
365
366 3. The RDAP server prepares an Authentication Request containing
367 the desired request parameters.
368
369 4. The RDAP server sends an Authentication Request to an OP
370 authorization endpoint and redirects the RDAP client to the OP
371 using an HTTP redirect.
372
373 5. The OP authenticates the end user.
374
375 6. The OP obtains end-user consent and authorization.
376
377 7. The OP sends the RDAP client back to the RDAP server with an
378 authorization code using an HTTP redirect.
379
380 8. The RDAP server requests tokens using the authorization code at
381 the OP's token endpoint.
382
383 9. The RDAP server receives a response that contains an ID Token
384 and access token in the response body.
385
386 10. The RDAP server validates the tokens as described in [OIDCC] and
387 retrieves the claims associated with the end user's identity
388 from the OP's UserInfo Endpoint.
389
390 The steps above can be described in a sequence diagram:
391
392 End OpenID RDAP RDAP
393 User Provider Client Server
394 | | | |
395 | | |-----Help Query---->|
396 | | | |
397 | | |<---Help Response---|
398 | | | |
399 |-------Login Request------>| |
400 | | | |
401 | | |---Login Request--->|
402 | | | |
403 | |<-----Authentication Request------|
404 | | | |
405 | Credential--| | |
406 |<--Request | | |
407 | | | |
408 |--Credential | | |
409 | Response->| | |
410 | | | |
411 | |-----Authentication Response----->|
412 | | | |
413 | |<----------Token Request----------|
414 | | | |
415 | |-----------Token Response-------->|
416 | | | |
417 | |<----------Claim Request----------|
418 | | | |
419 | |-----------Claim Response-------->|
420 | | | |
421 | | |<--Login Response---|
422 | | | |
423 |<------Login Response------| |
424 | | | |
425 |----------RDAP Query------>| |
426 | | | |
427 | | |-----RDAP Query---->|
428 | | | |
429 | | |<---RDAP Response---|
430 | | | |
431 |<------RDAP Response-------| |
432
433 Figure 1
434
435 The RDAP server can then make identification, authorization, and
436 access control decisions based on end-user identity information and
437 local policies. Note that OpenID Connect describes different process
438 flows for other types of clients, such as script-based or command-
439 line clients.
440
441 RDAP authentication of a token-oriented client using OpenID Connect
442 requires completion of the following steps:
443
444 1. An RDAP client sends an RDAP "help" query to an RDAP server to
445 determine the type and capabilities of the OPs that are used by
446 the RDAP server. This information is returned in the
447 "rdapConformance" section of the response. A value of "farv1"
448 indicates support for the extension described in this
449 specification. If one or more remote OPs are supported, the
450 RDAP client SHOULD evaluate the additional information described
451 in Section 4.1 in order to discover the capabilities of the RDAP
452 server and optionally obtain the set of supported OPs. Support
453 for token-oriented clients requires a default OP.
454
455 2. The RDAP client determines the end user's OP and confirms that
456 it's supported by the RDAP server.
457
458 3. The RDAP client sends an Authentication Request to the OP's
459 authorization endpoint.
460
461 4. The OP authenticates the end user.
462
463 5. The OP obtains end-user consent or authorization.
464
465 6. The OP returns an authorization code to the RDAP client.
466
467 7. The RDAP client requests tokens using the authorization code at
468 the OP's token endpoint.
469
470 8. The RDAP client receives a response that contains an ID Token
471 and an access token in the response body.
472
473 9. The RDAP client monitors the token validity period and either
474 refreshes the token or requests new tokens as necessary.
475
476 10. The RDAP client sends queries that require user identification,
477 authentication, and authorization to an RDAP server that include
478 an access token in an HTTP "authorization" header using the
479 "bearer" authentication scheme described in [RFC6750].
480
481 11. The RDAP server validates the access token and retrieves the
482 claims associated with the end user's identity from the OP's
483 UserInfo Endpoint.
484
485 12. The RDAP server determines the end user's authorization level
486 and processes the query in accordance with server policies.
487
488 The steps above can be described in a sequence diagram:
489
490 End OpenID RDAP RDAP
491 User Provider Client Server
492 | | | |
493 | | |-----Help Query---->|
494 | | | |
495 | | |<----Help Response--|
496 | | | |
497 |-------Login Request------>| |
498 | | | |
499 | |<-Authentication |
500 | | Request---| |
501 | | | |
502 |<-Credential | | |
503 | Request---| | |
504 | | | |
505 |--Credential | | |
506 | Response->| | |
507 | | | |
508 | |--Authentication |
509 | | Response--->| |
510 | | | |
511 | |<-Token | |
512 | | Request----| |
513 | | | |
514 | |--Token | |
515 | | Response-->| |
516 | | | |
517 |<------Login Response------| |
518 | | | |
519 |-----RDAP Query----------->| |
520 | | | |
521 | | |----RDAP Query----->|
522 | | | |
523 | |<------------Claim |
524 | | Request---------------|
525 | | | |
526 | |-------------Claim |
527 | | Response------------->|
528 | | | |
529 | | |<---RDAP Response---|
530 | | | |
531 |<----RDAP Response---------| |
532
533 Figure 2
534
535 3.1.4. RDAP Authentication and Authorization Steps
536
537 End users MAY present an identifier (an OpenID) issued by an OP to
538 use OpenID Connect with RDAP. If the RDAP server supports a default
539 OP or if provider discovery is not supported, the end-user identifier
540 MAY be omitted. An OP SHOULD include support for the claims
541 described in Section 3.1.5 to provide additional information needed
542 for RDAP end-user authorization; in the absence of these claims,
543 clients and servers MAY make authorization and access control
544 decisions as appropriate given any other information returned from
545 the OP. OpenID Connect requires RPs to register with OPs to use
546 OpenID Connect services for an end user. The registration process is
547 often completed using out-of-band methods, but it is also possible to
548 use the automated method described by the OpenID Connect Dynamic
549 Client Registration protocol [OIDCR]. The parties involved can use
550 any method that is mutually acceptable.
551
552 3.1.4.1. Provider Discovery
553
554 An RDAP server acting as an RP needs to be able to map an end user's
555 identifier to an OP. This can be accomplished using the OPTIONAL
556 OpenID Connect Discovery protocol [OIDCD], but that protocol is not
557 widely implemented. Out-of-band methods are also possible and can be
558 more dependable. For example, an RP can support a limited number of
559 OPs and maintain internal associations of those identifiers with the
560 OPs that issued them.
561
562 Alternatively, if mapping an end user's identifier is not possible,
563 or not supported by the RDAP server, the RDAP server SHOULD support
564 explicit specification of a remote OP by the RDAP client in the form
565 of a query parameter as described in Section 5.2.2 unless the remote
566 OP has been identified using an out-of-band mechanism. An RDAP
567 server MUST provide information about its capabilities and supported
568 OPs in the "help" query response in the "farv1_openidcConfiguration"
569 data structure described in Section 4.1. An RDAP server acting as an
570 RP MUST support at least one of these methods of OP discovery.
571
572 3.1.4.2. Authentication Request
573
574 Once the OP is known, an RP MUST form an Authentication Request and
575 send it to the OP as described in Section 3 of [OIDCC]. The
576 authentication path followed (authorization, implicit, or hybrid)
577 will depend on the Authentication Request response_type set by the
578 RP. The remainder of the processing steps described here assume that
579 the authorization code flow is being used by setting
580 "response_type=code" in the Authentication Request.
581
582 The benefits of using the authorization code flow for authenticating
583 a human user are described in Section 3.1 of [OIDCC]. The Implicit
584 Flow is more commonly used by clients implemented in a web browser
585 using a scripting language; it is described in Section 3.2 of
586 [OIDCC]. At the time of this writing, the Implicit Flow is
587 considered insecure and efforts are being made to deprecate the flow.
588 The Hybrid Flow (described in Section 3.3 of [OIDCC]) combines
589 elements of the authorization code and Implicit Flows by returning
590 some tokens from the authorization endpoint and others from the token
591 endpoint.
592
593 An Authentication Request can contain several parameters. REQUIRED
594 parameters are specified in Section 3.1.2.1 of [OIDCC]. Apart from
595 these parameters, it is RECOMMENDED that the RP include the optional
596 "login_hint" parameter in the request, with the value being that of
597 the "farv1_id" query parameter of the end user's RDAP "login"
598 request, if provided. Passing the "login_hint" parameter allows a
599 client to pre-fill login form information, so logging in can be more
600 convenient for users. Other parameters MAY be included.
601
602 The OP receives the Authentication Request and attempts to validate
603 it as described in Section 3.1.2.2 of [OIDCC]. If the request is
604 valid, the OP attempts to authenticate the end user as described in
605 Section 3.1.2.3 of [OIDCC]. The OP returns an error response if the
606 request is not valid or if any error is encountered.
607
608 3.1.4.3. End User Authorization
609
610 After the end user is authenticated, the OP MUST obtain consent from
611 the end user to release authorization information to the RDAP server
612 acting as an RP. This process is described in Section 3.1.2.4 of
613 [OIDCC].
614
615 3.1.4.4. Authorization Response and Validation
616
617 After obtaining an authorization result, the OP will send a response
618 to the RP that provides the result of the authorization process using
619 an authorization code. The RP MUST validate the response. This
620 process is described in Sections 3.1.2.5 - 3.1.2.7 of [OIDCC].
621
622 3.1.4.5. Token Processing
623
624 The RP sends a token request using the authorization grant to a token
625 endpoint to obtain a token response containing an access token, ID
626 Token, and an OPTIONAL refresh token. The RP MUST validate the token
627 response. This process is described in Section 3.1.3.5 [OIDCC].
628
629 3.1.4.6. Delivery of User Information
630
631 The set of claims can be retrieved by sending a request to a UserInfo
632 Endpoint using the access token. The claims are returned in the ID
633 Token. The process of retrieving claims from a UserInfo Endpoint is
634 described in Section 5.3 of [OIDCC].
635
636 OpenID Connect specifies a set of standard claims in Section 5.1 of
637 [OIDCC]. Additional claims for RDAP are described in Section 3.1.5.
638
639 3.1.5. Specialized Claims and Authorization Scope for RDAP
640
641 OpenID Connect claims are pieces of information used to make
642 assertions about an entity. Section 5 of [OIDCC] describes a set of
643 standard claims. Section 5.1.2 of [OIDCC] notes that additional
644 claims MAY be used, and it describes a method to create them. The
645 set of claims that are specific to RDAP are associated with an OAuth
646 scope request parameter value (see Section 3.3 of [RFC6749]) of
647 "rdap".
648
649 3.1.5.1. Stated Purposes
650
651 Communities of RDAP users and operators may wish to make and validate
652 claims about a user's "need to know" when it comes to requesting
653 access to a protected resource. For example, a law enforcement agent
654 or a trademark attorney may wish to be able to assert that they have
655 a legal right to access a protected resource, and a server operator
656 may need to be able to receive and validate that claim. These needs
657 can be met by defining and using an additional
658 "rdap_allowed_purposes" claim.
659
660 The "rdap_allowed_purposes" claim identifies the purposes for which
661 access to a protected resource can be requested by an end user. Use
662 of the "rdap_allowed_purposes" claim is OPTIONAL; processing of this
663 claim is subject to server acceptance of the purposes, the trust
664 level assigned to this claim by the server, and successful
665 authentication of the end user. Unrecognized purpose values MUST be
666 ignored, and the associated query MUST be processed as if the
667 unrecognized purpose value was not present at all. See Section 9.3
668 for a description of the IANA considerations associated with this
669 claim.
670
671 The "rdap_allowed_purposes" claim is represented as an array of case-
672 sensitive StringOrURI values as specified in Section 2 of [RFC7519].
673 An example:
674
675 "rdap_allowed_purposes": ["domainNameControl","dnsTransparency"]
676
677 Purpose values are assigned to an end user's credential by an
678 identity provider. Identity providers MUST ensure that appropriate
679 purpose values are only assigned to end user identities that are
680 authorized to use them.
681
682 3.1.5.2. Do Not Track
683
684 Communities of RDAP users and operators may wish to make and validate
685 claims about a user's wish to not have their queries logged, tracked,
686 or recorded. For example, a law enforcement agent may wish to assert
687 that their queries are part of a criminal investigation and should
688 not be tracked due to a risk of query exposure compromising the
689 investigation, and a server operator may need to be able to receive
690 and validate that claim. These needs can be met by defining and
691 using an additional "do not track" claim.
692
693 The "do not track" ("rdap_dnt_allowed") claim can be used to identify
694 an end user that is authorized to perform queries without the end
695 user's association with those queries being logged, tracked, or
696 recorded by the server. Client use of the "rdap_dnt_allowed" claim
697 is OPTIONAL. Server operators MUST NOT log, track, or record any
698 association of the query and the end user's identity if the end user
699 is successfully identified and authorized, if the "rdap_dnt_allowed"
700 claim is present, if the value of the claim is "true", and if
701 accepting the claim complies with local regulations regarding logging
702 and tracking.
703
704 The "rdap_dnt_allowed" value is represented as a JSON boolean
705 literal. An example:
706
707 rdap_dnt_allowed: true
708
709 No special query tracking processing is required if this claim is not
710 present or if the value of the claim is "false". Use of this claim
711 MUST be limited to end users who are granted "do not track"
712 privileges in accordance with service policies and regulations.
713 Specification of these policies and regulations is beyond the scope
714 of this document.
715
716 4. Common Protocol Features
717
718 As described in Section 3.1.4.1, an RDAP server MUST provide
719 information about its capabilities and supported OPs in a "help"
720 query response. This specification describes a new
721 "farv1_openidcConfiguration" data structure that describes the OpenID
722 Connect configuration and related extension features supported by the
723 RDAP server. This data structure is returned to all client types.
724
725 4.1. OpenID Connect Configuration
726
727 The "farv1_openidcConfiguration" data structure is an object with the
728 following members:
729
730 "sessionClientSupported": (REQUIRED) a boolean value that describes
731 RDAP server support for session-oriented clients (see
732 Section 3.1.2).
733
734 "tokenClientSupported": (REQUIRED) a boolean value that describes
735 RDAP server support for token-oriented clients (see
736 Section 3.1.2).
737
738 "dntSupported": (REQUIRED) a boolean value that describes RDAP
739 server support for the "farv1_dnt" query parameter (see
740 Section 4.2.2).
741
742 "providerDiscoverySupported": (OPTIONAL) a boolean value that
743 describes RDAP server support for discovery of providers of end-
744 user identifiers. The default value is "true".
745
746 "issuerIdentifierSupported": (OPTIONAL) a boolean value that
747 describes RDAP server support for explicit client specification of
748 an Issuer Identifier. The default value is "true".
749
750 "implicitTokenRefreshSupported": (OPTIONAL) a boolean value that
751 describes RDAP server support for implicit token refresh. The
752 default value is "false".
753
754 "openidcProviders": (OPTIONAL) a list of objects with the following
755 members that describes the set of OPs that are supported by the
756 RDAP server. This data is RECOMMENDED if the value of
757 issuerIdentifierSupported is "true":
758
759 "iss": (REQUIRED) a URI value that represents the Issuer
760 Identifier of the OP as per the OpenID Connect Core
761 specification [OIDCC].
762
763 "name": (REQUIRED) a string value representing the human-friendly
764 name of the OP.
765
766 "default": (OPTIONAL) a boolean value that describes RDAP server
767 support for an OPTIONAL default OP that will be used when a
768 client omits the "farv1_id" and "farv1_iss" query parameters
769 from a "farv1_session/login" request. Only one member of this
770 set can be identified as the default OP by setting a value of
771 "true". The default value is "false".
772
773 "additionalAuthorizationQueryParams": (OPTIONAL) an object where
774 each member represents an OAuth authorization request parameter
775 name-value pair supported by the OP. The name represents an
776 OAuth query parameter, and the value is the query parameter
777 value. A token-oriented RDAP client SHOULD add these query
778 parameters and their corresponding values to the Authentication
779 Request URL when requesting authorization by a specified OP
780 through a proxy OP.
781
782 An RDAP server MUST set either the "sessionClientSupported" or the
783 "tokenClientSupported" value to "true". Both values MAY be set to
784 "true" if an RDAP server supports both types of clients.
785
786 The "providerDiscoverySupported" value has a direct impact on the use
787 of the "farv1_id" query parameter described in Sections 3.1.4.2 and
788 5.2.1. The value of "providerDiscoverySupported" MUST be "true" for
789 an RDAP server to properly accept and process "farv1_id" query
790 parameters. Similarly, the "issuerIdentifierSupported" value has a
791 direct impact on the use of the "farv1_iss" query parameter described
792 in Section 5.2.2. The value of "issuerIdentifierSupported" MUST be
793 "true" for an RDAP server to properly accept and process "farv1_iss"
794 query parameters.
795
796 An example of a "farv1_openidcConfiguration" data structure:
797
798 "farv1_openidcConfiguration": {
799 "sessionClientSupported": true,
800 "tokenClientSupported": true,
801 "dntSupported": false,
802 "providerDiscoverySupported": true,
803 "issuerIdentifierSupported": true,
804 "openidcProviders":
805 [
806 {
807 "iss": "https://idp.example.com",
808 "name": "Example IDP"
809 },
810 {
811 "iss": "https://accounts.example.net",
812 "name": "Login with EXAMPLE",
813 "additionalAuthorizationQueryParams": {
814 "kc_idp_hint": "examplePublicIDP"
815 }
816 },
817 {
818 "iss": "https://auth.nic.example/auth/realms/rdap",
819 "name": "Default OP for the Example RDAP server",
820 "default": true
821 }
822 ]
823 }
824
825 Figure 3
826
827 4.2. RDAP Query Parameters
828
829 This specification describes two OPTIONAL query parameters for use
830 with RDAP queries that request access to information associated with
831 protected resources:
832
833 "farv1_qp": A query parameter to identify the purpose of the query.
834
835 "farv1_dnt": A query parameter to request that the server not log or
836 otherwise record information about the identity associated with a
837 query.
838
839 One or both parameters MAY be added to an RDAP request URI using the
840 syntax described in Section "application/x-www-form-urlencoded" of
841 [HTMLURL].
842
843 4.2.1. RDAP Query Purpose
844
845 This query is represented as a "key=value" pair using a key value of
846 "farv1_qp" and a value component that contains a single query purpose
847 string from the set of allowed purposes associated with the end
848 user's identity (see Section 3.1.5.1). If present, the server SHOULD
849 compare the value of the parameter to the "rdap_allowed_purposes"
850 claim values associated with the end user's identity and ensure that
851 the requested purpose is present in the set of allowed purposes. The
852 RDAP server MAY choose to ignore both the requested purpose and the
853 "rdap_allowed_purposes" claim values if they are inconsistent with
854 local server policy. The server MUST return an HTTP 403 (Forbidden)
855 response if the requested purpose is not an allowed purpose. If the
856 "farv1_qp" parameter is not present, the server MUST process the
857 query and make an access control decision based on any other
858 information known to the server about the end user and the
859 information they are requesting. For example, a server MAY treat the
860 request as one performed by an unidentified or unauthenticated user
861 and return either an error or an appropriate subset of the available
862 data. An example domain query using the "farv1_qp" query parameter:
863
864 https://example.com/rdap/domain/example.com?farv1_qp=legalActions
865
866 Figure 4
867
868 4.2.2. RDAP Do Not Track
869
870 This query is represented as a "key=value" pair using a key value of
871 "farv1_dnt" and a value component that contains a single boolean
872 value. A value of "true" indicates that the end user is requesting
873 that their query is not tracked or logged in accordance with server
874 policy. A value of "false" indicates that the end user is accepting
875 that their query can be tracked or logged in accordance with server
876 policy. The server MUST return an HTTP 403 (Forbidden) response if
877 the server is unable to perform the action requested by this query
878 parameter. An example domain query using the "farv1_dnt" query
879 parameter:
880
881 https://example.com/rdap/domain/example.com?farv1_dnt=true
882
883 Figure 5
884
885 4.2.3. Parameter Processing
886
887 Unrecognized query parameters MUST be ignored. An RDAP server that
888 processes an authenticated query MUST determine if the end-user
889 identification information is associated with an OP that is
890 recognized and supported by the server. RDAP servers MUST reject
891 queries that include identification information that is not
892 associated with a supported OP by returning an HTTP 400 (Bad Request)
893 response. An RDAP server that receives a query containing
894 identification information associated with a recognized OP MUST
895 perform the steps required to authenticate the user with the OP,
896 process the query, and return an RDAP response that is appropriate
897 for the end user's level of authorization and access.
898
899 5. Protocol Features for Session-Oriented Clients
900
901 This specification adds the following features to RDAP that are
902 commonly used by session-oriented clients:
903
904 1. Data structures to return information that describes an
905 established session and the information needed to establish a
906 session for a UI-constrained device.
907
908 2. A query parameter to request authentication for a specific end-
909 user identity.
910
911 3. A query parameter to support authentication for a specific end-
912 user identity on a device with a constrained user interface.
913
914 4. A query parameter to identify the purpose of the query.
915
916 5. A query parameter to request that the server not log or otherwise
917 record information about the identity associated with a query.
918
919 6. Path segments to start, stop, refresh, and determine the status
920 of an authenticated session for a specific end-user identity.
921
922 5.1. Data Structures
923
924 This specification describes two new data structures that are used to
925 return information to a session-oriented client:
926
927 "farv1_session": A data structure that contains information that
928 describes an established session.
929
930 "farv1_deviceInfo": A data structure that contains information that
931 describes an active attempt to establish a session on a UI-
932 constrained device.
933
934 5.1.1. Session
935
936 The "farv1_session" data structure is an object that contains the
937 following members:
938
939 "userID": an OPTIONAL string value that represents the end-user
940 identifier associated with the session.
941
942 "iss": an OPTIONAL URI value that represents the issuer of the end-
943 user identifier associated with the session.
944
945 "userClaims": an OPTIONAL object that contains the set of claims
946 associated with the end user's identity based on the user
947 information provided by the OP as described in Section 3.1.4.6 and
948 processed by the RDAP server in the authentication and
949 authorization process. The set of possible values is determined
950 by OP policy and RDAP server policy.
951
952 "sessionInfo": an OPTIONAL object that contains two members:
953
954 "tokenExpiration": an integer value that represents the number of
955 seconds that remain in the lifetime of the access token.
956
957 "tokenRefresh": a boolean value that indicates if the OP supports
958 refresh tokens. As described in [RFC6749], support for refresh
959 tokens is OPTIONAL.
960
961 Note that all of the members of the "farv1_session" data structure
962 are OPTIONAL. See Section 5.2.3 for instructions describing when to
963 return the minimum set of members.
964
965 An example of a "farv1_session" data structure:
966
967 "farv1_session": {
968 "userID": "user.idp.example",
969 "iss": "https://idp.example.com",
970 "userClaims": {
971 "sub": "103892603076825016132",
972 "name": "User Person",
973 "given_name": "User",
974 "family_name": "Person",
975 "picture": "https://lh3.example.com/a-/AOh14=s96-c",
976 "email": "user@example.com",
977 "email_verified": true,
978 "locale": "en",
979 "rdap_allowed_purposes": [
980 "domainNameControl",
981 "personalDataProtection"
982 ],
983 "rdap_dnt_allowed": false
984 },
985 "sessionInfo": {
986 "tokenExpiration": 3599,
987 "tokenRefresh": true
988 }
989 }
990
991 Figure 6
992
993 5.1.2. Device Info
994
995 The flow described in Section 3.1.4 requires an end user to interact
996 with a server using a user interface that can process HTTP. This
997 will not work well in situations where the client is automated or an
998 end user is using a command-line user interface such as curl
999 (https://curl.se/) or wget (https://www.gnu.org/software/wget/).
1000 This limitation can be addressed using a web browser on a second
1001 device. The information that needs to be entered using the web
1002 browser is contained in the "farv1_deviceInfo" data structure, an
1003 object that contains members as described in Section 3.2 of
1004 [RFC8628].
1005
1006 An example of a "farv1_deviceInfo" data structure:
1007
1008 "farv1_deviceInfo": {
1009 "device_code": "AH-1ng2ezu",
1010 "user_code": "NJJQ-GJFC",
1011 "verification_uri": "https://www.example.com/device",
1012 "verification_uri_complete":
1013 "https://www.example.com/device?user_code=NJJQ-GJFC",
1014 "expires_in": 1800,
1015 "interval": 5
1016 }
1017
1018 Figure 7
1019
1020 5.2. Client Login
1021
1022 Client authentication is requested by sending a "farv1_session/login"
1023 request to an RDAP server. If the RDAP server supports only remote
1024 OPs, the "farv1_session/login" request MUST include at least one end-
1025 user identifier or OP Issuer Identifier.
1026
1027 The server sets an HTTP cookie as described in [RFC6265] when the
1028 "farv1_session/login" request is received and processed successfully.
1029 The client MUST include the session cookie received from the server
1030 in any RDAP request within the scope of that session, including
1031 "farv1_session/refresh", "farv1_session/status", and "farv1_session/
1032 logout". A "farv1_session/login" followed by another "farv1_session/
1033 login" that does not include an HTTP cookie MUST start a new session
1034 on the server that includes a new cookie. A server that receives a
1035 "farv1_session/login" followed by another "farv1_session/login" that
1036 includes an HTTP cookie MUST return an HTTP 409 (Conflict) response.
1037
1038 To help reduce the risk of resource starvation, a server MAY reject a
1039 "farv1_session/login" request and refuse to start a new session by
1040 returning an HTTP 409 (Conflict) response if a server-side maximum
1041 number of concurrent sessions per user exists and the client exceeds
1042 that limit. Additionally, an active session MAY be removed by the
1043 server due to timeout expiration or because a maximum session
1044 lifetime has been exceeded. Clients SHOULD proactively monitor the
1045 "tokenExpiration" value associated with an active session and refresh
1046 the session as appropriate to provide a positive user experience.
1047
1048 5.2.1. End-User Identifier
1049
1050 The end-user identifier is delivered using one of two methods: by
1051 adding a query component to an RDAP request URI using the syntax
1052 described in Section "application/x-www-form-urlencoded" of [HTMLURL]
1053 or by including an HTTP "authorization" request header for the Basic
1054 authentication scheme as described in [RFC7617]. Clients can use
1055 either of these methods to deliver the end-user identifier to a
1056 server that supports remote OPs and provider discovery. Servers that
1057 support remote OPs and provider discovery MUST accept both methods.
1058 If the RDAP server supports a default OP or if provider discovery is
1059 not supported, the end-user identifier MAY be omitted.
1060
1061 The query parameter used to deliver the end-user identifier is
1062 represented as an OPTIONAL "key=value" pair using a key value of
1063 "farv1_id" and a value component that contains the client identifier
1064 issued by an OP. An example for client identifier
1065 "user.idp.example":
1066
1067 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1068 https://example.com/rdap/farv1_session/\
1069 login?farv1_id=user.idp.example
1070
1071 Figure 8
1072
1073 The authorization header for the Basic authentication scheme contains
1074 a base64-encoded representation of the client identifier issued by an
1075 OP. No password is provided. An example for client identifier
1076 "user.idp.example":
1077
1078 https://example.com/rdap/farv1_session/login
1079 Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==
1080
1081 Figure 9
1082
1083 An example for use with a default OP:
1084
1085 https://example.com/rdap/farv1_session/login
1086
1087 Figure 10
1088
1089 5.2.2. OP Issuer Identifier
1090
1091 The OP's Issuer Identifier is delivered by adding a query component
1092 to an RDAP request URI using the syntax described in Section
1093 "application/x-www-form-urlencoded" of [HTMLURL]. If the RDAP server
1094 supports a default OP, the Issuer Identifier MAY be omitted.
1095
1096 The query parameter used to deliver the OP's Issuer Identifier is
1097 represented as an OPTIONAL "key=value" pair using a key value of
1098 "farv1_iss" and a value component that contains the Issuer Identifier
1099 associated with an OP. An RDAP server MAY accept Issuer Identifiers
1100 not specified in the "farv1_openidcConfiguration" data structure and
1101 MAY also decide to accept specific Issuer Identifiers only from
1102 specific clients. An example for Issuer Identifier
1103 "https://idp.example.com":
1104
1105 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1106 https://example.com/rdap/farv1_session/\
1107 login?farv1_iss=https://idp.example.com
1108
1109 Figure 11
1110
1111 5.2.3. Login Response
1112
1113 The response to this request MUST be a valid RDAP response per
1114 [RFC9083]. It MUST NOT include any members that relate to a specific
1115 RDAP object type (e.g., "events" or "status"). In addition, the
1116 response MAY include an indication of the requested operation's
1117 success or failure in the "notices" data structure. If successful,
1118 the response MUST include a "farv1_session" data structure that
1119 includes a "sessionInfo" object and an OPTIONAL "userClaims" object.
1120 If unsuccessful, the response MUST include a "farv1_session" data
1121 structure that omits the "userClaims" and "sessionInfo" objects.
1122
1123 An example of a successful "farv1_session/login" response:
1124
1125 {
1126 "rdapConformance": [
1127 "farv1"
1128 ],
1129 "lang": "en-US",
1130 "notices": [
1131 {
1132 "title": "Login Result",
1133 "description": [
1134 "Login succeeded"
1135 ]
1136 }
1137 ],
1138 "farv1_session": {
1139 "userID": "user.idp.example",
1140 "iss": "https://idp.example.com",
1141 "userClaims": {
1142 "sub": "103892603076825016132",
1143 "name": "User Person",
1144 "given_name": "User",
1145 "family_name": "Person",
1146 "picture": "https://lh3.example.com/a-/AOh14=s96-c",
1147 "email": "user@example.com",
1148 "email_verified": true,
1149 "locale": "en",
1150 "rdap_allowed_purposes": [
1151 "domainNameControl",
1152 "personalDataProtection"
1153 ],
1154 "rdap_dnt_allowed": false
1155 },
1156 "sessionInfo": {
1157 "tokenExpiration": 3599,
1158 "tokenRefresh": true
1159 }
1160 }
1161 }
1162
1163 Figure 12
1164
1165 An example of a failed "farv1_session/login" response:
1166
1167 {
1168 "rdapConformance": [
1169 "farv1"
1170 ],
1171 "lang": "en-US",
1172 "notices": [
1173 {
1174 "title": "Login Result",
1175 "description": [
1176 "Login failed"
1177 ]
1178 }
1179 ],
1180 "farv1_session": {
1181 "userID": "user.idp.example",
1182 "iss": "https://idp.example.com"
1183 }
1184 }
1185
1186 Figure 13
1187
1188 5.2.4. Clients with Limited User Interfaces
1189
1190 "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an OPTIONAL
1191 method to request user authorization from devices that have an
1192 Internet connection but lack a suitable browser for a more
1193 conventional OAuth flow. This method requires an end user to use a
1194 second device (such as a smartphone) that has access to a web browser
1195 for entry of a code sequence that is presented on the UI-constrained
1196 device.
1197
1198 5.2.4.1. UI-Constrained Client Login
1199
1200 Client authentication is requested by sending a "farv1_session/
1201 device" request to an RDAP server. If the RDAP server supports only
1202 remote OPs, the "farv1_session/device" request MUST include either an
1203 end-user identifier as described in Section 5.2.1 or an OP Issuer
1204 Identifier as described in Section 5.2.2.
1205
1206 An example using wget for client identifier "user.idp.example":
1207
1208 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1209 wget -qO- "https://example.com/rdap/farv1_session/device\
1210 ?farv1_id=user.idp.example"
1211
1212 Figure 14
1213
1214 The authorization header for the Basic authentication scheme contains
1215 a base64-encoded representation of the client identifier issued by an
1216 OP. No password is provided.
1217
1218 An example using curl and an authorization header:
1219
1220 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1221 curl -H "Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ=="\
1222 "https://example.com/rdap/farv1_session/device"
1223
1224 Figure 15
1225
1226 The response to this request MUST be a valid RDAP response per
1227 [RFC9083]. It MUST NOT include any members that relate to a specific
1228 RDAP object type (e.g., "events" or "status"). In addition, the
1229 response MAY include an indication of the requested operation's
1230 success or failure in the "notices" data structure and, if
1231 successful, a "farv1_deviceInfo" data structure.
1232
1233 An example of a "farv1_session/device" response:
1234
1235 {
1236 "rdapConformance": [
1237 "farv1"
1238 ],
1239 "lang": "en-US",
1240 "notices": [
1241 {
1242 "title": "Device Login Result",
1243 "description": [
1244 "Login succeeded"
1245 ]
1246 }
1247 ],
1248 "farv1_deviceInfo": {
1249 "device_code": "AH-1ng2ezu",
1250 "user_code": "NJJQ-GJFC",
1251 "verification_uri": "https://www.example.com/device",
1252 "verification_uri_complete":
1253 "https://www.example.com/device?user_code=NJJQ-GJFC",
1254 "expires_in": 1800,
1255 "interval": 5
1256 }
1257 }
1258
1259 Figure 16
1260
1261 5.2.4.2. UI-Constrained Client Login Polling
1262
1263 After successful processing of the "farv1_session/device" request,
1264 the client MUST send a "farv1_session/devicepoll" request to the RDAP
1265 server to continue the login process. This request initiates the
1266 polling function described in [RFC8628] on the RDAP server. The RDAP
1267 server polls the OP as described in Section 3.4 of [RFC8628],
1268 allowing the RDAP server to wait for the end user to enter the
1269 information returned from the "farv1_session/device" request using
1270 the interface on their second device. After the end user has
1271 completed that process, or if the process fails or times out, the OP
1272 will respond to the polling requests with an indication of success or
1273 failure. If the RDAP server supports only remote OPs, the
1274 "farv1_session/devicepoll" request MUST include either an end-user
1275 identifier as described in Section 5.2.1 or an OP Issuer Identifier
1276 as described in Section 5.2.2.
1277
1278 The "farv1_session/devicepoll" request MUST also include a "farv1_dc"
1279 query parameter. The query parameter is represented as an OPTIONAL
1280 "key=value" pair using a key value of "farv1_dc" and a value
1281 component that contains the value of the device_code that was
1282 returned in the response to the "farv1_session/device" request.
1283
1284 An example using wget:
1285
1286 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1287 wget -qO- --keep-session-cookies --save-cookies cookie.txt\
1288 "https://example.com/rdap/farv1_session/devicepoll\
1289 ?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"
1290
1291 Figure 17
1292
1293 An example using curl:
1294
1295 ========== NOTE: '\' line wrapping per RFC 8792 ===========
1296 curl -c cookie.txt "https://example.com/rdap/farv1_session/\
1297 devicepoll?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"
1298
1299 Figure 18
1300
1301 The response to this request MUST use the response structures
1302 described in Section 5.2. RDAP query processing can continue
1303 normally on the UI-constrained device once the device polling process
1304 has been completed successfully.
1305
1306 5.3. Session Status
1307
1308 Clients MAY send a query to an RDAP server to determine the status of
1309 an existing login session using a "farv1_session/status" path
1310 segment. An example "farv1_session/status" request:
1311
1312 https://example.com/rdap/farv1_session/status
1313
1314 Figure 19
1315
1316 The response to this request MUST be a valid RDAP response per
1317 [RFC9083]. It MUST NOT include any members that relate to a specific
1318 RDAP object type (e.g., "events" or "status"). In addition, the
1319 response MAY include an indication of the requested operation's
1320 success or failure in the "notices" data structure. If the operation
1321 is successful and an active session exists, the response MUST include
1322 a "farv1_session" data structure that includes a "sessionInfo" object
1323 and an OPTIONAL "userClaims" object. If the operation is
1324 unsuccessful or if no active session exists, the response MUST NOT
1325 include a "farv1_session" object.
1326
1327 An example of a "farv1_session/status" response for an active
1328 session:
1329
1330 {
1331 "rdapConformance": [
1332 "farv1"
1333 ],
1334 "lang": "en-US",
1335 "notices": [
1336 {
1337 "title": "Session Status Result",
1338 "description": [
1339 "Session status succeeded"
1340 ]
1341 }
1342 ],
1343 "farv1_session": {
1344 "userID": "user.idp.example",
1345 "iss": "https://idp.example.com",
1346 "userClaims": {
1347 "sub": "103892603076825016132",
1348 "name": "User Person",
1349 "given_name": "User",
1350 "family_name": "Person",
1351 "picture": "https://lh3.example.com/a-/AOh14=s96-c",
1352 "email": "user@example.com",
1353 "email_verified": true,
1354 "locale": "en",
1355 "rdap_allowed_purposes": [
1356 "domainNameControl",
1357 "personalDataProtection"
1358 ],
1359 "rdap_dnt_allowed": false
1360 },
1361 "sessionInfo": {
1362 "tokenExpiration": 3490,
1363 "tokenRefresh": true
1364 }
1365 }
1366 }
1367
1368 Figure 20
1369
1370 If the operation is successful and an active session does not exist,
1371 the response MAY note the lack of an active session in the "notices"
1372 data structure. The "farv1_session" data structure MUST be omitted.
1373
1374 An example of a "farv1_session/status" response with no active
1375 session:
1376
1377 {
1378 "rdapConformance": [
1379 "farv1"
1380 ],
1381 "lang": "en-US",
1382 "notices": [
1383 {
1384 "title": "Session Status Result",
1385 "description": [
1386 "Session status succeeded",
1387 "No active session"
1388 ]
1389 }
1390 ]
1391 }
1392
1393 Figure 21
1394
1395 5.4. Session Refresh
1396
1397 Clients MAY send a request to an RDAP server to refresh or extend an
1398 existing login session using a "farv1_session/refresh" path segment.
1399 The RDAP server MAY attempt to refresh the access token associated
1400 with the current session as part of extending the session for a
1401 period of time determined by the RDAP server. As described in
1402 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP server
1403 MUST determine if the OP supports token refresh and process the
1404 refresh request by either requesting refresh of the access token or
1405 returning a response that indicates that token refresh is not
1406 supported by the OP in the "notices" data structure. An example
1407 "farv1_session/refresh" request:
1408
1409 https://example.com/rdap/farv1_session/refresh
1410
1411 Figure 22
1412
1413 The response to this request MUST be a valid RDAP response per
1414 [RFC9083]. It MUST NOT include any members that relate to a specific
1415 RDAP object type (e.g., "events" or "status"). In addition, the
1416 response MAY include an indication of the requested operation's
1417 success or failure in the "notices" data structure. The response
1418 MUST include a "farv1_session" data structure that includes a
1419 "sessionInfo" object and an OPTIONAL "userClaims" object. If
1420 unsuccessful but an active session exists, the response MUST include
1421 a "farv1_session" data structure that includes a "sessionInfo" object
1422 and an OPTIONAL "userClaims" object. If unsuccessful and no active
1423 session exists, the response MUST omit the "farv1_session" data
1424 structure.
1425
1426 An example of a successful "farv1_session/refresh" response:
1427
1428 {
1429 "rdapConformance": [
1430 "farv1"
1431 ],
1432 "lang": "en-US",
1433 "notices": [
1434 {
1435 "title": "Session Refresh Result",
1436 "description": [
1437 "Session refresh succeeded",
1438 "Token refresh succeeded."
1439 ]
1440 }
1441 ],
1442 "farv1_session": {
1443 "userID": "user.idp.example",
1444 "iss": "https://idp.example.com",
1445 "userClaims": {
1446 "sub": "103892603076825016132",
1447 "name": "User Person",
1448 "given_name": "User",
1449 "family_name": "Person",
1450 "picture": "https://lh3.example.com/a-/AOh14=s96-c",
1451 "email": "user@example.com",
1452 "email_verified": true,
1453 "locale": "en",
1454 "rdap_allowed_purposes": [
1455 "domainNameControl",
1456 "personalDataProtection"
1457 ],
1458 "rdap_dnt_allowed": false
1459 },
1460 "sessionInfo": {
1461 "tokenExpiration": 3599,
1462 "tokenRefresh": true
1463 }
1464 }
1465 }
1466
1467 Figure 23
1468
1469 Alternatively, an RDAP server MAY attempt to refresh an access token
1470 upon receipt of a query if the access token associated with an
1471 existing session has expired and the corresponding OP supports token
1472 refresh. The default RDAP server behavior is described in the
1473 "implicitTokenRefreshSupported" value that's included in the
1474 "farv1_openidcConfiguration" data structure (see Section 4.1).
1475
1476 If the value of "implicitTokenRefreshSupported" is "true", the client
1477 MAY either explicitly attempt to refresh the session using the
1478 "farv1_session/refresh" query or depend on the RDAP server to attempt
1479 to refresh the session as necessary when an RDAP query is received by
1480 the server. In this case, a server MUST attempt to refresh the
1481 access token upon receipt of a query if the access token associated
1482 with an existing session has expired and the corresponding OP
1483 supports token refresh. Servers MUST return an HTTP 401
1484 (Unauthorized) response to a query if an attempt to implicitly
1485 refresh an existing session fails.
1486
1487 If the value of "implicitTokenRefreshSupported" is "false", the
1488 client MUST explicitly attempt to refresh the session using the
1489 "farv1_session/refresh" query to extend an existing session. If a
1490 session cannot be extended for any reason, the client MUST establish
1491 a new session to continue authenticated query processing by
1492 submitting a "farv1_session/login" query. If the OP does not support
1493 token refresh, the client MUST submit a new "farv1_session/login"
1494 request to establish a new session once an access token has expired.
1495
1496 Clients SHOULD NOT send a "farv1_session/refresh" request in the
1497 absence of an active login session because the request conflicts with
1498 the current state of the server. Servers MUST return an HTTP 409
1499 (Conflict) response if a "farv1_session/refresh" request is received
1500 in the absence of a session cookie.
1501
1502 5.5. Client Logout
1503
1504 Clients MAY send a request to an RDAP server to terminate an existing
1505 login session. Termination of a session is requested using a
1506 "farv1_session/logout" path segment. Access and refresh tokens can
1507 be revoked during the "farv1_session/logout" process as described in
1508 [RFC7009] if supported by the OP (token revocation endpoint support
1509 is OPTIONAL per [RFC8414]). If supported, this feature SHOULD be
1510 used to ensure that the tokens are not mistakenly associated with a
1511 future RDAP session. Alternatively, an RDAP server MAY attempt to
1512 log out from the OP using the OpenID Connect RP-Initiated Logout
1513 protocol [OIDCL] if that protocol is supported by the OP. In any
1514 case, to prevent abuse before the cookie times out, an RDAP server
1515 SHOULD invalidate the HTTP cookie associated with the session as part
1516 of terminating the session.
1517
1518 An example "farv1_session/logout" request:
1519
1520 https://example.com/rdap/farv1_session/logout
1521
1522 Figure 24
1523
1524 The response to this request MUST be a valid RDAP response per
1525 [RFC9083]. It MUST NOT include any members that relate to a specific
1526 RDAP object type (e.g., "events" or "status"). In addition, the
1527 response MAY include an indication of the requested operation's
1528 success or failure in the "notices" data structure. The "notices"
1529 data structure MAY include an indication of the success or failure of
1530 any attempt to logout from the OP or to revoke the tokens issued by
1531 the OP.
1532
1533 An example of a "farv1_session/logout" response:
1534
1535 {
1536 "rdapConformance": [
1537 "farv1"
1538 ],
1539 "lang": "en-US",
1540 "notices": [
1541 {
1542 "title": "Logout Result",
1543 "description": [
1544 "Logout succeeded"
1545 "Provider logout failed: Not supported by provider.",
1546 "Token revocation successful."
1547 ]
1548 }
1549 ]
1550 }
1551
1552 Figure 25
1553
1554 In the absence of a "logout" request, an RDAP session MUST be
1555 terminated by the RDAP server after a server-defined period of time.
1556 The server SHOULD also take appropriate steps to ensure that the
1557 tokens associated with the terminated session cannot be reused. This
1558 SHOULD include revoking the tokens or logging out from the OP if
1559 either operation is supported by the OP.
1560
1561 5.6. Request Sequencing
1562
1563 The requests described in this document are typically performed in a
1564 specific sequence:
1565
1566 1. "farv1_session/login" (or the related "farv1_session/device" and
1567 "farv1_session/devicepoll" requests) to start a session,
1568
1569 2. "farv1_session/status" and/or "farv1_session/refresh" to manage a
1570 session,
1571
1572 3. and "farv1_session/logout" to end a session.
1573
1574 If a client sends a "farv1_session/status", "farv1_session/refresh",
1575 or "farv1_session/logout" request in the absence of a session cookie,
1576 the server MUST return an HTTP 409 (Conflict) error.
1577
1578 A client can end a session explicitly by sending a "farv1_session/
1579 logout" request to the RDAP server. A session can also be ended
1580 implicitly by the server after a server-defined period of time. The
1581 status of a session can be determined at any time by sending a
1582 "farv1_session/status" query to the RDAP server.
1583
1584 An RDAP server MUST maintain session state information for the
1585 duration of an active session. This is commonly done using HTTP
1586 cookies as described in [RFC6265]. Doing so allows end users to
1587 submit queries without having to explicitly identify and authenticate
1588 themselves for every query.
1589
1590 An RDAP server can receive queries that include a session cookie
1591 where the associated session has expired or is otherwise unavailable
1592 (e.g., due to the user requesting explicit logout for the associated
1593 session). The server MUST return an HTTP 401 (Unauthorized) error in
1594 response to such queries.
1595
1596 6. Protocol Features for Token-Oriented Clients
1597
1598 This specification adds additional processing steps for token-
1599 oriented clients as described in this section and Section 3.1.3. It
1600 does not define additional data structures or RDAP-specific protocol
1601 parameters specifically for token-oriented clients.
1602
1603 6.1. Client Login
1604
1605 Clients identify and authenticate end users by exchanging information
1606 with an OP that is recognized by the RDAP server as described in
1607 Sections 3.1.4.2, 3.1.4.3, and 3.1.4.4. A client SHOULD append the
1608 "additionalAuthorizationQueryParams" values retrieved from the
1609 "openidcProviders" array described in Section 4.1 to the
1610 authorization endpoint URL when requesting authorization from the OP.
1611 Once these processes are completed successfully, the client can
1612 request tokens from the OP as described in Section 3.1.4.5. The OP
1613 SHOULD include the RDAP server's client_id in the "aud" claim value
1614 of an issued ID Token. The RDAP server MAY choose to ignore the
1615 value of the "aud" claim or exchange the token as described in
1616 Section 6.4. With these steps completed, the access token received
1617 from the OP can be passed to an RDAP server in an HTTP
1618 "authorization" request header [RFC6750] for RDAP queries that
1619 require end-user identification, authentication, and authorization.
1620
1621 6.2. Client Queries
1622
1623 An RDAP server that receives a bearer token in an HTTP
1624 "authorization" request header as part of an RDAP object query MUST
1625 validate the token in accordance with local policy and confirm that
1626 the token is a legitimate access token. Once validated, the access
1627 token MAY be used to retrieve the claims associated with the end
1628 user's identity, including claims associated with the "rdap" scope
1629 that are not already included in the access token, as described in
1630 Section 3.1.4.6. The RDAP server can then evaluate the end user's
1631 identity information to determine the end user's authorization level
1632 and process the query in accordance with server policies. A client
1633 MUST include the "farv1_iss" query parameter and Issuer Identifier
1634 value with an RDAP query if the token was issued by a remote OP.
1635
1636 6.3. Access Token Validation
1637
1638 An RDAP server MUST validate a received access token prior to using
1639 that token for access control purposes. Validation MAY include token
1640 introspection [RFC7662] using the issuing OP or analysis of the
1641 values included in a JWT access token. Once an access token is
1642 validated, an RDAP server MAY use that token to request user claims
1643 from the issuing OP.
1644
1645 There are performance considerations associated with the process of
1646 validating a token and requesting user claims as part of processing
1647 every received RDAP query. An RDAP server MAY cache validated
1648 information and use that cached information to reduce the amount of
1649 time needed to process subsequent RDAP queries associated with the
1650 same access token as long as the token has not expired. The client
1651 SHOULD monitor the token expiration time and refresh the token as
1652 needed.
1653
1654 6.4. Token Exchange
1655
1656 Tokens can include an "aud" (audience) claim that contains the OAuth
1657 2.0 client_id of the RP as an audience value. In some operational
1658 scenarios (such as a client that is providing a proxy service), an RP
1659 can receive tokens with an "aud" claim value that does not include
1660 the RP's client_id. These tokens might not be trusted by the RP, and
1661 the RP might refuse to accept the tokens. This situation can be
1662 remedied by having the RP exchange the access token with the OP for a
1663 set of trusted tokens that reset the "aud" claim. The token exchange
1664 protocol is described in [RFC8693].
1665
1666 7. RDAP Query Processing
1667
1668 Once an RDAP session is active, an RDAP server MUST determine if the
1669 end user is authorized to perform any queries that are received
1670 during the duration of the session. This MAY include rejecting
1671 queries outright, and it MAY include omitting or otherwise redacting
1672 information that the end user is not authorized to receive. Specific
1673 processing requirements are beyond the scope of this document.
1674
1675 8. RDAP Conformance
1676
1677 RDAP responses that contain values described in this document MUST
1678 indicate conformance with this specification by including an
1679 rdapConformance [RFC9083] value of "farv1" (federated authentication
1680 method for RDAP version 1). The information needed to register this
1681 value in the "RDAP Extensions" registry is described in Section 9.1.
1682
1683 Example rdapConformance structure with extension specified:
1684
1685 "rdapConformance" :
1686 [
1687 "rdap_level_0",
1688 "farv1"
1689 ]
1690
1691 Figure 26
1692
1693 9. IANA Considerations
1694
1695 9.1. RDAP Extensions Registry
1696
1697 IANA has registered the following value in the "RDAP Extensions"
1698 registry:
1699
1700 Extension Identifier: farv1
1701 Registry Operator: Any
1702 Specification: RFC 9560
1703 Contact: IETF <iesg@ietf.org>
1704 Intended Usage: This extension describes federated authentication
1705 method for RDAP version 1 using OAuth 2.0 and OpenID Connect.
1706
1707 9.2. JSON Web Token Claims Registry
1708
1709 IANA has registered the following values in the "JSON Web Token
1710 Claims" registry:
1711
1712 Claim Name: rdap_allowed_purposes
1713 Claim Description: This claim describes the set of RDAP query
1714 purposes that are available to an identity that is presented for
1715 access to a protected RDAP resource.
1716 Change Controller: IETF
1717 Reference: Section 3.1.5.1 of RFC 9560.
1718
1719 Claim Name: rdap_dnt_allowed
1720 Claim Description: This claim contains a JSON boolean literal that
1721 describes a "do not track" request for server-side tracking,
1722 logging, or recording of an identity that is presented for access
1723 to a protected RDAP resource.
1724 Change Controller: IETF
1725 Reference: Section 3.1.5.2 of RFC 9560.
1726
1727 9.3. RDAP Query Purpose Registry
1728
1729 IANA has created a new protocol registry to manage RDAP query purpose
1730 values.
1731
1732 Section at https://www.iana.org/protocols: Registration Data Access
1733 Protocol (RDAP)
1734 Registry Name: Registration Data Access Protocol (RDAP) Query
1735 Purpose Values
1736 Registration Procedure(s): This registry is operated under the
1737 "Specification Required" policy defined in [RFC8126]. The
1738 designated expert must ensure that requests to add values to this
1739 registry meet the syntax, value, and description requirements
1740 described in this section.
1741 Required Information: Registration requests are described in a
1742 specification that's consistent with the "Specification Required"
1743 policy defined in [RFC8126]. The specification must include one
1744 or more purpose values as described below.
1745
1746 Individual purpose values are registered with IANA. Each entry in
1747 the registry contains the following fields:
1748
1749 Value: The purpose string value being registered. Value strings can
1750 contain uppercase ASCII characters from "A" to "Z", lowercase
1751 ASCII characters from "a" to "z", and the underscore ("_")
1752 character. Value strings contain at least one character and no
1753 more than 64 characters.
1754 Description: One or two sentences in English describing the meaning
1755 of the purpose value, how it might be used, and/or how it should
1756 be interpreted by clients and servers.
1757 Reference: RFC 9560
1758
1759 The set of initial values used to populate the registry as described
1760 below are derived from the final report produced by the Expert
1761 Working Group on gTLD Directory Services chartered by the Internet
1762 Corporation for Assigned Names and Numbers (ICANN) [gTLD].
1763
1764 Value: domainNameControl
1765 Description: Tasks within the scope of this purpose include, for a
1766 registrant's own domain name, creating the domain name, updating
1767 information about the domain name, transferring the domain name,
1768 renewing the domain name, deleting the domain name, maintaining a
1769 domain name portfolio, and detecting fraudulent use of the
1770 registrant's own contact information.
1771 Reference: RFC 9560
1772
1773 Value: personalDataProtection
1774 Description: Tasks within the scope of this purpose include
1775 identifying the accredited privacy or proxy provider associated
1776 with a domain name, reporting abuse, requesting reveal, or
1777 otherwise contacting the provider.
1778 Reference: RFC 9560
1779
1780 Value: technicalIssueResolution
1781 Description: Tasks within the scope of this purpose include (but are
1782 not limited to) working to resolve technical issues, including
1783 email delivery issues, DNS resolution failures, and website
1784 functionality issues.
1785 Reference: RFC 9560
1786
1787 Value: domainNameCertification
1788 Description: Tasks within the scope of this purpose include a
1789 Certification Authority (CA) issuing an X.509 certificate to a
1790 subject identified by a domain name.
1791 Reference: RFC 9560
1792
1793 Value: individualInternetUse
1794 Description: Tasks within the scope of this purpose include
1795 identifying the organization using a domain name to instill
1796 consumer trust or contacting that organization to raise a customer
1797 complaint to them or file a complaint about them.
1798 Reference: RFC 9560
1799
1800 Value: businessDomainNamePurchaseOrSale
1801 Description: Tasks within the scope of this purpose include making
1802 purchase queries about a domain name, acquiring a domain name from
1803 a registrant, and enabling due diligence research.
1804 Reference: RFC 9560
1805
1806 Value: academicPublicInterestDNSResearch
1807 Description: Tasks within the scope of this purpose include academic
1808 public interest research studies about domain names published in
1809 the registration data service, including public information about
1810 the registrant and designated contacts, the domain name's history
1811 and status, and domain names registered by a given registrant
1812 (reverse query).
1813 Reference: RFC 9560
1814
1815 Value: legalActions
1816 Description: Tasks within the scope of this purpose include
1817 investigating possible fraudulent use of a registrant's name or
1818 address by other domain names, investigating possible trademark
1819 infringement, contacting a registrant's or licensee's legal
1820 representative prior to taking legal action, and then taking a
1821 legal action if the concern is not satisfactorily addressed.
1822 Reference: RFC 9560
1823
1824 Value: regulatoryAndContractEnforcement
1825 Description: Tasks within the scope of this purpose include
1826 investigating the tax authority of businesses with online
1827 presences, investigating Uniform Domain-Name Dispute-Resolution
1828 Policy (UDRP), investigating contractual compliance, and
1829 registering data escrow audits.
1830 Reference: RFC 9560
1831
1832 Value: criminalInvestigationAndDNSAbuseMitigation
1833 Description: Tasks within the scope of this purpose include
1834 reporting abuse to someone who can investigate and address that
1835 abuse or contacting entities associated with a domain name during
1836 an offline criminal investigation.
1837 Reference: RFC 9560
1838
1839 Value: dnsTransparency
1840 Description: Tasks within the scope of this purpose involve querying
1841 the registration data made public by registrants to satisfy a wide
1842 variety of use cases around informing the public.
1843 Reference: RFC 9560
1844
1845 10. Security Considerations
1846
1847 Security considerations for RDAP can be found in [RFC7481]. Security
1848 considerations for OpenID Connect Core [OIDCC] and OAuth 2.0
1849 [RFC6749] can be found in their reference specifications; best
1850 current security practice for OAuth 2.0 can be found in
1851 [OAUTH-SECURITY]. Additionally, the practices described in [RFC9325]
1852 MUST be followed when the Transport Layer Security (TLS) protocol is
1853 used.
1854
1855 As described in Section 3.1.4.2, the OAuth 2.0 Implicit Flow
1856 [RFC6749] is considered insecure, and efforts are being made to
1857 deprecate the flow. It MUST NOT be used.
1858
1859 Some of the responses described in this specification return
1860 information to a client from an RDAP server that is intended to help
1861 the client match responses to queries and manage sessions. Some of
1862 that information, such as the "userClaims" described in
1863 Section 5.1.1, can be personally identifiable and considered
1864 sensitive if disclosed to unauthorized parties. An RDAP server
1865 operator must develop policies for information disclosure to ensure
1866 that personally identifiable information is disclosed only to clients
1867 that are authorized to process that information.
1868
1869 The "do not track" claim relies on the good will of the RDAP server
1870 and associated proxies. As such, using and processing this claim
1871 depends on out-of-band trust relationships that need to be
1872 established before the claim is used in practice. If used and
1873 accepted by the RDAP server, there is a risk of information loss that
1874 could seriously impair audit capabilities.
1875
1876 10.1. Authentication and Access Control
1877
1878 Having completed the client identification, authorization, and
1879 validation process, an RDAP server can make access control decisions
1880 based on a comparison of client-provided information (such as the set
1881 of "userClaims" described in Section 5.1.1) and local policy. For
1882 example, a client who provides an email address (and nothing more)
1883 might be entitled to receive a subset of the information that would
1884 be available to a client who provides an email address, a full name,
1885 and a stated purpose. Development of these access control policies
1886 is beyond the scope of this document.
1887
1888 11. References
1889
1890 11.1. Normative References
1891
1892 [HTMLURL] WHATWG, "URL (Living Standard)", March 2024,
1893 <https://url.spec.whatwg.org/>.
1894
1895 [OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
1896 C. Mortimore, "OpenID Connect Core 1.0 incorporating
1897 errata set 2", December 2023,
1898 <https://openid.net/specs/openid-connect-core-1_0.html>.
1899
1900 [OIDCD] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
1901 Connect Discovery 1.0 incorporating errata set 2",
1902 December 2023, <https://openid.net/specs/openid-connect-
1903 discovery-1_0.html>.
1904
1905 [OIDCL] Jones, M., de Medeiros, B., Agarwal, N., Sakimura, N., and
1906 J. Bradley, "OpenID Connect RP-Initiated Logout 1.0",
1907 September 2022, <https://openid.net/specs/openid-connect-
1908 rpinitiated-1_0.html>.
1909
1910 [OIDCR] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
1911 Dynamic Client Registration 1.0 incorporating errata set
1912 2", December 2023, <https://openid.net/specs/openid-
1913 connect-registration-1_0.html>.
1914
1915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1916 Requirement Levels", BCP 14, RFC 2119,
1917 DOI 10.17487/RFC2119, March 1997,
1918 <https://www.rfc-editor.org/info/rfc2119>.
1919
1920 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
1921 DOI 10.17487/RFC6265, April 2011,
1922 <https://www.rfc-editor.org/info/rfc6265>.
1923
1924 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
1925 RFC 6749, DOI 10.17487/RFC6749, October 2012,
1926 <https://www.rfc-editor.org/info/rfc6749>.
1927
1928 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
1929 Framework: Bearer Token Usage", RFC 6750,
1930 DOI 10.17487/RFC6750, October 2012,
1931 <https://www.rfc-editor.org/info/rfc6750>.
1932
1933 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
1934 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
1935 August 2013, <https://www.rfc-editor.org/info/rfc7009>.
1936
1937 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
1938 Registration Data Access Protocol (RDAP)", STD 95,
1939 RFC 7480, DOI 10.17487/RFC7480, March 2015,
1940 <https://www.rfc-editor.org/info/rfc7480>.
1941
1942 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
1943 Registration Data Access Protocol (RDAP)", STD 95,
1944 RFC 7481, DOI 10.17487/RFC7481, March 2015,
1945 <https://www.rfc-editor.org/info/rfc7481>.
1946
1947 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
1948 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
1949 <https://www.rfc-editor.org/info/rfc7519>.
1950
1951 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
1952 RFC 7617, DOI 10.17487/RFC7617, September 2015,
1953 <https://www.rfc-editor.org/info/rfc7617>.
1954
1955 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
1956 RFC 7662, DOI 10.17487/RFC7662, October 2015,
1957 <https://www.rfc-editor.org/info/rfc7662>.
1958
1959 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1960 Writing an IANA Considerations Section in RFCs", BCP 26,
1961 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1962 <https://www.rfc-editor.org/info/rfc8126>.
1963
1964 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1965 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1966 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1967
1968 [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
1969 "OAuth 2.0 Device Authorization Grant", RFC 8628,
1970 DOI 10.17487/RFC8628, August 2019,
1971 <https://www.rfc-editor.org/info/rfc8628>.
1972
1973 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
1974 and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
1975 DOI 10.17487/RFC8693, January 2020,
1976 <https://www.rfc-editor.org/info/rfc8693>.
1977
1978 [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
1979 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
1980 2021, <https://www.rfc-editor.org/info/rfc9068>.
1981
1982 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
1983 Protocol (RDAP) Query Format", STD 95, RFC 9082,
1984 DOI 10.17487/RFC9082, June 2021,
1985 <https://www.rfc-editor.org/info/rfc9082>.
1986
1987 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
1988 Registration Data Access Protocol (RDAP)", STD 95,
1989 RFC 9083, DOI 10.17487/RFC9083, June 2021,
1990 <https://www.rfc-editor.org/info/rfc9083>.
1991
1992 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1993 Ed., "HTTP Semantics", STD 97, RFC 9110,
1994 DOI 10.17487/RFC9110, June 2022,
1995 <https://www.rfc-editor.org/info/rfc9110>.
1996
1997 [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
1998 "Recommendations for Secure Use of Transport Layer
1999 Security (TLS) and Datagram Transport Layer Security
2000 (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2001 2022, <https://www.rfc-editor.org/info/rfc9325>.
2002
2003 11.2. Informative References
2004
2005 [gTLD] Expert Working Group on gTLD Directory Services (EWG),
2006 "Final Report from the Expert Working Group on gTLD
2007 Directory Services: A Next-Generation Registration
2008 Directory Service (RDS)", June 2014,
2009 <https://www.icann.org/en/system/files/files/final-report-
2010 06jun14-en.pdf>.
2011
2012 [OAUTH-SECURITY]
2013 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
2014 "OAuth 2.0 Security Best Current Practice", Work in
2015 Progress, Internet-Draft, draft-ietf-oauth-security-
2016 topics-26, 21 April 2024,
2017 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
2018 security-topics-26>.
2019
2020 [OIDC] OpenID, "What is OpenID Connect",
2021 <https://openid.net/developers/how-connect-works/>.
2022
2023 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
2024 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
2025 <https://www.rfc-editor.org/info/rfc4949>.
2026
2027 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
2028 Authorization Server Metadata", RFC 8414,
2029 DOI 10.17487/RFC8414, June 2018,
2030 <https://www.rfc-editor.org/info/rfc8414>.
2031
2032 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
2033 "Handling Long Lines in Content of Internet-Drafts and
2034 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
2035 <https://www.rfc-editor.org/info/rfc8792>.
2036
2037 Acknowledgments
2038
2039 The author would like to acknowledge the following individuals for
2040 their contributions to the development of this document: Julien
2041 Bernard, Marc Blanchet, Tom Harrison, Russ Housley, Jasdip Singh,
2042 Rhys Smith, Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In
2043 addition, the Verisign Registry Services Lab development team of
2044 Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel
2045 Sheth, Nitin Singh, and Zhao Zhao provided critical "proof of
2046 concept" implementation experience that helped demonstrate the
2047 validity of the concepts described in this document.
2048
2049 Pawel Kowalik and Mario Loffredo provided significant text
2050 contributions that led to welcome improvements in several sections of
2051 this document. Their contributions are greatly appreciated.
2052
2053 Author's Address
2054
2055 Scott Hollenbeck
2056 Verisign Labs
2057 12061 Bluemont Way
2058 Reston, VA 20190
2059 United States of America
2060 Email: shollenbeck@verisign.com
2061 URI: https://www.verisignlabs.com/
2062
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.