idnits 2.17.1 draft-ietf-regext-rdap-reverse-search-10.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 (8 April 2022) is 721 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 216 -- Looks like a reference, but probably isn't: '0' on line 216 -- Looks like a reference, but probably isn't: '3' on line 216 -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCC' ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-17) exists of draft-ietf-calext-jscontact-00 == Outdated reference: A later version (-21) exists of draft-ietf-jsonpath-base-03 == Outdated reference: A later version (-17) exists of draft-ietf-regext-rdap-jscontact-09 == Outdated reference: A later version (-27) exists of draft-ietf-regext-rdap-openid-08 Summary: 2 errors (**), 0 flaws (~~), 6 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: 10 October 2022 8 April 2022 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-ietf-regext-rdap-reverse-search-10 10 Abstract 12 The Registration Data Access Protocol (RDAP) does not include query 13 capabilities to find the list of domains related to a set of entities 14 matching a given search pattern. In the RDAP context, an entity can 15 be associated with any defined object class. Moreover, other 16 relationships between object classes exist and might be used for 17 providing a reverse search capability. Therefore, a reverse search 18 can be applied to other use cases than the classic domain-entity 19 scenario. This document describes RDAP query extensions that allow 20 servers to provide a reverse search feature based on the relationship 21 defined in RDAP between an object class for search and any related 22 object class. The reverse search based on the domain-entity 23 relationship is treated as a particular case but with a special focus 24 on its privacy implications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 10 October 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 61 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 62 2.1. Reverse Searches Based on Entity Details . . . . . . . . 4 63 3. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 66 5.1. IIT-CNR/Registro.it RDAP Server . . . . . . . . . . . . . 7 67 5.2. IIT-CNR/Registro.it RDAP Client . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.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 . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Reverse Whois is a service provided by many web applications that 83 allow 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 has been caused by the potential risks of privacy 92 violation. However, TLDs community is considering a new generation 93 of Registration Directory Services [ICANN-RDS1] [ICANN-RDS2] 94 [ICANN-RA], which provide access to sensitive data under some 95 permissible purposes and according to adequate policies to enforce 96 the requestor accreditation, authentication, authorization, and terms 97 and conditions of data use. It is well known that such security 98 policies are not implemented in Whois [RFC3912], while they are in 99 RDAP [RFC7481]. Therefore, RDAP permits a reverse search 100 implementation complying with privacy protection principles. 102 The other objection to the implementation of a reverse search 103 capability has been connected with its impact on server processing. 104 Since RDAP supports search queries, the impact of both standard and 105 reverse searches is equivalent and can be mitigated by servers 106 adopting ad hoc strategies. Furthermore, the reverse search is 107 almost always performed by specifying an entity role (e.g. 108 registrant, technical contact) and this can contribute to restricting 109 the result set. 111 Reverse searches, such as finding the list of domain names associated 112 with contacts or nameservers may be useful to registrars as well. 113 Usually, registries adopt out-of-band solutions to provide results to 114 registrars asking for reverse searches on their domains. Possible 115 reasons for such requests are: 117 * the loss of synchronization between the registrar database and the 118 registry database; 119 * the need for such data to perform massive EPP [RFC5730] updates 120 (e.g. changing the contacts of a set of domains, etc.). 122 Currently, RDAP does not provide any means for a client to search for 123 the collection of domains associated with an entity [RFC9082]. A 124 query (lookup or search) on domains can return the array of entities 125 related to a domain with different roles (registrant, registrar, 126 administrative, technical, reseller, etc.), but the reverse operation 127 is not allowed. Only reverse searches to find the collection of 128 domains related to a nameserver (ldhName or ip) can be requested. 129 Since an entity can be in relationship with any RDAP object 130 [RFC9083], the availability of a reverse search as largely intended 131 can be common to all the object classes allowed for search. Through 132 a further step of generalization, the meaning of reverse search in 133 the RDAP context can be extended to include any query for retrieving 134 all the objects in relationship with another matching a given search 135 pattern. 137 The protocol described in this specification aims to extend the RDAP 138 query capabilities to enable the reverse search based on the 139 relationships defined in RDAP between an object class for search and 140 any related object class. The reverse search based on the domain- 141 entity relationship is treated as a particular case of such a generic 142 query model but with a special focus on its privacy implications. 143 The extension is implemented by adding new path segments (i.e. search 144 paths) and using a RESTful web service [REST]. The service is 145 implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] 146 and the conventions described in [RFC7480]. 148 1.1. Conventions Used in This Document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2. RDAP Path Segment Specification 158 The new search paths are OPTIONAL extensions of those defined in 159 [RFC9082]. A generic reverse search path is described by the syntax: 161 {searchable-resource-type}/reverse/{related-resource-type}? 164 The path segments are defined as in the following: 166 * searchable-resource-type: it MUST be one of resource types for 167 search defined in Section 3.2 of [RFC9082], i.e. "domains", 168 "nameservers" and "entities"; 169 * related-resource-type: it MUST be one of the resource types for 170 lookup defined in Section 3.1 of [RFC9082], i.e. "domain", 171 "nameserver", "entity", "ip" and "autnum"; 172 * search-condition: a sequence of "property=search pattern" 173 predicates separated by the ampersand character ('&', US-ASCII 174 value 0x0026). Each "property" represents a JSON object property 175 of the RDAP object class corresponding to "related-resource-type". 176 All the predicates are joined by the AND logical operator. Based 177 on their policy, servers MAY restrict the usage of predicates to 178 make a valid search condition. 180 Partial string matching in search patterns is allowed as defined in 181 section 4.1 of [RFC9082]. 183 2.1. Reverse Searches Based on Entity Details 185 Since in RDAP, an entity can be associated with any other object 186 class, the most common kind of reverse searches are based on the 187 entity details. Such reverse searches arise from the above query 188 model by setting the related resource type to "entity". 190 By selecting a specific searchable resource type, the resulting 191 reverse search aims at retrieving all the objects (e.g. all the 192 domains) that are related to any entity object matching the search 193 condition. 195 This section defines the following reverse search properties to be 196 used regardless of the searchable resource type being selected: 198 Reverse search property: role 199 RDAP property: $..entities[*].roles 200 Reference: Section 10.2.4 of [RFC9083] 202 Reverse search property: handle 203 RDAP property: $..entities[*].handle 204 Reference: Section 5.1 of [RFC9083] 206 Reverse search property: fn 207 Using jCard: 208 RDAP property: $..entities[*].vcardArray[1][?(@[0]=='fn')][3] 209 Reference: Section 6.2.1 of [RFC6350] 210 Using JSContact: 211 RDAP property: $..entities[*].jscard.fullName 212 Reference: Section 2.2.2 of [I-D.ietf-calext-jscontact] 214 Reverse search property: email 215 Using jCard: 216 RDAP property: $..entities[*].vcardArray[1][?(@[0]=='email')][3] 217 Reference: Section 6.4.2 of [RFC6350] 218 Using JSContact: 219 RDAP property: $..entities[*].jscard.emails.[*].email 220 Reference: Section 2.3.1 of [I-D.ietf-calext-jscontact] 222 Regarding the above definitions, it must be noted that: 224 * the mapping between the reverse search property and the 225 corresponding RDAP response property is done through the use of a 226 JSONPath expression [I-D.ietf-jsonpath-base]; 227 * the presence of a predicate on the reverse search property "role" 228 means that the RDAP response property "roles" must contain at 229 least the specified role; 230 * the last two properties are related to jCard elements [RFC7095] 231 but, being jCard the JSON format for vCard, the corresponding 232 reference is to the vCard specification [RFC6350]. Such 233 properties are also shown according to the JSContact format 234 [I-D.ietf-calext-jscontact] to address the case when it is used 235 instead of jCard as described in [I-D.ietf-regext-rdap-jscontact]. 237 Servers MAY implement other properties than those defined in this 238 section. 240 Examples of reverse search paths based on the domain-entity 241 relationship are presented below: 243 /domains/reverse/entity?handle=CID-40*&role=technical 245 /domains/reverse/entity?fn=Bobby*&role=registrant 247 /domains/reverse/entity?handle=RegistrarX&role=registrar 249 Figure 1 251 3. RDAP Conformance 253 Servers complying with this specification MUST include the value 254 "reverse_search_0" in the rdapConformance property of the help 255 response [RFC9083]. The information needed to register this value in 256 the "RDAP Extensions" registry is described in Section 6. 258 4. Implementation Considerations 260 The implementation of the proposed extension is technically feasible. 261 To limit the impact of processing the search predicates, servers are 262 RECOMMENDED to mandate the use of at least one property among those 263 mapped to indexed fields of the registry database. Other properties, 264 such as "role", MAY be allowed to further restrict the set of 265 possible results. In addition, the risks to degrade the performance 266 or to generate huge result sets can be mitigated by adopting the same 267 policies valid for handling searches (e.g. restricting the search 268 functionality, limiting the rate of search requests according to the 269 user profile, truncating and paging the results, returning partial 270 responses). 272 5. Implementation Status 274 NOTE: Please remove this section and the reference to RFC 7942 prior 275 to publication as an RFC. 277 This section records the status of known implementations of the 278 protocol defined by this specification at the time of posting of this 279 Internet-Draft, and is based on a proposal described in [RFC7942]. 280 The description of implementations in this section is intended to 281 assist the IETF in its decision processes in progressing drafts to 282 RFCs. Please note that the listing of any individual implementation 283 here does not imply endorsement by the IETF. Furthermore, no effort 284 has been spent to verify the information presented here that was 285 supplied by IETF contributors. This is not intended as, and must not 286 be construed to be, a catalog of available implementations or their 287 features. Readers are advised to note that other implementations may 288 exist. 290 According to RFC 7942, "this will allow reviewers and working groups 291 to assign due consideration to documents that have the benefit of 292 running code, which may serve as evidence of valuable experimentation 293 and feedback that have made the implemented protocols more mature. 294 It is up to the individual working groups to use this information as 295 they see fit". 297 5.1. IIT-CNR/Registro.it RDAP Server 299 * Responsible Organization: Institute of Informatics and Telematics 300 of National Research Council (IIT-CNR)/Registro.it 301 * Location: https://rdap.pubtest.nic.it/ 302 * Description: This implementation includes support for RDAP queries 303 using data from the public test environment of .it ccTLD. Reverse 304 search is allowed to authenticated users. Registrar users are 305 allowed to perform reverse searches on their own domains and 306 contacts. This is achieved by adding an implicit condition to the 307 search pattern. 308 * Level of Maturity: This is an "alpha" test implementation. 309 * Coverage: This implementation includes all of the features 310 described in this specification. 311 * Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 313 5.2. IIT-CNR/Registro.it RDAP Client 315 * Responsible Organization: Institute of Informatics and Telematics 316 of National Research Council (IIT-CNR)/Registro.it 317 * Location: https://web-rdap.pubtest.nic.it/ 318 * Description: This is a Javascript web-based RDAP client. RDAP 319 responses are retrieved from RDAP servers by the browser, parsed 320 into an HTML representation, and displayed in a format improving 321 the user experience. Reverse search is allowed to authenticated 322 users. 323 * Level of Maturity: This is an "alpha" test implementation. 324 * Coverage: This implementation includes all of the features 325 described in this specification. 326 * Contact Information: Francesco Donini, francesco.donini@iit.cnr.it 328 6. IANA Considerations 330 IANA is requested to register the following value in the RDAP 331 Extensions Registry: 333 * Extension identifier: reverse_search_0 334 * Registry operator: Any 335 * Published specification: This document. 336 * Contact: IETF 337 * Intended usage: This extension describes reverse search query 338 patterns for RDAP. 340 7. Privacy Considerations 342 The use of the capability described in this document whenever a 343 contact detail is taken MUST be compliant with the rules about 344 privacy protection each RDAP provider is subject to. Sensitive 345 registration data MUST be protected and accessible for permissible 346 purposes only. This feature SHOULD be only accessible to authorized 347 users and only for a specified use case. 349 Since the request for this feature could contain Personal 350 Identifiable Information, it SHOULD only be accessible to authorized 351 users and available over HTTPS. 353 Providing reverse search in RDAP carries the following threats as 354 described in [RFC6973]: 356 * Correlation 357 * Disclosure 358 * Misuse of information 360 Therefore, RDAP providers are REQUIRED to mitigate the risk of those 361 threats by implementing appropriate measures supported by security 362 services (see Section 8). 364 8. Security Considerations 366 Security services required to provide controlled access to the 367 operations specified in this document are described in [RFC7481]. A 368 non-exhaustive list of access control paradigms an RDAP provider can 369 implement is presented in Appendix A. 371 The specification of the relationship within the reverse search path 372 allows the RDAP servers to implement different authorization policies 373 on a per-relationship basis. 375 9. Acknowledgements 377 The authors would like to acknowledge the following individuals for 378 their contributions to this document: Francesco Donini, Scott 379 Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez and 380 Ulrich Wisser. 382 Tom Harrison and Jasdip Singh provided relevant feedback and constant 383 support to the implementation of this proposal. Their contributions 384 are greatly appreciated. 386 10. References 388 10.1. Normative References 390 [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating 391 errata set 1", November 2014, 392 . 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 400 DOI 10.17487/RFC3912, September 2004, 401 . 403 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 404 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 405 . 407 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 408 DOI 10.17487/RFC6350, August 2011, 409 . 411 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 412 Morris, J., Hansen, M., and R. Smith, "Privacy 413 Considerations for Internet Protocols", RFC 6973, 414 DOI 10.17487/RFC6973, July 2013, 415 . 417 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 418 DOI 10.17487/RFC7095, January 2014, 419 . 421 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 422 Protocol (HTTP/1.1): Message Syntax and Routing", 423 RFC 7230, DOI 10.17487/RFC7230, June 2014, 424 . 426 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 427 Registration Data Access Protocol (RDAP)", STD 95, 428 RFC 7480, DOI 10.17487/RFC7480, March 2015, 429 . 431 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 432 Registration Data Access Protocol (RDAP)", STD 95, 433 RFC 7481, DOI 10.17487/RFC7481, March 2015, 434 . 436 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 437 Code: The Implementation Status Section", BCP 205, 438 RFC 7942, DOI 10.17487/RFC7942, July 2016, 439 . 441 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 442 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 443 May 2017, . 445 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 446 Protocol (RDAP) Query Format", STD 95, RFC 9082, 447 DOI 10.17487/RFC9082, June 2021, 448 . 450 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 451 Registration Data Access Protocol (RDAP)", STD 95, 452 RFC 9083, DOI 10.17487/RFC9083, June 2021, 453 . 455 10.2. Informative References 457 [I-D.ietf-calext-jscontact] 458 Stepanek, R. and M. Loffredo, "JSContact: A JSON 459 representation of contact data", Work in Progress, 460 Internet-Draft, draft-ietf-calext-jscontact-00, 17 January 461 2020, . 464 [I-D.ietf-jsonpath-base] 465 Gössner, S., Normington, G., and C. Bormann, "JSONPath: 466 Query expressions for JSON", Work in Progress, Internet- 467 Draft, draft-ietf-jsonpath-base-03, 16 January 2022, 468 . 471 [I-D.ietf-regext-rdap-jscontact] 472 Loffredo, M. and G. Brown, "Using JSContact in 473 Registration Data Access Protocol (RDAP) JSON Responses", 474 Work in Progress, Internet-Draft, draft-ietf-regext-rdap- 475 jscontact-09, 7 March 2022, 476 . 479 [I-D.ietf-regext-rdap-openid] 480 Hollenbeck, S., "Federated Authentication for the 481 Registration Data Access Protocol (RDAP) using OpenID 482 Connect", Work in Progress, Internet-Draft, draft-ietf- 483 regext-rdap-openid-08, 8 November 2021, 484 . 487 [ICANN-RA] Internet Corporation For Assigned Names and Numbers, 488 "Registry Agreement", July 2017, 489 . 492 [ICANN-RDS1] 493 Internet Corporation For Assigned Names and Numbers, 494 "Final Report from the Expert Working Group on gTLD 495 Directory Services: A Next-Generation Registration 496 Directory Service (RDS)", June 2014, 497 . 500 [ICANN-RDS2] 501 Internet Corporation For Assigned Names and Numbers, 502 "Final Issue Report on a Next-Generation gTLD RDS to 503 Replace WHOIS", October 2015, 504 . 507 [REST] Fielding, R., "Architectural Styles and the Design of 508 Network-based Software Architectures", 2000, 509 . 512 Appendix A. Paradigms to Enforce Access Control on Reverse Search in 513 RDAP 515 Access control can be implemented according to different paradigms 516 introducing increasingly stringent rules. The paradigms reported 517 here in the following leverage the capabilities either supported 518 natively or provided as extensions by the OpenID Connect [OIDCC]: 520 * Role-Based Access Control: access rights are granted depending on 521 roles. Generally, this is done by grouping users into fixed 522 categories and assigning each category with static grants. A more 523 dynamic approach can be implemented by using the OpenID Connect 524 "scope" claim; 526 * Purpose-Based Access Control: access rules are based on the notion 527 of purpose which means the intended usage of some data by a user. 528 It can be implemented by tagging a request with the usage purpose 529 and making the RDAP server check the compliance between the given 530 purpose and the control rules applied to data to be returned. The 531 purpose can be stated within an out-of-band process by setting the 532 OpenID Connect RDAP specific "purpose" claim as defined in 533 [I-D.ietf-regext-rdap-openid]; 534 * Attribute-Based Access Control: rules to manage access rights are 535 evaluated and applied according to specific attributes describing 536 the context within which data are requested. It can be 537 implemented by setting within an out-of-band process additional 538 OpenID Connect claims describing the request context and making 539 the RDAP server check the compliance between the given context and 540 the control rules applied to data to be returned; 541 * Time-Based Access Control: data access is allowed for a limited 542 time only. It can be implemented by assigning the users with 543 temporary credentials linked to access grants whose scope is 544 limited. 546 Appendix B. Change Log 548 00: Initial working group version ported from draft-loffredo-regext- 549 rdap-reverse-search-04 550 01: Updated "Privacy Considerations" section. 551 02: Revised the text. 552 03: Refactored the query model. 553 04: Keepalive refresh. 554 05: Reorganized "Abstract". Corrected "Conventions Used in This 555 Document" section. Added "RDAP Conformance" section. Changed 556 "IANA Considerations" section. Added references to RFC7095 and 557 RFC8174. Other minor edits. 558 06: Updated "Privacy Considerations", "Security Considerations" and 559 "Acknowledgements" sections. Added some normative and informative 560 references. Added Appendix A. 561 07: Updated normative references. 562 08: Changed "Implementation Status" section. Updated informative 563 references. 564 09: Extended the query model to represent a reverse search based on 565 any relationship between the RDAP object classes. Changed the 566 path segment "role" into a query parameter. 567 10: Updated "Reverse Searches Based on Entity Details" section to 568 consider the use of JSContact format instead of jCard. Added 569 references to JSContact documents. 571 Authors' Addresses 572 Mario Loffredo 573 IIT-CNR/Registro.it 574 Via Moruzzi,1 575 56124 Pisa 576 Italy 577 Email: mario.loffredo@iit.cnr.it 578 URI: http://www.iit.cnr.it 580 Maurizio Martinelli 581 IIT-CNR/Registro.it 582 Via Moruzzi,1 583 56124 Pisa 584 Italy 585 Email: maurizio.martinelli@iit.cnr.it 586 URI: http://www.iit.cnr.it