idnits 2.17.1 draft-ietf-regext-rdap-reverse-search-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 May 2022) is 722 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 223 -- Looks like a reference, but probably isn't: '0' on line 223 -- Looks like a reference, but probably isn't: '3' on line 223 -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCC' ** Downref: Normative reference to an Informational RFC: RFC 6973 == Outdated reference: A later version (-21) exists of draft-ietf-jsonpath-base-03 == Outdated reference: A later version (-27) exists of draft-ietf-regext-rdap-openid-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions M. Loffredo 3 Internet-Draft M. Martinelli 4 Intended status: Standards Track IIT-CNR/Registro.it 5 Expires: 3 November 2022 2 May 2022 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-ietf-regext-rdap-reverse-search-11 10 Abstract 12 The Registration Data Access Protocol (RDAP) does not include query 13 capabilities for finding the list of domains related to a set of 14 entities matching a given search pattern. In the RDAP context, an 15 entity can be associated with any defined object class. Moreover, 16 other relationships between object classes exist and might be used 17 for providing a reverse search capability. Therefore, a reverse 18 search can be applied to other use cases than the classic domain- 19 entity scenario. This document describes an RDAP extension that 20 allow servers to provide a reverse search feature based on the 21 relationship defined in RDAP between an object class for search and 22 any related object class. The reverse search based on the domain- 23 entity relationship is treated as a particular case. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 3 November 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 60 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 61 3. RDAP Response Specification . . . . . . . . . . . . . . . . . 5 62 4. Reverse Searches Based on Entity Details . . . . . . . . . . 5 63 5. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 66 7.1. IIT-CNR/Registro.it RDAP Server . . . . . . . . . . . . . 7 67 7.2. IIT-CNR/Registro.it RDAP Client . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 12.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Appendix A. Paradigms to Enforce Access Control on Reverse Search 76 in RDAP . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Reverse Whois is a service provided by many web applications that 83 allows users to find domain names owned by an individual or a company 84 starting from the owner's details, such as name and email. Even if 85 it has been considered useful for some legal purposes (e.g. 86 uncovering trademark infringements, detecting cybercrimes), its 87 availability as a standardized Whois capability has been objected to 88 for two main reasons, which now don't seem to conflict with an RDAP 89 implementation. 91 The first objection concerns the potential risks of privacy 92 violation. However, the domain name community is considering a new 93 generation of Registration Directory Services [ICANN-RDS1] 94 [ICANN-RDS2] [ICANN-RA], which provide access to sensitive data under 95 some permissible purposes and in accordance with appropriate policies 96 for requestor accreditation, authentication and authorization. 97 RDAP's reliance on HTTP means that it can make use of common HTTP- 98 based approaches to authentication and authorization, making it more 99 useful than Whois [RFC3912] in the context of such directory 100 services. Since RDAP consequently permits a reverse search 101 implementation complying with privacy protection principles, this 102 objection is not well-founded. 104 The other objection to the implementation of a reverse search 105 capability has been connected with its impact on server processing. 106 However, the core RDAP specifications already define search queries, 107 with similar processing requirements, so the distinction on which 108 this objection is based is not clear. 110 Reverse searches, such as finding the list of domain names associated 111 with contacts or nameservers, may be useful to registrars as well. 112 Usually, registries adopt out-of-band solutions to provide results to 113 registrars asking for reverse searches on their domains. Possible 114 reasons for such requests are: 116 * the loss of synchronization between the registrar database and the 117 registry database; 118 * the need for such data to perform bulk EPP [RFC5730] updates (e.g. 119 changing the contacts of a set of domains, etc.). 121 Currently, RDAP does not provide any means for a client to search for 122 the collection of domains associated with an entity [RFC9082]. A 123 query (lookup or search) on domains can return the array of entities 124 related to a domain with different roles (registrant, registrar, 125 administrative, technical, reseller, etc.), but the reverse operation 126 is not allowed. Only reverse searches to find the collection of 127 domains related to a nameserver (ldhName or ip) can be requested. 128 Since an entity can be in relationship with any RDAP object 129 [RFC9083], the availability of a reverse search as largely intended 130 can be common to all the object classes allowed for search. Through 131 a further step of generalization, the meaning of reverse search in 132 the RDAP context can be extended to include any query for retrieving 133 all the objects in relationship with another matching a given search 134 pattern. 136 The protocol described in this specification aims to extend the RDAP 137 query capabilities to enable reverse search based on the 138 relationships defined in RDAP between an object class for search and 139 a related object class. The reverse search based on the domain- 140 entity relationship is treated as a particular case of such a generic 141 query model. 143 1.1. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. RDAP Path Segment Specification 153 A generic reverse search path is described by the syntax: 155 {searchable-resource-type}/reverse_search_0/{related-resource- 156 type}? 158 The path segments are defined as in the following: 160 * searchable-resource-type: it MUST be one of the resource types for 161 search defined in Section 3.2 of [RFC9082] (i.e. "domains", 162 "nameservers" and "entities") or a resource type extension; 163 * related-resource-type: it MUST be one of the resource types for 164 lookup defined in Section 3.1 of [RFC9082] (i.e. "domain", 165 "nameserver", "entity", "ip" and "autnum") or a resource type 166 extension; 167 * search-condition: a sequence of "property=search pattern" 168 predicates separated by the ampersand character ('&', US-ASCII 169 value 0x0026). Each "property" represents a JSON object property 170 of the RDAP object class corresponding to "related-resource-type". 171 Objects are only included in the search results if they satisfy 172 all included predicates. This includes predicates that are for 173 the same property: it is necessary in such a case for the related 174 object to match against each of those predicates. Based on their 175 policy, servers MAY restrict the usage of predicates to make a 176 valid search condition, by returning a 400 (Bad Request) response 177 when a problematic request is received. 179 While related-resource-type is defined as having one of a number of 180 different values, the only searches defined in this document are for 181 a related-resource-type of "entity". Searches for the other resource 182 types specified in [RFC9082] and resource type extensions may be 183 defined by future documents. 185 Partial string matching in search patterns is allowed as defined in 186 section 4.1 of [RFC9082]. 188 3. RDAP Response Specification 190 Reverse search responses use the formats defined in section 8 of 191 [RFC9083], which correspond to the searchable resource types defined 192 in Section 2. 194 4. Reverse Searches Based on Entity Details 196 Since in RDAP, an entity can be associated with any other object 197 class, the most common kind of reverse search is one based on an 198 entity's details. Such reverse searches arise from the query model 199 by setting the related resource type to "entity". 201 By selecting a specific searchable resource type, the resulting 202 reverse search aims at retrieving all the objects (e.g. all the 203 domains) that are related to any entity object matching the search 204 conditions. 206 This section defines the following reverse search properties servers 207 SHOULD support regardless of the searchable resource type being 208 selected: 210 Reverse search property: role 211 RDAP property: $..entities[*].roles 212 Reference: Section 10.2.4 of [RFC9083] 214 Reverse search property: handle 215 RDAP property: $..entities[*].handle 216 Reference: Section 5.1 of [RFC9083] 218 Reverse search property: fn 219 RDAP property: $..entities[*].vcardArray[1][?(@[0]=='fn')][3] 220 Reference: Section 6.2.1 of [RFC6350] 222 Reverse search property: email 223 RDAP property: $..entities[*].vcardArray[1][?(@[0]=='email')][3] 224 Reference: Section 6.4.2 of [RFC6350] 226 The mapping between the reverse search property and the corresponding 227 RDAP response property is done through the use of a JSONPath 228 expression [I-D.ietf-jsonpath-base]. 230 The presence of a predicate on the reverse search property "role" 231 means that the RDAP response property "roles" must contain at least 232 the specified role. 234 The last two properties are related to jCard elements [RFC7095], but 235 the field references are to vCard [RFC6350], since jCard is the JSON 236 format for vCard. 238 Examples of reverse search paths based on the domain-entity 239 relationship are presented in Figure 1. 241 /domains/reverse_search_0/entity?handle=CID-40*&role=technical 243 /domains/reverse_search_0/entity?fn=Bobby*&role=registrant 245 /domains/reverse_search_0/entity?handle=RegistrarX&role=registrar 247 Figure 1 249 Documents that deprecate or restructure RDAP responses such that one 250 or more of the properties listed above becomes invalid 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 way of some new RDAP property (in the case of 254 restructuring). 256 A server that includes additional fields in its objects in accordance 257 with the extensibility provisions of section 6 of [RFC7480] MAY 258 support the use of those fields in search conditions, in the same way 259 as for the search conditions defined in this section. Support for 260 such fields in the reverse search context MUST be documented in the 261 extension specification. 263 5. RDAP Conformance 265 Servers complying with this specification MUST include the value 266 "reverse_search_0" in the rdapConformance property of the help 267 response [RFC9083]. The information needed to register this value in 268 the "RDAP Extensions" registry is described in Section 8. 270 6. Implementation Considerations 272 To limit the impact of processing the search predicates, servers are 273 RECOMMENDED to make use of indexes and similar functionality in their 274 underlying data store. In addition, risks with respect to 275 performance degradation or result set generation can be mitigated by 276 adopting practices used for standard searches, e.g. restricting the 277 search functionality, limiting the rate of search requests according 278 to the user's authorization, truncating and paging the results, and 279 returning partial responses. 281 7. Implementation Status 283 NOTE: Please remove this section and the reference to RFC 7942 prior 284 to publication as an RFC. 286 This section records the status of known implementations of the 287 protocol defined by this specification at the time of posting of this 288 Internet-Draft, and is based on a proposal described in [RFC7942]. 289 The description of implementations in this section is intended to 290 assist the IETF in its decision processes in progressing drafts to 291 RFCs. Please note that the listing of any individual implementation 292 here does not imply endorsement by the IETF. Furthermore, no effort 293 has been spent to verify the information presented here that was 294 supplied by IETF contributors. This is not intended as, and must not 295 be construed to be, a catalog of available implementations or their 296 features. Readers are advised to note that other implementations may 297 exist. 299 According to RFC 7942, "this will allow reviewers and working groups 300 to assign due consideration to documents that have the benefit of 301 running code, which may serve as evidence of valuable experimentation 302 and feedback that have made the implemented protocols more mature. 303 It is up to the individual working groups to use this information as 304 they see fit". 306 7.1. IIT-CNR/Registro.it RDAP Server 308 * Responsible Organization: Institute of Informatics and Telematics 309 of National Research Council (IIT-CNR)/Registro.it 310 * Location: https://rdap.pubtest.nic.it/ 311 * Description: This implementation includes support for RDAP queries 312 using data from the public test environment of .it ccTLD. Reverse 313 search is allowed to authenticated users. Registrar users are 314 allowed to perform reverse searches on their own domains and 315 contacts. This is achieved by adding an implicit predicate to the 316 search condition. 317 * Level of Maturity: This is an "alpha" test implementation. 318 * Coverage: This implementation includes all of the features 319 described in this specification. 320 * Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 322 7.2. IIT-CNR/Registro.it RDAP Client 324 * Responsible Organization: Institute of Informatics and Telematics 325 of National Research Council (IIT-CNR)/Registro.it 326 * Location: https://web-rdap.pubtest.nic.it/ 327 * Description: This is a Javascript web-based RDAP client. RDAP 328 responses are retrieved from RDAP servers by the browser, parsed 329 into an HTML representation, and displayed in a format improving 330 the user experience. Reverse search is allowed to authenticated 331 users. 332 * Level of Maturity: This is an "alpha" test implementation. 333 * Coverage: This implementation includes all of the features 334 described in this specification. 335 * Contact Information: Francesco Donini, francesco.donini@iit.cnr.it 337 8. IANA Considerations 339 IANA is requested to register the following value in the RDAP 340 Extensions Registry: 342 * Extension identifier: reverse_search_0 343 * Registry operator: Any 344 * Published specification: This document. 345 * Contact: IETF 346 * Intended usage: This extension describes reverse search query 347 patterns for RDAP. 349 9. Privacy Considerations 351 The search functionality defined in this document may affect the 352 privacy of entities in the registry (and elsewhere) in various ways: 353 see [RFC6973] for a general treatment of privacy in protocol 354 specifications. Registry operators should be aware of the tradeoffs 355 that result from implementation of this functionality. 357 Many jurisdictions have laws or regulations that restrict the use of 358 "Personal Data", per the definition in [RFC6973]. Given that, 359 registry operators should ascertain whether the regulatory 360 environment in which they operate permits implementation of the 361 functionality defined in this document. 363 In general, given the sensitivity of this functionality,it SHOULD be 364 accessible to authorized users only, and for specific use cases only. 366 Since reverse search requests and responses could contain Personally 367 Identifiable Information (PII), reverse search functionality SHOULD 368 be available over HTTPS only. 370 Providing reverse search in RDAP carries the following threats as 371 described in [RFC6973]: 373 * Correlation 374 * Disclosure 375 * Misuse of information 377 Therefore, RDAP providers are REQUIRED to mitigate the risk of those 378 threats by implementing appropriate measures supported by security 379 services (see Section 10). 381 10. Security Considerations 383 Security services required to provide controlled access to the 384 operations specified in this document are described in [RFC7481]. A 385 non-exhaustive list of access control paradigms an RDAP provider can 386 implement is presented in Appendix A. 388 The specification of the relationship within the reverse search path 389 allows the RDAP servers to implement different authorization policies 390 on a per-relationship basis. 392 11. Acknowledgements 394 The authors would like to acknowledge the following individuals for 395 their contributions to this document: Francesco Donini, Scott 396 Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez, Ulrich 397 Wisser and James Gould. 399 Tom Harrison and Jasdip Singh provided relevant feedback and constant 400 support to the implementation of this proposal. Their contributions 401 have been greatly appreciated. 403 12. References 405 12.1. Normative References 407 [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating 408 errata set 1", November 2014, 409 . 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 417 DOI 10.17487/RFC3912, September 2004, 418 . 420 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 421 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 422 . 424 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 425 DOI 10.17487/RFC6350, August 2011, 426 . 428 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 429 Morris, J., Hansen, M., and R. Smith, "Privacy 430 Considerations for Internet Protocols", RFC 6973, 431 DOI 10.17487/RFC6973, July 2013, 432 . 434 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 435 DOI 10.17487/RFC7095, January 2014, 436 . 438 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 439 Registration Data Access Protocol (RDAP)", STD 95, 440 RFC 7480, DOI 10.17487/RFC7480, March 2015, 441 . 443 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 444 Registration Data Access Protocol (RDAP)", STD 95, 445 RFC 7481, DOI 10.17487/RFC7481, March 2015, 446 . 448 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 449 Code: The Implementation Status Section", BCP 205, 450 RFC 7942, DOI 10.17487/RFC7942, July 2016, 451 . 453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 455 May 2017, . 457 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 458 Protocol (RDAP) Query Format", STD 95, RFC 9082, 459 DOI 10.17487/RFC9082, June 2021, 460 . 462 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 463 Registration Data Access Protocol (RDAP)", STD 95, 464 RFC 9083, DOI 10.17487/RFC9083, June 2021, 465 . 467 12.2. Informative References 469 [I-D.ietf-jsonpath-base] 470 Gössner, S., Normington, G., and C. Bormann, "JSONPath: 471 Query expressions for JSON", Work in Progress, Internet- 472 Draft, draft-ietf-jsonpath-base-03, 16 January 2022, 473 . 476 [I-D.ietf-regext-rdap-openid] 477 Hollenbeck, S., "Federated Authentication for the 478 Registration Data Access Protocol (RDAP) using OpenID 479 Connect", Work in Progress, Internet-Draft, draft-ietf- 480 regext-rdap-openid-08, 8 November 2021, 481 . 484 [ICANN-RA] Internet Corporation For Assigned Names and Numbers, 485 "Registry Agreement", July 2017, 486 . 489 [ICANN-RDS1] 490 Internet Corporation For Assigned Names and Numbers, 491 "Final Report from the Expert Working Group on gTLD 492 Directory Services: A Next-Generation Registration 493 Directory Service (RDS)", June 2014, 494 . 497 [ICANN-RDS2] 498 Internet Corporation For Assigned Names and Numbers, 499 "Final Issue Report on a Next-Generation gTLD RDS to 500 Replace WHOIS", October 2015, 501 . 504 Appendix A. Paradigms to Enforce Access Control on Reverse Search in 505 RDAP 507 Access control can be implemented according to different paradigms 508 introducing increasingly stringent rules. The paradigms reported 509 here in the following leverage the capabilities either supported 510 natively or provided as extensions by the OpenID Connect [OIDCC]: 512 * Role-Based Access Control: access rights are granted depending on 513 roles. Generally, this is done by grouping users into fixed 514 categories and assigning static grants to each category. A more 515 dynamic approach can be implemented by using the OpenID Connect 516 "scope" claim; 517 * Purpose-Based Access Control: access rules are based on the notion 518 of purpose, being the intended use of some data by a user. It can 519 be implemented by tagging a request with the usage purpose and 520 making the RDAP server check the compliance between the given 521 purpose and the control rules applied to the data to be returned. 522 The purpose can be stated within an out-of-band process by setting 523 the OpenID Connect RDAP-specific "purpose" claim as defined in 524 [I-D.ietf-regext-rdap-openid]; 525 * Attribute-Based Access Control: rules to manage access rights are 526 evaluated and applied according to specific attributes describing 527 the context within which data are requested. It can be 528 implemented by setting within an out-of-band process additional 529 OpenID Connect claims describing the request context and making 530 the RDAP server check the compliance between the given context and 531 the control rules applied to the data to be returned; 532 * Time-Based Access Control: data access is allowed for a limited 533 time only. It can be implemented by assigning the users with 534 temporary credentials linked to access grants whose scope is 535 limited. 537 Appendix B. Change Log 539 00: Initial working group version ported from draft-loffredo-regext- 540 rdap-reverse-search-04 541 01: Updated "Privacy Considerations" section. 542 02: Revised the text. 543 03: Refactored the query model. 544 04: Keepalive refresh. 545 05: Reorganized "Abstract". Corrected "Conventions Used in This 546 Document" section. Added "RDAP Conformance" section. Changed 547 "IANA Considerations" section. Added references to RFC7095 and 548 RFC8174. Other minor edits. 549 06: Updated "Privacy Considerations", "Security Considerations" and 550 "Acknowledgements" sections. Added some normative and informative 551 references. Added Appendix A. 552 07: Updated normative references. 553 08: Changed "Implementation Status" section. Updated informative 554 references. 555 09: Extended the query model to represent a reverse search based on 556 any relationship between the RDAP object classes. Changed the 557 path segment "role" into a query parameter. 558 10: Updated "Reverse Searches Based on Entity Details" section to 559 consider the use of JSContact format instead of jCard. Added 560 references to JSContact documents. 561 11: Updated the document based on Tom Harrison and James Gould 562 feedback: 563 * Updated section "RDAP Path Segment Specification": 564 - Clarified how servers must evaluate a reverse search 565 including predicates that are for the same property. 567 - Specified the error response servers must return when 568 receiving a wrong reverse search request according to their 569 policy. 570 - Clarified that searchs for the related-resource-type values 571 other than "entity" may be defined in future documents. 572 * Reviewed text in section "Reverse Searches Based on Entity 573 Details" about reverse searches based on custom response 574 extensions. 575 * Removed references to JSContact documents in section "Reverse 576 Searches Based on Entity Details". Moved the mapping between 577 jCard properties used in the RDAP response and JSContact 578 counterparts to draft-ietf-regext-rdap-jscontact. 579 * Added section "RDAP Response Specification". 580 * Changed the text to present reverse search as a single 581 extension with multiple features. 582 * Changed the definition of searchable-resource-type and related- 583 resource-type to consider also the resource type extensions. 584 * Replaced "reverse" with "reverse_search_0" in the generic 585 reverse search path. Updated Figure 1 accordingly. 586 * Removed the phrase "but with a special focus on its privacy 587 implications" from both the "Abstract" and the "Introduction". 588 Moved the mapping between jCard properties used in the RDAP 589 response and JSContact counterparts to draft-ietf-regext-rdap- 590 jscontact. 591 * Reviewed the text of "Privacy Considerations" section. 592 * Text cleaning. 594 Authors' Addresses 596 Mario Loffredo 597 IIT-CNR/Registro.it 598 Via Moruzzi,1 599 56124 Pisa 600 Italy 601 Email: mario.loffredo@iit.cnr.it 602 URI: http://www.iit.cnr.it 604 Maurizio Martinelli 605 IIT-CNR/Registro.it 606 Via Moruzzi,1 607 56124 Pisa 608 Italy 609 Email: maurizio.martinelli@iit.cnr.it 610 URI: http://www.iit.cnr.it