1 Internet Engineering Task Force (IETF) M. Loffredo
2 Request for Comments: 9536 M. Martinelli
3 Category: Standards Track IIT-CNR/Registro.it
4 ISSN: 2070-1721 April 2024
5
6
7 Registration Data Access Protocol (RDAP) Reverse Search
8
9 Abstract
10
11 The Registration Data Access Protocol (RDAP) does not include query
12 capabilities for finding the list of domains related to a set of
13 entities matching a given search pattern. Considering that an RDAP
14 entity can be associated with any defined object class and other
15 relationships between RDAP object classes exist, a reverse search can
16 be applied to other use cases besides the classic domain-entity
17 scenario. This document describes an RDAP extension that allows
18 servers to provide a reverse search feature based on the relationship
19 defined in RDAP between an object class for search and any related
20 object class. The reverse search based on the domain-entity
21 relationship is treated as a particular case.
22
23 Status of This Memo
24
25 This is an Internet Standards Track document.
26
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 7841.
32
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 https://www.rfc-editor.org/info/rfc9536.
36
37 Copyright Notice
38
39 Copyright (c) 2024 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
41
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Revised BSD License text as described in Section 4.e of the
49 Trust Legal Provisions and are provided without warranty as described
50 in the Revised BSD License.
51
52 Table of Contents
53
54 1. Introduction
55 1.1. Background
56 1.2. Conventions Used in This Document
57 2. Reverse Search Path Segment Specification
58 3. Reverse Search Definition
59 4. Reverse Search Properties Discovery
60 5. Reverse Search Properties Mapping
61 6. Reverse Search Response Specification
62 7. Reverse Search Query Processing
63 8. Reverse Searches Based on Entity Details
64 9. RDAP Conformance
65 10. Implementation Considerations
66 11. IANA Considerations
67 11.1. RDAP Extensions Registry
68 11.2. RDAP Reverse Search Registries
69 11.2.1. Creation of the RDAP Reverse Search Registries
70 11.2.2. Submit Requests to IANA
71 11.2.3. RDAP Reverse Search Registry
72 11.2.3.1. Template
73 11.2.3.2. Initial Content
74 11.2.4. RDAP Reverse Search Mapping Registry
75 11.2.4.1. Template
76 11.2.4.2. Initial Content
77 12. Privacy Considerations
78 13. Security Considerations
79 14. References
80 14.1. Normative References
81 14.2. Informative References
82 Appendix A. Paradigms to Enforce Access Control on Reverse Search
83 in RDAP
84 Acknowledgements
85 Authors' Addresses
86
87 1. Introduction
88
89 The protocol described in this specification aims to extend the RDAP
90 query capabilities and response to enable reverse search based on the
91 relationships defined in RDAP between an object class for search and
92 a related object class. The reverse search based on the domain-
93 entity relationship is treated as a particular case of such a generic
94 model.
95
96 RDAP providers willing to implement this specification should
97 carefully consider its implications on the efficiency (see
98 Section 10), the security (see Section 13), and the compliance with
99 privacy regulations (see Section 12) of their RDAP service.
100
101 1.1. Background
102
103 Reverse WHOIS is a service provided by many web applications that
104 allows users to find domain names owned by an individual or a company
105 starting from the owner's details, such as name and email. Even if
106 it has been considered useful for some legal purposes (e.g.,
107 uncovering trademark infringements and detecting cybercrimes), its
108 availability as a standardized WHOIS [RFC3912] capability has been
109 objected to for two main reasons, which now don't seem to conflict
110 with an RDAP implementation.
111
112 The first objection concerns the potential risks of privacy
113 violation. However, the domain name community is considering a new
114 generation of Registration Directory Services [ICANN-RDS] [ICANN-RA]
115 that provide access to sensitive data under some permissible purposes
116 and in accordance with appropriate policies for requestor
117 accreditation, authentication, and authorization. RDAP's reliance on
118 HTTP means that it can make use of common HTTP-based approaches to
119 authentication and authorization, making it more useful than WHOIS in
120 the context of such directory services. Since RDAP consequently
121 permits a reverse search implementation complying with privacy
122 protection principles, this first objection is not well-founded.
123
124 The second objection to the implementation of a reverse search
125 capability has been connected with its impact on server processing.
126 However, the core RDAP specifications already define search queries,
127 with similar processing requirements, so the basis of this objection
128 is not clear.
129
130 Reverse searches, such as finding the list of domain names associated
131 with contacts or nameservers, may be useful to registrars as well.
132 Usually, registries adopt out-of-band solutions to provide results to
133 registrars asking for reverse searches on their domains. Possible
134 reasons for such requests are:
135
136 * the loss of synchronization between the registrar database and the
137 registry database and
138
139 * the need for such data to perform bulk Extensible Provisioning
140 Protocol (EPP) [RFC5730] updates (e.g., changing the contacts of a
141 set of domains, etc.).
142
143 Currently, RDAP does not provide any means for a client to search for
144 the collection of domains associated with an entity [RFC9082]. A
145 query (lookup or search) on domains can return the array of entities
146 related to a domain with different roles (registrant, registrar,
147 administrative, technical, reseller, etc.), but the reverse operation
148 is not allowed. Only reverse searches to find the collection of
149 domains related to a nameserver (ldhName or ip) can be requested.
150 Since an entity can be in relationship with any RDAP object
151 [RFC9083], the availability of a reverse search as largely intended
152 can be common to all the object classes allowed for search. Through
153 a further step of generalization, the meaning of reverse search in
154 the RDAP context can be extended to include any query for retrieving
155 all the objects that relates to another query matching a given search
156 pattern.
157
158 1.2. Conventions Used in This Document
159
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
163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
164 capitals, as shown here.
165
166 2. Reverse Search Path Segment Specification
167
168 A generic reverse search path is described by the syntax:
169
170 {searchable-resource-type}/reverse_search/{related-resource-
171 type}?<search-condition>
172
173 The path segments are defined as follows:
174
175 "searchable-resource-type": It MUST be one of the resource types for
176 search defined in Section 3.2 of [RFC9082] (i.e., "domains",
177 "nameservers", and "entities") or a resource type extension.
178
179 "related-resource-type": It MUST be one of the resource types for
180 lookup defined in Section 3.1 of [RFC9082] (i.e., "domain",
181 "nameserver", "entity", "ip", and "autnum") or a resource type
182 extension.
183
184 "search-condition": A sequence of "property=search pattern"
185 predicates separated by the ampersand character ('&', US-ASCII
186 value 0x0026).
187
188 While related-resource-type is defined as having one of a number of
189 different values, the only reverse searches defined in this document
190 are for a related-resource-type of "entity". Reverse searches for
191 the other resource types specified in [RFC9082] and resource type
192 extensions may be defined by future documents.
193
194 3. Reverse Search Definition
195
196 Based on the content of Section 2, defining a reverse search means to
197 define the triple <searchable resource type, related resource type,
198 property> and the mapping with the corresponding RDAP object member.
199 The mapping is done through the use of a JSONPath expression
200 [RFC9535]. Reverse searches are registered in the "RDAP Reverse
201 Search" registry (see Section 11.2.3), whereas reverse search
202 mappings are registered in the "RDAP Reverse Search Mapping" registry
203 (see Section 11.2.4). The reason for having two registries is that
204 it may be possible for a single type of reverse search to rely on
205 different members, depending on the server's configuration (see
206 Section 5).
207
208 All of the reverse searches defined by this document (see Section 8)
209 have property names that are the same as the name of the RDAP object
210 member that is the subject of the search. For example, the reverse
211 search with the property name "fn" relies on the value of the "fn"
212 member inside the jCard of an entity object. However, it is not
213 necessary that these two names be the same. In particular, remapping
214 of searches as part of the deprecation of an existing member (see
215 Section 5) will typically lead to a member with a different name
216 being used for the search.
217
218 Servers MUST NOT provide or implement reverse searches or reverse
219 search mappings that are not registered with IANA.
220
221 4. Reverse Search Properties Discovery
222
223 Servers complying with this specification MUST extend the help
224 response [RFC9083] with the "reverse_search_properties" member that
225 contains an array of objects with the following mandatory child
226 members:
227
228 "searchableResourceType": the searchable resource type of the
229 reverse search query, as defined in Section 2
230
231 "relatedResourceType": the related resource type of the reverse
232 search query, as defined in Section 2
233
234 "property": the reverse search property used in the predicate of the
235 reverse search query, as defined in Section 2
236
237 An example of the help response including the
238 "reverse_search_properties" member is shown in Figure 2
239
240 5. Reverse Search Properties Mapping
241
242 To permit clients to determine the member used by the server for a
243 reverse search, servers MUST detail the mapping that is occurring by
244 adding the "reverse_search_properties_mapping" member to the topmost
245 object of a reverse search response. This data structure is included
246 in the search response, rather than in the help response, because it
247 may differ depending on the query that is sent to the server.
248
249 Documents that deprecate or restructure RDAP responses such that a
250 registered reverse search is no longer able to be used MUST either
251 note that the relevant reverse search is no longer available (in the
252 case of deprecation) or describe how to continue supporting the
253 relevant search by adding another mapping for the reverse search
254 property (in the case of restructuring).
255
256 The "reverse_search_properties_mapping" member contains an array of
257 objects with the following mandatory child members:
258
259 "property": the reverse search property used in the predicate of the
260 current query, as defined in Section 2
261
262 "propertyPath": the JSONPath expression of the object member (or
263 members) corresponding to the reverse search property
264
265 The searchable and the related resource types are derived from the
266 query, so there is no need to include them in addition to the
267 property in this member.
268
269 This member MUST be included for all properties used in the search,
270 regardless of whether that property has multiple registered mappings
271 as at the time of the search, because new mappings may be registered
272 at any time.
273
274 When applied to an object, the JSONPath expression MUST produce a
275 list of values, each of which is a JSON number or string.
276
277 An example of a reverse search response including the
278 "reverse_search_properties_mapping" member is shown in Figure 3.
279
280 6. Reverse Search Response Specification
281
282 Reverse search responses use the formats defined in Section 8 of
283 [RFC9083], which correspond to the searchable resource types defined
284 in Section 2.
285
286 7. Reverse Search Query Processing
287
288 To process a reverse search, the server returns the objects from its
289 data store that are of type searchable-resource-type and that match
290 each of the predicates from the search conditions. To determine
291 whether an object matches a predicate, the server:
292
293 * applies the mapping it uses for the reverse search property to the
294 object in order to generate a list of values, each of which MUST
295 be a JSON number or string and
296
297 * checks whether the search pattern matches one or more of those
298 values.
299
300 A search pattern matches a value where it equals the string
301 representation of the value or where it is a match for the value in
302 accordance with the partial string matching behavior defined in
303 Section 4.1 of [RFC9082].
304
305 Objects are only included in the search results if they satisfy all
306 included predicates. This includes predicates that are for the same
307 property; in such a case, it is necessary for the related object to
308 match against each of those predicates.
309
310 Servers MUST return an HTTP 501 (Not Implemented) [RFC9110] response
311 to inform clients of unsupported reverse searches.
312
313 Based on their policy, servers MAY restrict how predicates are used
314 to make a valid search condition by returning a 400 (Bad Request)
315 response when a problematic request is received.
316
317 A given reverse search or reverse search mapping MAY define
318 additional or alternative search behavior past that set out in this
319 section.
320
321 8. Reverse Searches Based on Entity Details
322
323 Since an entity can be associated with any other object class in
324 RDAP, the most common kind of reverse search is one based on an
325 entity's details. Such reverse searches arise from the query model
326 by setting the related resource type to "entity".
327
328 By selecting a specific searchable resource type, the resulting
329 reverse search aims at retrieving all the objects (e.g., all the
330 domains) that are related to any entity object matching the search
331 conditions.
332
333 This section defines the reverse search properties servers SHOULD
334 support for the domain, nameserver, entity-searchable resource types,
335 and entity-related resource type:
336
337 Reverse search property: role
338 RDAP member path: $.entities[*].roles
339 Reference: Section 10.2.4 of [RFC9083]
340
341 Reverse search property: handle
342 RDAP member path: $.entities[*].handle
343 Reference: Section 5.1 of [RFC9083]
344
345 Reverse search property: fn
346 RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
347 Reference: Section 6.2.1 of [RFC6350]
348
349 Reverse search property: email
350 RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='email')][3]
351 Reference: Section 6.4.2 of [RFC6350]
352
353 The presence of a predicate on the reverse search property "role"
354 means that the RDAP response property "roles" MUST contain at least
355 the specified role.
356
357 The last two properties are related to jCard elements [RFC7095], but
358 the field references are to vCard [RFC6350], since jCard is the JSON
359 format for vCard.
360
361 Examples of reverse search paths based on the domain-entity
362 relationship are presented in Figure 1.
363
364 /domains/reverse_search/entity?handle=CID-40*&role=technical
365
366 /domains/reverse_search/entity?fn=Bobby*&role=registrant
367
368 /domains/reverse_search/entity?handle=RegistrarX&role=registrar
369
370 Figure 1: Examples of Reverse Search Queries
371
372 An example of the help response including the supported reverse
373 search properties is shown in Figure 2.
374
375 {
376 "rdapConformance": [
377 "rdap_level_0",
378 "reverse_search"
379 ],
380 ...
381 "reverse_search_properties": [
382 {
383 "searchableResourceType": "domains",
384 "relatedResourceType": "entity",
385 "property": "fn"
386 },
387 {
388 "searchableResourceType": "domains",
389 "relatedResourceType": "entity",
390 "property": "handle"
391 },
392 {
393 "searchableResourceType": "domains",
394 "relatedResourceType": "entity",
395 "property": "email"
396 },
397 {
398 "searchableResourceType": "domains",
399 "relatedResourceType": "entity",
400 "property": "role"
401 }
402 ],
403 ...
404 }
405
406 Figure 2: An Example of the Help Response including the
407 "reverse_search_properties" Member
408
409 An example of a response including the mapping that is occurring for
410 the first reverse search in Figure 1 is shown below.
411
412 {
413 "rdapConformance": [
414 "rdap_level_0",
415 "reverse_search"
416 ],
417 ...
418 "reverse_search_properties_mapping": [
419 {
420 "property": "handle",
421 "propertyPath": "$.entities[*].handle"
422 },
423 {
424 "property": "role",
425 "propertyPath": "$.entities[*].roles"
426 }
427 ],
428 ...
429 }
430
431 Figure 3: An Example of an RDAP Response including the
432 "reverse_search_properties_mapping" Member
433
434 9. RDAP Conformance
435
436 Servers complying with this specification MUST include the value
437 "reverse_search" in the rdapConformance property of the help response
438 [RFC9083] and any other response including the
439 "reverse_search_properties_mapping" member. The information needed
440 to register this value in the "RDAP Extensions" registry is described
441 in Section 11.1.
442
443 10. Implementation Considerations
444
445 To limit the impact of processing the search predicates, servers are
446 RECOMMENDED to make use of techniques to speed up the data retrieval
447 in their underlying data store, such as indexes or similar. In
448 addition, risks with respect to performance degradation or result set
449 generation can be mitigated by adopting practices used for standard
450 searches, e.g., restricting the search functionality, limiting the
451 rate of search requests according to the user's authorization,
452 truncating and paging the results [RFC8977], and returning partial
453 responses [RFC8982].
454
455 11. IANA Considerations
456
457 11.1. RDAP Extensions Registry
458
459 IANA has registered the following value in the "RDAP Extensions"
460 registry:
461
462 Extension Identifier: reverse_search
463
464 Registry Operator: Any
465
466 Specification: RFC 9536
467
468 Contact: IETF <iesg@ietf.org>
469
470 Intended Usage: This extension identifier is used for both URI path
471 segments and response extensions related to the reverse search in
472 RDAP.
473
474 11.2. RDAP Reverse Search Registries
475
476 11.2.1. Creation of the RDAP Reverse Search Registries
477
478 IANA has created the "RDAP Reverse Search" and "RDAP Reverse Search
479 Mapping" registries within the "Registration Data Access Protocol
480 (RDAP)" category in the protocol registries.
481
482 These registries follow the Specification Required registration
483 policy, as defined in Section 4.6 of [RFC8126].
484
485 The designated expert should prevent collisions and confirm that
486 suitable documentation, as described in Section 4.5 of [RFC8126], is
487 available to ensure interoperability.
488
489 Creators of either new RDAP reverse searches or new mappings for
490 registered reverse searches SHOULD NOT replicate functionality
491 already available by way of other documents referenced in these
492 registries. Creators MAY register additional reverse search mappings
493 for existing properties, but they SHOULD NOT map a registered reverse
494 search property to a response field with a meaning other than that of
495 the response fields referenced by the mappings already registered for
496 that property. In other words, all the mappings for a reverse search
497 property MUST point to response fields with the same meaning.
498
499 11.2.2. Submit Requests to IANA
500
501 Registration requests can be sent to <iana@iana.org>.
502
503 11.2.3. RDAP Reverse Search Registry
504
505 11.2.3.1. Template
506
507 Property: The name of the reverse search property.
508
509 Description: A brief human-readable text describing the reverse
510 search property.
511
512 Searchable Resource Type: The searchable resource type of the
513 reverse search query (Section 2) including the reverse search
514 property. Multiple reverse search properties differing only by
515 this field can be grouped together by listing all the searchable
516 resource types separated by comma (see Section 11.2.3.2).
517
518 Related Resource Type: The related resource type of the reverse
519 search query (Section 2) including the reverse search property.
520
521 Registrant: The name of the person registering the reverse search
522 property.
523
524 Contact Information: An email address, postal address, or some other
525 information to be used to contact the registrant.
526
527 Reference: Document (e.g., the RFC number) and section reference
528 where the reverse search property is specified.
529
530 The combination of Searchable Resource Type, Related Resource Type,
531 and Property MUST be unique across the registry entries.
532
533 11.2.3.2. Initial Content
534
535 IANA has registered the following entries in the "RDAP Reverse
536 Search" registry. For all entries, the common values are shown in
537 Table 1, whereas the specific values are shown in Table 2.
538
539 +==========================+================================+
540 | Registry Property | Value |
541 +==========================+================================+
542 | Searchable Resource Type | domains, nameservers, entities |
543 +--------------------------+--------------------------------+
544 | Related Resource Type | entity |
545 +--------------------------+--------------------------------+
546 | Registrant | IETF |
547 +--------------------------+--------------------------------+
548 | Contact Information | iesg@ietf.org |
549 +--------------------------+--------------------------------+
550 | Reference | RFC 9536 |
551 +--------------------------+--------------------------------+
552
553 Table 1: Common Values for All Entries in the RDAP
554 Reverse Search Registry
555
556 +==========+==============================================+
557 | Property | Description |
558 +==========+==============================================+
559 | fn | The server supports the domain/nameserver/ |
560 | | entity search based on the full name (a.k.a. |
561 | | formatted name) of an associated entity |
562 +----------+----------------------------------------------+
563 | handle | The server supports the domain/nameserver/ |
564 | | entity search based on the handle of an |
565 | | associated entity |
566 +----------+----------------------------------------------+
567 | email | The server supports the domain/nameserver/ |
568 | | entity search based on the email address of |
569 | | an associated entity |
570 +----------+----------------------------------------------+
571 | role | The server supports the domain/nameserver/ |
572 | | entity search based on the role of an |
573 | | associated entity |
574 +----------+----------------------------------------------+
575
576 Table 2: Specific Values for Entries in the RDAP
577 Reverse Search Registry
578
579 11.2.4. RDAP Reverse Search Mapping Registry
580
581 11.2.4.1. Template
582
583 Property: The same as defined in the "RDAP Reverse Search" registry.
584
585 Property Path: The JSONPath of the RDAP property this reverse search
586 property maps to.
587
588 Searchable Resource Type: The same as defined in the "RDAP Reverse
589 Search" registry.
590
591 Related Resource Type: The same as defined in the "RDAP Reverse
592 Search" registry.
593
594 Registrant: The name of the person registering this reverse search
595 property mapping.
596
597 Contact Information: The same as defined in the "RDAP Reverse
598 Search" registry.
599
600 Reference: Document (e.g., the RFC number) and section reference
601 where this reverse search property mapping is specified.
602
603 The combination of Searchable Resource Type, Related Resource Type,
604 Property, and Property Path MUST be unique across the registry
605 entries.
606
607 11.2.4.2. Initial Content
608
609 IANA has registered the following entries in the "RDAP Reverse Search
610 Mapping" registry. For all entries, the common values are the same
611 as defined in the "RDAP Reverse Search" registry (see Table 1),
612 whereas the specific values are shown below (see Table 3).
613
614 +==========+==================================================+
615 | Property | Property Path |
616 +==========+==================================================+
617 | fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] |
618 +----------+--------------------------------------------------+
619 | handle | $.entities[*].handle |
620 +----------+--------------------------------------------------+
621 | email | $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
622 +----------+--------------------------------------------------+
623 | role | $.entities[*].roles |
624 +----------+--------------------------------------------------+
625
626 Table 3: Specific Values for Entries in the RDAP Reverse
627 Search Mapping Registry
628
629 12. Privacy Considerations
630
631 The search functionality defined in this document may affect the
632 privacy of entities in the registry (and elsewhere) in various ways;
633 see [RFC6973] for a general treatment of privacy in protocol
634 specifications. Registry operators should be aware of the trade-offs
635 that result from implementing this functionality.
636
637 Many jurisdictions have laws or regulations that restrict the use of
638 "personal data", per the definition in [RFC6973]. Given that,
639 registry operators should ascertain whether the regulatory
640 environment in which they operate permits implementation of the
641 functionality defined in this document.
642
643 In those cases where this functionality makes use of sensitive
644 information, the information MUST only be accessible to authorized
645 users under a lawful basis.
646
647 Since reverse search requests and responses could contain Personally
648 Identifiable Information (PII), reverse search functionality MUST be
649 available over HTTPS only.
650
651 Providing reverse search in RDAP carries the following threats as
652 described in [RFC6973]:
653
654 * Correlation
655
656 * Disclosure
657
658 * Misuse of data
659
660 Therefore, RDAP providers need to mitigate the risk of those threats
661 by implementing appropriate measures supported by security services
662 (see Section 13).
663
664 13. Security Considerations
665
666 Security services that are required to provide controlled access to
667 the operations specified in this document are described in [RFC7481].
668 A non-exhaustive list of access control paradigms an RDAP provider
669 can implement is presented in Appendix A.
670
671 As an additional measure to enforce security by preventing reverse
672 searches to be accessed from unauthorized users, the RDAP providers
673 may consider physically separating the reverse search endpoints from
674 the other ones by configuring a proxy routing the reverse searches to
675 a dedicated backend server and leveraging further security services
676 offered by other protocol layers, such as digital certificates and IP
677 allow-listing.
678
679 Finally, the specification of the relationship within the reverse
680 search path allows the RDAP servers to implement different
681 authorization policies on a per-relationship basis.
682
683 14. References
684
685 14.1. Normative References
686
687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
688 Requirement Levels", BCP 14, RFC 2119,
689 DOI 10.17487/RFC2119, March 1997,
690 <https://www.rfc-editor.org/info/rfc2119>.
691
692 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
693 DOI 10.17487/RFC6350, August 2011,
694 <https://www.rfc-editor.org/info/rfc6350>.
695
696 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
697 DOI 10.17487/RFC7095, January 2014,
698 <https://www.rfc-editor.org/info/rfc7095>.
699
700 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
701 Registration Data Access Protocol (RDAP)", STD 95,
702 RFC 7481, DOI 10.17487/RFC7481, March 2015,
703 <https://www.rfc-editor.org/info/rfc7481>.
704
705 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
706 Writing an IANA Considerations Section in RFCs", BCP 26,
707 RFC 8126, DOI 10.17487/RFC8126, June 2017,
708 <https://www.rfc-editor.org/info/rfc8126>.
709
710 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
711 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
712 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
713
714 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
715 Protocol (RDAP) Query Format", STD 95, RFC 9082,
716 DOI 10.17487/RFC9082, June 2021,
717 <https://www.rfc-editor.org/info/rfc9082>.
718
719 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
720 Registration Data Access Protocol (RDAP)", STD 95,
721 RFC 9083, DOI 10.17487/RFC9083, June 2021,
722 <https://www.rfc-editor.org/info/rfc9083>.
723
724 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
725 Ed., "HTTP Semantics", STD 97, RFC 9110,
726 DOI 10.17487/RFC9110, June 2022,
727 <https://www.rfc-editor.org/info/rfc9110>.
728
729 [RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
730 Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
731 DOI 10.17487/RFC9535, February 2024,
732 <https://www.rfc-editor.org/info/rfc9535>.
733
734 14.2. Informative References
735
736 [ICANN-RA] ICANN, "Base Registry Agreement", January 2024,
737 <https://www.icann.org/en/registry-agreements/base-
738 agreement>.
739
740 [ICANN-RDS]
741 ICANN, "Final Report from the Expert Working Group on gTLD
742 Directory Services: A Next-Generation Registration
743 Directory Service (RDS)", June 2014,
744 <https://www.icann.org/en/system/files/files/final-report-
745 06jun14-en.pdf>.
746
747 [OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
748 C. Mortimore, "OpenID Connect Core 1.0 incorporating
749 errata set 2", December 2023,
750 <http://openid.net/specs/openid-connect-core-1_0.html>.
751
752 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
753 DOI 10.17487/RFC3912, September 2004,
754 <https://www.rfc-editor.org/info/rfc3912>.
755
756 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
757 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
758 <https://www.rfc-editor.org/info/rfc5730>.
759
760 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
761 Morris, J., Hansen, M., and R. Smith, "Privacy
762 Considerations for Internet Protocols", RFC 6973,
763 DOI 10.17487/RFC6973, July 2013,
764 <https://www.rfc-editor.org/info/rfc6973>.
765
766 [RFC8977] Loffredo, M., Martinelli, M., and S. Hollenbeck,
767 "Registration Data Access Protocol (RDAP) Query Parameters
768 for Result Sorting and Paging", RFC 8977,
769 DOI 10.17487/RFC8977, January 2021,
770 <https://www.rfc-editor.org/info/rfc8977>.
771
772 [RFC8982] Loffredo, M. and M. Martinelli, "Registration Data Access
773 Protocol (RDAP) Partial Response", RFC 8982,
774 DOI 10.17487/RFC8982, February 2021,
775 <https://www.rfc-editor.org/info/rfc8982>.
776
777 Appendix A. Paradigms to Enforce Access Control on Reverse Search in
778 RDAP
779
780 Access control can be implemented according to different paradigms
781 introducing increasingly stringent rules. The paradigms listed below
782 leverage the capabilities that are either built in or provided as
783 extensions by the OpenID Connect [OIDCC]:
784
785 Role-Based Access Control (RBAC): Access rights are granted
786 depending on roles. Generally, this is done by grouping users
787 into fixed categories and assigning static grants to each
788 category. A more dynamic approach can be implemented by using the
789 OpenID Connect "scope" claim.
790
791 Purpose-Based Access Control (PBAC): Access rules are based on the
792 notion of purpose, being the intended use of some data by a user.
793 It can be implemented by tagging a request with the usage purpose
794 and making the RDAP server check the compliance between the given
795 purpose and the control rules applied to the data to be returned.
796
797 Attribute-Based Access Control (ABAC): Rules to manage access rights
798 are evaluated and applied according to specific attributes
799 describing the context within which data are requested. It can be
800 implemented within an out-of-band process by setting additional
801 OpenID Connect claims that describe the request context and make
802 the RDAP server check for compliance between the given context and
803 the control rules that are applied to the data to be returned.
804
805 Time-Based Access Control (TBAC): Data access is allowed for a
806 limited time only. It can be implemented by assigning users
807 temporary credentials linked to access grants with limited scopes.
808
809 With regard to the privacy threats reported in Section 12,
810 correlation and disclosure can be mitigated by minimizing both the
811 request features and the response data based on user roles (i.e.,
812 RBAC). Misuse can be mitigated by checking for the purpose of the
813 request (i.e., PBAC). It can be accomplished according to the
814 following approaches:
815
816 Full Trust: The registry trusts the fairness of an accredited user.
817 The requestor is always legitimized to submit their requests under
818 a lawful basis. Additionally, they can be required to specify the
819 purpose as either a claim of their account or a query parameter.
820 In the former case, the purpose is assumed to be the same for
821 every request. In the latter case, the purpose must be one of
822 those associated to the user.
823
824 Zero Trust: The registry requires documents that assess whether the
825 requestor is legitimized to submit a given request. It can be
826 implemented by assigning the requestor a temporary OpenID account
827 linked to the given request (i.e., TBAC) and describing the
828 request through a set of claims (i.e., ABAC). The association
829 between the temporary account and the claims about the request is
830 made by an out-of-band application. In so doing, the RDAP server
831 is able to check that the incoming request is consistent with the
832 request claims linked to the temporary account.
833
834 The two approaches can be used together:
835
836 * The former is suitable for users carrying out a task in the public
837 interest or exercising their official authority (e.g., an officer
838 of a cybercrime agency). Similarly, registrars can submit reverse
839 searches on their domains and contacts based on their contractual
840 relationship with the domain holders. In this case, the query
841 results can be restricted to those pertaining to a registrar by
842 adding an implicit predicate to the search condition.
843
844 * The latter can be taken to allow domain name dispute resolution
845 service providers to request information in defense of the
846 legitimate interests of complainants.
847
848 Acknowledgements
849
850 The authors would like to acknowledge the following individuals for
851 their contributions to this document: Francesco Donini, Scott
852 Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez, Ulrich
853 Wisser, James Gould, and Pawel Kowalik.
854
855 Tom Harrison and Jasdip Singh provided relevant feedback and constant
856 support to the implementation of this proposal. Their contributions
857 have been greatly appreciated.
858
859 Authors' Addresses
860
861 Mario Loffredo
862 IIT-CNR/Registro.it
863 Via Moruzzi,1
864 56124 Pisa
865 Italy
866 Email: mario.loffredo@iit.cnr.it
867 URI: http://www.iit.cnr.it
868
869
870 Maurizio Martinelli
871 IIT-CNR/Registro.it
872 Via Moruzzi,1
873 56124 Pisa
874 Italy
875 Email: maurizio.martinelli@iit.cnr.it
876 URI: http://www.iit.cnr.it
877
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.