rfc9536xml2.original.xml   rfc9536.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" <!DOCTYPE rfc [
[ <!ENTITY nbsp "&#160;">
<!ENTITY RFC2119 PUBLIC '' <!ENTITY zwsp "&#8203;">
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3912 PUBLIC '' <!ENTITY wj "&#8288;">
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml'>
<!ENTITY RFC5730 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml'>
<!ENTITY RFC6350 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml'>
<!ENTITY RFC6973 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml'>
<!ENTITY RFC7095 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7095.xml'>
<!ENTITY RFC7481 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7481.xml'>
<!ENTITY RFC7942 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml'>
<!ENTITY RFC8126 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml'>
<!ENTITY RFC8174 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'>
<!ENTITY RFC8977 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8977.xml'>
<!ENTITY RFC8982 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8982.xml'>
<!ENTITY RFC9082 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9082.xml'>
<!ENTITY RFC9083 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9083.xml'>
<!ENTITY RFC9110 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9110.xml'>
<!ENTITY I-D.ietf-jsonpath-base PUBLIC ''
'https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-jsonpath-base.xml'>
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc tocompact="yes"?> std" consensus="true" docName="draft-ietf-regext-rdap-reverse-search-25" number=
<?rfc tocdepth="4"?> "9536" ipr="trust200902" tocInclude="true" tocDepth="4" sortRefs="true" symRefs=
<?rfc compact="yes"?> "true" updates="" obsoletes="" xml:lang="en" version="3">
<?rfc subcompact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc iprnotified="no"?>
<rfc category="std" docName="draft-ietf-regext-rdap-reverse-search-25" ipr="trus t200902" submissionType="IETF" consensus="true"> <!-- xml2rfc v2v3 conversion 3.18.0 -->
<front> <front>
<title abbrev="RDAP Reverse search">Registration Data Access Protocol (RDAP) <title abbrev="RDAP Reverse Search">Registration Data Access Protocol (RDAP)
Reverse Search</title> Reverse Search</title>
<seriesInfo name="RFC" value="9536"/>
<author fullname="Mario Loffredo" initials="M." surname="Loffredo"> <author fullname="Mario Loffredo" initials="M." surname="Loffredo">
<organization>IIT-CNR/Registro.it</organization> <organization>IIT-CNR/Registro.it</organization>
<address> <address>
<postal> <postal>
<street>Via Moruzzi,1</street> <street>Via Moruzzi,1</street>
<city>Pisa</city> <city>Pisa</city>
<country>IT</country> <country>Italy</country>
<code>56124</code> <code>56124</code>
</postal> </postal>
<email>mario.loffredo@iit.cnr.it</email> <email>mario.loffredo@iit.cnr.it</email>
<uri>http://www.iit.cnr.it</uri> <uri>http://www.iit.cnr.it</uri>
</address> </address>
</author> </author>
<author fullname="Maurizio Martinelli" initials="M." surname="Martinelli"> <author fullname="Maurizio Martinelli" initials="M." surname="Martinelli">
<organization>IIT-CNR/Registro.it</organization> <organization>IIT-CNR/Registro.it</organization>
<address> <address>
<postal> <postal>
<street>Via Moruzzi,1</street> <street>Via Moruzzi,1</street>
<city>Pisa</city> <city>Pisa</city>
<country>IT</country> <country>Italy</country>
<code>56124</code> <code>56124</code>
</postal> </postal>
<email>maurizio.martinelli@iit.cnr.it</email> <email>maurizio.martinelli@iit.cnr.it</email>
<uri>http://www.iit.cnr.it</uri> <uri>http://www.iit.cnr.it</uri>
</address> </address>
</author> </author>
<date year="2024" month="March" />
<date/> <area>art</area>
<area>Applications and Real-Time</area> <workgroup>regext</workgroup>
<workgroup>Registration Protocols Extensions</workgroup>
<keyword>RDAP</keyword> <keyword>RDAP</keyword>
<keyword>Reverse search</keyword> <keyword>Reverse search</keyword>
<abstract>
<abstract> <t>The Registration Data Access Protocol (RDAP) does not include query cap
<t>The Registration Data Access Protocol (RDAP) does not include query abilities for finding the list of domains related to a set of entities matching
capabilities for finding the list of domains related to a set of entities match a given search pattern. Considering that an RDAP entity can be associated with
ing a given search pattern. Considering that an RDAP entity can be associated w any defined object class and other relationships between RDAP object classes exi
ith any defined object class and other relationships between RDAP object classes st, a reverse search can be applied to other use cases besides the classic domai
exist, a reverse search can be applied to other use cases besides the classic d n-entity scenario. This document describes an RDAP extension that allows server
omain-entity scenario. This document describes an RDAP extension that allows se s to provide a reverse search feature based on the relationship defined in RDAP
rvers to provide a reverse search feature based on the relationship defined in R between an object class for search and any related object class. The reverse se
DAP between an object class for search and any related object class. The revers arch based on the domain-entity relationship is treated as a particular case.</t
e search based on the domain-entity relationship is treated as a particular case >
.</t> </abstract>
</abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction">
<name>Introduction</name>
<t>The protocol described in this specification aims to extend the RDAP <t>The protocol described in this specification aims to extend the RDAP qu
query capabilities and response to enable reverse search based on the relationsh ery capabilities and response to enable reverse search based on the relationship
ips defined in RDAP between an object class for search and a related object clas s defined in RDAP between an object class for search and a related object class.
s. The reverse search based on the domain-entity relationship is treated as a p The reverse search based on the domain-entity relationship is treated as a par
articular case of such a generic model.</t> ticular case of such a generic model.</t>
<t>RDAP providers willing to implement this specification should carefully
<t>RDAP providers willing to implement this specification should careful consider its implications on the efficiency (see <xref target="impl-considerati
ly consider its implications on the efficiency (see <xref target="impl-considera ons"/>), the security (see <xref target="security-considerations"/>), and the co
tions"/>), the security (see <xref target="security-considerations"/>) and the c mpliance with privacy regulations (see <xref target="privacy-considerations"/>)
ompliance with privacy regulations (see <xref target="privacy-considerations"/>) of their RDAP service.</t>
of their RDAP service.</t> <section anchor="background">
<name>Background</name>
<section anchor="background" title="Background"> <t>Reverse WHOIS is a service provided by many web applications that all
<t>Reverse Whois is a service provided by many web applications that all ows users to find domain names owned by an individual or a company starting from
ows users to find domain names owned by an individual or a company starting from the owner's details, such as name and email. Even if it has been considered us
the owner's details, such as name and email. Even if it has been considered us eful for some legal purposes (e.g., uncovering trademark infringements and detec
eful for some legal purposes (e.g. uncovering trademark infringements, detecting ting cybercrimes), its availability as a standardized WHOIS <xref target="RFC391
cybercrimes), its availability as a standardized Whois <xref target="RFC3912"/> 2"/> capability has been objected to for two main reasons, which now don't seem
capability has been objected to for two main reasons, which now don't seem to c to conflict with an RDAP implementation.</t>
onflict with an RDAP implementation.</t> <t>The first objection concerns the potential risks of privacy violation
. However, the domain name community is considering a new generation of Registr
<t>The first objection concerns the potential risks of privacy violation. ation Directory Services <xref target="ICANN-RDS"/> <xref target="ICANN-RA"/> th
However, the domain name community is considering a new generation of Registrat at provide access to sensitive data under some permissible purposes and in accor
ion Directory Services <xref target="ICANN-RDS1"/> <xref target="ICANN-RDS2"/> < dance with appropriate policies for requestor accreditation, authentication, and
xref target="ICANN-RA"/>, which provide access to sensitive data under some perm authorization. RDAP's reliance on HTTP means that it can make use of common HT
issible purposes and in accordance with appropriate policies for requestor accre TP-based approaches to authentication and authorization, making it more useful t
ditation, authentication and authorization. RDAP's reliance on HTTP means that han WHOIS in the context of such directory services. Since RDAP consequently pe
it can make use of common HTTP-based approaches to authentication and authorizat rmits a reverse search implementation complying with privacy protection principl
ion, making it more useful than Whois in the context of such directory services. es, this first objection is not well-founded.</t>
Since RDAP consequently permits a reverse search implementation complying with <t>The second objection to the implementation of a reverse search capabi
privacy protection principles, this first objection is not well-founded.</t> lity has been connected with its impact on server processing. However, the core
RDAP specifications already define search queries, with similar processing requ
<t>The second objection to the implementation of a reverse search capabili irements, so the basis of this objection is not clear.</t>
ty has been connected with its impact on server processing. However, the core R <t>Reverse searches, such as finding the list of domain names associated
DAP specifications already define search queries, with similar processing requir with contacts or nameservers, may be useful to registrars as well. Usually, re
ements, so the basis of this objection is not clear.</t> gistries adopt out-of-band solutions to provide results to registrars asking for
reverse searches on their domains. Possible reasons for such requests are:</t>
<t>Reverse searches, such as finding the list of domain names associated w <ul spacing="normal">
ith contacts or nameservers, may be useful to registrars as well. Usually, regi <li>the loss of synchronization between the registrar database and the
stries adopt out-of-band solutions to provide results to registrars asking for r registry database and
everse searches on their domains. Possible reasons for such requests are:</t> </li>
<li>the need for such data to perform bulk Extensible Provisioning Pro
<t><list style="symbols"> tocol (EPP) <xref target="RFC5730"/> updates (e.g., changing the contacts of a s
<t>the loss of synchronization between the registrar database and the r et of domains, etc.).</li>
egistry database;<vspace blankLines='1' /></t> </ul>
<t>the need for such data to perform bulk Extensible Provisioning Proto <t>Currently, RDAP does not provide any means for a client to search for
col (EPP) <xref target="RFC5730"/> updates (e.g. changing the contacts of a set the collection of domains associated with an entity <xref target="RFC9082"/>.
of domains, etc.).</t> A query (lookup or search) on domains can return the array of entities related t
</list></t> o a domain with different roles (registrant, registrar, administrative, technica
l, reseller, etc.), but the reverse operation is not allowed. Only reverse sear
<t>Currently, RDAP does not provide any means for a client to search for t ches to find the collection of domains related to a nameserver (ldhName or ip) c
he collection of domains associated with an entity <xref target="RFC9082"/>. A an be requested. Since an entity can be in relationship with any RDAP object <x
query (lookup or search) on domains can return the array of entities related to ref target="RFC9083"/>, the availability of a reverse search as largely intended
a domain with different roles (registrant, registrar, administrative, technical, can be common to all the object classes allowed for search.
reseller, etc.), but the reverse operation is not allowed. Only reverse search Through a further step of generalization, the meaning of reverse search
es to find the collection of domains related to a nameserver (ldhName or ip) can in the RDAP context can be extended to include any query for retrieving
be requested. Since an entity can be in relationship with any RDAP object <xre all the objects that relates to another query matching a given
f target="RFC9083"/>, the availability of a reverse search as largely intended c search pattern.</t>
an be common to all the object classes allowed for search. Through a further st
ep of generalization, the meaning of reverse search in the RDAP context can be e
xtended to include any query for retrieving all the objects in relationship with
another matching a given search pattern.</t>
</section>
<section title="Conventions Used in This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT
", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONA
L" in this document are to be interpreted as described in BCP 14 <xref target="R
FC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capit
als, as shown here.</t>
</section>
</section>
<section anchor="reverse-search-path-segment-specification" title="Reverse
Search Path Segment Specification">
<t>A generic reverse search path is described by the syntax:</t>
<t>{searchable-resource-type}/reverse_search/{related-resource-typ
e}?&lt;search-condition&gt;</t>
<t>The path segments are defined as in the following:</t>
<t>
<list style="hanging">
<t hangText="&quot;searchable-resource-type&quot;:">it MUST be o
ne of the resource types for search defined in Section 3.2 of <xref target="RFC9
082"/> (i.e. &quot;domains&quot;, &quot;nameservers&quot; and &quot;entities&quo
t;) or a resource type extension;<vspace blankLines='1'/></t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;related-resource-type&quot;:">it MUST be one
of the resource types for lookup defined in Section 3.1 of <xref target="RFC9082
"/> (i.e. &quot;domain&quot;, &quot;nameserver&quot;, &quot;entity&quot;, &quot;
ip&quot; and &quot;autnum&quot;) or a resource type extension;<vspace blankLines
='1'/></t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;search-condition&quot;:">a sequence of &quot;
property=search pattern&quot; predicates separated by the ampersand character ('
&amp;', US-ASCII value 0x0026).</t>
</list>
</t>
<t>While related-resource-type is defined as having one of a number of
different values, the only reverse searches defined in this document are for a
related-resource-type of &quot;entity&quot;. Reverse searches for the other res
ource types specified in <xref target="RFC9082"/> and resource type extensions m
ay be defined by future documents.</t>
</section>
<section anchor="reverse-search-definition" title="Reverse Search Definiti
on">
<t>Based on the content of <xref target="reverse-search-path-segment-spec
ification"/>, defining a reverse search means to define the triple &lt;searchabl
e resource type, related resource type, property&gt; and the mapping with the co
rresponding RDAP object member. The mapping is done through the use of a JSONPa
th expression <xref target="I-D.ietf-jsonpath-base"/>. Reverse searches are reg
istered in the Reverse Search registry (see <xref target="rdap-reverse-search-re
gistry" />), whereas reverse search mappings are registered in the Reverse Searc
h Mapping registry (see <xref target="rdap-reverse-search-mapping-registry"/>).
The reason for having two registries is that it may be possible for a single ty
pe of reverse search to rely on different members, depending on the server's con
figuration (see <xref target="reverse-search-properties-mapping" />).</t>
<t>All of the reverse searches defined by this document (see <xref target
="reverse-search-on-entities"/>) have property names that are the same as the na
me of the RDAP object member that is the subject of the search. For example, th
e reverse search with the property name &quot;fn&quot; relies on the value of th
e &quot;fn&quot; member inside the jCard of an entity object. However, it is no
t necessary that these two names be the same. In particular, remapping of searc
hes as part of the deprecation of an existing member (see <xref target="reverse-
search-properties-mapping"/>) will typically lead to a member with a different n
ame being used for the search.</t>
<t>Servers MUST NOT provide or implement reverse searches or reverse sea
rch mappings that are not registered with IANA.</t>
</section> </section>
<section>
<section anchor="reverse-search-properties-discovery" title="Reverse Searc <name>Conventions Used in This Document</name>
h Properties Discovery"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
<t>Servers complying with this specification MUST extend the help resp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1
onse <xref target="RFC9083"/> with the &quot;reverse_search_properties&quot; mem 4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<
ber which contains an array of objects with the following mandatory child member bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1
s:</t> 4>" in this document are to be interpreted as described in BCP&nbsp;14 <xref tar
<t> get="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
<list style="hanging"> capitals, as shown here.</t>
<t hangText="&quot;searchableResourceType&quot;:">the searchab
le resource type of the reverse search query as defined in <xref target="reverse
-search-path-segment-specification"/>;</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;relatedResourceType&quot;:">the related res
ource type of the reverse search query as defined in <xref target="reverse-searc
h-path-segment-specification"/>;</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;property&quot;:">the reverse search propert
y used in the predicate of the reverse search query as defined in <xref target="
reverse-search-path-segment-specification"/>;</t>
</list>
</t>
<t>An example of the help response including the &quot;reverse_search_
properties&quot; member is shown in <xref target="reverse-search-properties-exam
ple"/>.</t>
</section> </section>
</section>
<section anchor="reverse-search-path-segment-specification">
<name>Reverse Search Path Segment Specification</name>
<t>A generic reverse search path is described by the syntax:</t>
<t>{searchable-resource-type}/reverse_search/{related-resource-type}?&lt;s
earch-condition&gt;</t>
<t>The path segments are defined as follows:</t>
<dl newline="false" spacing="normal">
<dt>"searchable-resource-type":</dt>
<dd>It <bcp14>MUST</bcp14> be one of the resource types for search defin
ed in <xref target="RFC9082" section="3.2" sectionFormat="of" /> (i.e., "domains
", "nameservers", and "entities") or a resource type extension.
</dd>
<dt>"related-resource-type":</dt>
<dd>It <bcp14>MUST</bcp14> be one of the resource types for lookup defin
ed in <xref target="RFC9082" section="3.1" sectionFormat="of" /> (i.e., "domain"
, "nameserver", "entity", "ip", and "autnum") or a resource type extension.
</dd>
<dt>"search-condition":</dt>
<dd>A sequence of "property=search pattern" predicates separated by the
ampersand character ('&amp;', US-ASCII value 0x0026).</dd>
</dl>
<t>While related-resource-type is defined as having one of a number of dif
ferent values, the only reverse searches defined in this document are for a rela
ted-resource-type of "entity". Reverse searches for the other resource types sp
ecified in <xref target="RFC9082"/> and resource type extensions may be defined
by future documents.</t>
</section>
<section anchor="reverse-search-definition">
<name>Reverse Search Definition</name>
<t>Based on the content of <xref target="reverse-search-path-segment-speci
fication"/>, defining a reverse search means to define the triple &lt;searchable
resource type, related resource type, property&gt; and the mapping with the cor
responding RDAP object member. The mapping is done through the use of a JSONPat
h expression <xref target="RFC9535"/>. Reverse searches are registered in the "
RDAP Reverse Search" registry (see <xref target="rdap-reverse-search-registry"/>
), whereas reverse search mappings are registered in the "RDAP Reverse Search Ma
pping" registry (see <xref target="rdap-reverse-search-mapping-registry"/>). Th
e reason for having two registries is that it may be possible for a single type
of reverse search to rely on different members, depending on the server's config
uration (see <xref target="reverse-search-properties-mapping"/>).</t>
<section anchor="reverse-search-properties-mapping" title="Reverse Search <t>All of the reverse searches defined by this document (see <xref target=
Properties Mapping"> "reverse-search-on-entities"/>) have property names that are the same as the nam
<t>To permit clients to determine the member used by the server for a e of the RDAP object member that is the subject of the search. For example, the
reverse search, servers MUST detail the mapping that is occurring by adding the reverse search with the property name "fn" relies on the value of the "fn" memb
&quot;reverse_search_properties_mapping&quot; member to the topmost object of a er inside the jCard of an entity object. However, it is not necessary that thes
reverse search response. This data is included in the search response, rather e two names be the same. In particular, remapping of searches as part of the de
precation of an existing member (see <xref target="reverse-search-properties-map
ping"/>) will typically lead to a member with a different name being used for th
e search.</t>
<t>Servers <bcp14>MUST NOT</bcp14> provide or implement reverse searches o
r reverse search mappings that are not registered with IANA.</t>
</section>
<section anchor="reverse-search-properties-discovery">
<name>Reverse Search Properties Discovery</name>
<t>Servers complying with this specification <bcp14>MUST</bcp14> extend th
e help response <xref target="RFC9083"/> with the "reverse_search_properties" me
mber that contains an array of objects with the following mandatory child member
s:</t>
<dl newline="false" spacing="normal">
<dt>"searchableResourceType":</dt>
<dd>the searchable resource type of the reverse search query, as defined
in <xref target="reverse-search-path-segment-specification"/></dd>
<dt>"relatedResourceType":</dt>
<dd>the related resource type of the reverse search query, as defined in
<xref target="reverse-search-path-segment-specification"/></dd>
<dt>"property":</dt>
<dd>the reverse search property used in the predicate of the reverse sea
rch query, as defined in <xref target="reverse-search-path-segment-specification
"/></dd>
</dl>
<t>An example of the help response including the "reverse_search_propertie
s" member is shown in <xref target="reverse-search-properties-example"/></t>
</section>
<section anchor="reverse-search-properties-mapping">
<name>Reverse Search Properties Mapping</name>
<t>To permit clients to determine the member used by the server for a reve
rse search, servers <bcp14>MUST</bcp14> detail the mapping that is occurring by
adding the "reverse_search_properties_mapping" member to the topmost object of a
reverse search response.
This data structure is included in the search response, rather
than in the help response, because it may differ depending on the query that is sent to the server.</t> than in the help response, because it may differ depending on the query that is sent to the server.</t>
<t>Documents that deprecate or restructure RDAP responses such that a regi
<t>Documents that deprecate or restructure RDAP responses such that a stered reverse search is no longer able to be used <bcp14>MUST</bcp14> either no
registered reverse search is no longer able to be used MUST either note that the te that the relevant reverse search is no longer available (in the case of depre
relevant reverse search is no longer available (in the case of deprecation) or cation) or describe how to continue supporting the relevant search by adding ano
describe how to continue supporting the relevant search by adding another mappin ther mapping for the reverse search property (in the case of restructuring).</t>
g for the reverse search property (in the case of restructuring).</t> <t>The "reverse_search_properties_mapping" member contains an array of obj
ects with the following mandatory child members:</t>
<t>The "reverse_search_properties_mapping" member contains an array of <dl newline="false" spacing="normal">
objects with the following mandatory child members:</t> <dt>"property":</dt>
<t> <dd>the reverse search property used in the predicate of the current que
<list style="hanging"> ry, as defined in <xref target="reverse-search-path-segment-specification"/></dd
<t hangText="&quot;property&quot;:">the reverse search propert >
y used in the predicate of the current query as defined in <xref target="reverse <dt>"propertyPath":</dt>
-search-path-segment-specification"/>;</t> <dd>the JSONPath expression of the object member (or members) correspond
</list> ing to the reverse search property</dd>
</t> </dl>
<t> <t>The searchable and the related resource types are derived from the quer
<list style="hanging"> y, so there is no need to include them in addition to the property in this membe
<t hangText="&quot;propertyPath&quot;:">the JSONPath expressio r.</t>
n of the object member (or members) corresponding to the reverse search property <t>This member <bcp14>MUST</bcp14> be included for all properties used in
.</t> the search, regardless of whether that property has multiple registered mappings
</list> as at the time of the search, because new mappings may be registered at any tim
</t> e.</t>
<t>When applied to an object, the JSONPath expression <bcp14>MUST</bcp14>
<t>The searchable and the related resource types are derived from the produce a list of values, each of which is a JSON number or string.</t>
query, so there is no need to include them in addition to the property in this m <t>An example of a reverse search response including the "reverse_search_p
ember.</t> roperties_mapping" member is shown in <xref target="reverse-search-properties-ma
pping-example"/>.</t>
<t>This member MUST be included for all properties used in the search, </section>
regardless of whether that property has multiple registered mappings as at the <section anchor="reverse-search-response-specification">
time of the search, because new mappings may be registered at any time.</t> <name>Reverse Search Response Specification</name>
<t>Reverse search responses use the formats defined in <xref target="RFC90
<t>When applied to an object, the JSONPath expression MUST produce a l 83" section="8" sectionFormat="of" />, which correspond to the searchable resour
ist of values, each of which is a JSON number or string.</t> ce types defined in <xref target="reverse-search-path-segment-specification"/>.<
/t>
<t>An example of a reverse search response including the &quot;reverse </section>
_search_properties_mapping&quot; member is shown in <xref target="reverse-search <section anchor="reverse-search-query-processing">
-properties-mapping-example"/>.</t> <name>Reverse Search Query Processing</name>
</section> <t>To process a reverse search, the server returns the objects from its da
ta store that are of type searchable-resource-type and that match each of the pr
<section anchor="reverse-search-response-specification" title="Reverse Sea edicates from the search conditions. To determine whether an object matches a p
rch Response Specification"> redicate, the server:</t>
<t>Reverse search responses use the formats defined in section 8 of <xre <ul spacing="normal">
f target="RFC9083"/>, which correspond to the searchable resource types defined <li>applies the mapping it uses for the reverse search property to the o
in <xref target="reverse-search-path-segment-specification"/>.</t> bject in order to generate a list of values, each of which <bcp14>MUST</bcp14> b
</section> e a JSON number or string and</li>
<li>checks whether the search pattern matches one or more of those value
<section anchor="reverse-search-query-processing" title="Reverse Search Qu s.</li>
ery Processing"> </ul>
<t>To process a reverse search, the server returns the objects from its <t>A search pattern matches a value where it equals the string representat
data store that are of type searchable-resource-type and that match each of the ion of the value or where it is a match for the value in accordance with the par
predicates from the search conditions. To determine whether an object matches a tial string matching behavior defined in <xref target="RFC9082" section="4.1" se
predicate, the server:</t> ctionFormat="of" />.</t>
<list style="symbols"> <t>Objects are only included in the search results if they satisfy all inc
<t>applies the mapping it uses for the reverse search property t luded predicates. This includes predicates that are for the same property; in s
o the object in order to generate a list of values, each of which MUST be a JSON uch a case, it is necessary for the related object to match against each of thos
number or string; and</t> e predicates.</t>
<t>checks whether the search pattern matches one or more of thos <t>Servers <bcp14>MUST</bcp14> return an HTTP 501 (Not Implemented) <xref
e values.</t> target="RFC9110"/> response to inform clients of unsupported reverse searches.</
</list> t>
<t>Based on their policy, servers <bcp14>MAY</bcp14> restrict how predicat
<t>A search pattern matches a value where it equals the string represent es are used to make a valid search condition by returning a 400 (Bad Request) re
ation of the value, or where it is a match for the value in accordance with the sponse when a problematic request is received.</t>
partial string matching behaviour defined in section 4.1 of <xref target="RFC908 <t>A given reverse search or reverse search mapping <bcp14>MAY</bcp14> def
2" />.</t> ine additional or alternative search behavior past that set out in this section.
</t>
<t>Objects are only included in the search results if they satisfy all i </section>
ncluded predicates. This includes predicates that are for the same property: it <section anchor="reverse-search-on-entities">
is necessary in such a case for the related object to match against each of tho <name>Reverse Searches Based on Entity Details</name>
se predicates.</t> <t>Since an entity can be associated with any other object class in RDAP,
the most common kind of reverse search is one based on an entity's details. Suc
<t>Servers MUST return an HTTP 501 (Not Implemented) <xref target="RFC91 h reverse searches arise from the query model by setting the related resource ty
10"/> response to inform clients of unsupported reverse searches.</t> pe to "entity".</t>
<t>By selecting a specific searchable resource type, the resulting reverse
<t>Based on their policy, servers MAY restrict how predicates are used t search aims at retrieving all the objects (e.g., all the domains) that are rela
o make a valid search condition, by returning a 400 (Bad Request) response when ted to any entity object matching the search conditions.</t>
a problematic request is received.</t> <t>This section defines the reverse search properties servers <bcp14>SHOUL
D</bcp14> support for the domain, nameserver, entity-searchable resource types,
<t>A given reverse search or reverse search mapping MAY define additiona and entity-related resource type:</t>
l or alternative search behaviour past that set out in this section.</t> <dl newline="false" spacing="compact">
</section> <dt>Reverse search property:</dt>
<dd>role</dd>
<section anchor="reverse-search-on-entities" title="Reverse Searches Based <dt>RDAP member path:</dt>
on Entity Details"> <dd>$.entities[*].roles</dd>
<dt>Reference:</dt>
<t>Since in RDAP, an entity can be associated with any other object clas <dd><xref target="RFC9083" section="10.2.4" sectionFormat="of" /></dd>
s, the most common kind of reverse search is one based on an entity's details. </dl>
Such reverse searches arise from the query model by setting the related resource <dl newline="false" spacing="compact">
type to &quot;entity&quot;.</t> <dt>Reverse search property:</dt>
<t>By selecting a specific searchable resource type, the resulting rever <dd>handle</dd>
se search aims at retrieving all the objects (e.g. all the domains) that are rel <dt>RDAP member path:</dt>
ated to any entity object matching the search conditions.</t> <dd>$.entities[*].handle</dd>
<t>This section defines the reverse search properties servers SHOULD sup <dt>Reference:</dt>
port for the domain, nameserver, and entity searchable resource types and the en <dd><xref target="RFC9083" section="5.1" sectionFormat="of" /></dd>
tity related resource type:</t> </dl>
<dl newline="false" spacing="compact">
<t> <dt>Reverse search property:</dt>
<list style="hanging"> <dd>fn</dd>
<t hangText="Reverse search property:">role</t> <dt>RDAP member path:</dt>
<t hangText="RDAP member path:">$.entities[*].roles</t> <dd>$.entities[*].vcardArray[1][?(@[0]=='fn')][3]</dd>
<t hangText="Reference:">Section 10.2.4 of <xref target="RFC9083 <dt>Reference:</dt>
"/></t> <dd><xref target="RFC6350" section="6.2.1" sectionFormat="of" /></dd>
</list> </dl>
</t> <dl newline="false" spacing="compact">
<t> <dt>Reverse search property:</dt>
<list style="hanging"> <dd>email</dd>
<t hangText="Reverse search property:">handle</t> <dt>RDAP member path:</dt>
<t hangText="RDAP member path:">$.entities[*].handle</t> <dd>$.entities[*].vcardArray[1][?(@[0]=='email')][3]</dd>
<t hangText="Reference:">Section 5.1 of <xref target="RFC9083"/> <dt>Reference:</dt>
</t> <dd><xref target="RFC6350" section="6.4.2" sectionFormat="of" /></dd>
</list> </dl>
</t> <t>The presence of a predicate on the reverse search property "role" means
<t> that the RDAP response property "roles" <bcp14>MUST</bcp14> contain at least th
<list style="hanging"> e specified role.</t>
<t hangText="Reverse search property:">fn</t> <t>The last two properties are related to jCard elements <xref target="RFC
<t hangText="RDAP member path:">$.entities[*].vcardArray[1][?(@[ 7095"/>, but the field references are to vCard <xref target="RFC6350"/>, since j
0]=='fn')][3]</t> Card is the JSON format for vCard.</t>
<t hangText="Reference:">Section 6.2.1 of <xref target="RFC6350" <t>Examples of reverse search paths based on the domain-entity relationshi
/></t> p are presented in <xref target="reverse-search-request"/>.</t>
</list> <figure anchor="reverse-search-request">
</t> <name>Examples of Reverse Search Queries</name>
<t> <artwork><![CDATA[
<list style="hanging">
<t hangText="Reverse search property:">email</t>
<t hangText="RDAP member path:">$.entities[*].vcardArray[1][?(@[
0]=='email')][3]</t>
<t hangText="Reference:">Section 6.4.2 of <xref target="RFC6350"
/></t>
</list>
</t>
<t>The presence of a predicate on the reverse search property &quot;role
&quot; means that the RDAP response property &quot;roles&quot; MUST contain at l
east the specified role.</t>
<t>The last two properties are related to jCard elements <xref target="R
FC7095"/>, but the field references are to vCard <xref target="RFC6350"/>, since
jCard is the JSON format for vCard.</t>
<t>Examples of reverse search paths based on the domain-entity relations
hip are presented in <xref target="reverse-search-request"/>.</t>
<figure anchor="reverse-search-request" title="Examples of reverse sea
rch queries">
<artwork xml:space="preserve"><![CDATA[
/domains/reverse_search/entity?handle=CID-40*&role=technical /domains/reverse_search/entity?handle=CID-40*&role=technical
/domains/reverse_search/entity?fn=Bobby*&role=registrant /domains/reverse_search/entity?fn=Bobby*&role=registrant
/domains/reverse_search/entity?handle=RegistrarX&role=registrar /domains/reverse_search/entity?handle=RegistrarX&role=registrar
]]></artwork> ]]></artwork>
</figure> </figure>
<t>An example of the help response including the supported reverse search
<t>An example of the help response including the reverse search proper properties is shown in <xref target="reverse-search-properties-example"/>.</t>
ties supported is shown below.</t> <figure anchor="reverse-search-properties-example">
<figure anchor="reverse-search-properties-example" title="An example o <name>An Example of the Help Response including the "reverse_search_prop
f help response including the &quot;reverse_search_properties_mapping&quot; memb erties" Member</name>
er"> <sourcecode type="json"><![CDATA[
<artwork xml:space="preserve"><![CDATA[
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"reverse_search" "reverse_search"
], ],
... ...
"reverse_search_properties": [ "reverse_search_properties": [
{ {
"searchableResourceType": "domains", "searchableResourceType": "domains",
"relatedResourceType": "entity", "relatedResourceType": "entity",
skipping to change at line 311 skipping to change at line 233
"property": "email" "property": "email"
}, },
{ {
"searchableResourceType": "domains", "searchableResourceType": "domains",
"relatedResourceType": "entity", "relatedResourceType": "entity",
"property": "role" "property": "role"
} }
], ],
... ...
} }
]]></sourcecode>
]]></artwork> </figure>
</figure> <t>An example of a response including the mapping that is occurring for th
e first reverse search in <xref target="reverse-search-request"/> is shown below
<t>An example of a response including the mapping that is occurring fo .</t>
r the first reverse search in <xref target="reverse-search-request"/> is shown b <figure anchor="reverse-search-properties-mapping-example">
elow.</t> <name>An Example of an RDAP Response including the "reverse_search_prope
<figure anchor="reverse-search-properties-mapping-example" title="An e rties_mapping" Member</name>
xample of an RDAP response including the &quot;reverse_search_properties&quot; m <sourcecode type="json"><![CDATA[
ember">
<artwork xml:space="preserve"><![CDATA[
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"reverse_search" "reverse_search"
], ],
... ...
"reverse_search_properties_mapping": [ "reverse_search_properties_mapping": [
{ {
"property": "handle", "property": "handle",
"propertyPath": "$.entities[*].handle" "propertyPath": "$.entities[*].handle"
}, },
{ {
"property": "role", "property": "role",
"propertyPath": "$.entities[*].roles" "propertyPath": "$.entities[*].roles"
} }
], ],
... ...
} }
]]></sourcecode>
]]></artwork> </figure>
</figure>
</section>
<section anchor="rdap-conformance" title="RDAP Conformance">
<t>Servers complying with this specification MUST include the value &q
uot;reverse_search&quot; in the rdapConformance property of the help response <x
ref target="RFC9083"/> and any other response including the &quot;reverse_search
_properties_mapping&quot; member. The information needed to register this value
in the &quot;RDAP Extensions&quot; registry is described in <xref target="rdap-
extensions-registry"/>.</t>
</section>
<section anchor="impl-considerations" title="Implementation Considerations
">
<t>To limit the impact of processing the search predicates, servers ar
e RECOMMENDED to make use of techniques to speed up the data retrieval in their
underlying data store such as indexes or similar. In addition, risks with respe
ct to performance degradation or result set generation can be mitigated by adopt
ing practices used for standard searches, e.g. restricting the search functional
ity, limiting the rate of search requests according to the user's authorization,
truncating and paging the results <xref target="RFC8977"/>, and returning parti
al responses <xref target="RFC8982"/>.</t>
</section>
<section anchor="impl-status" title="Implementation Status">
<t>NOTE: Please remove this section and the reference to RFC 7942 prior to
publication as an RFC.</t>
<t>This section records the status of known implementations of the protoco
l defined by this specification at the time of posting of this Internet-Draft, a
nd is based on a proposal described in <xref target="RFC7942"/>. The descriptio
n of implementations in this section is intended to assist the IETF in its decis
ion processes in progressing drafts to RFCs. Please note that the listing of an
y individual implementation here does not imply endorsement by the IETF. Furthe
rmore, no effort has been spent to verify the information presented here that wa
s supplied by IETF contributors. This is not intended as, and must not be const
rued to be, a catalog of available implementations or their features. Readers a
re advised to note that other implementations may exist.</t>
<t>According to RFC 7942, "this will allow reviewers and working groups to
assign due consideration to documents that have the benefit of running code, wh
ich may serve as evidence of valuable experimentation and feedback that have mad
e the implemented protocols more mature. It is up to the individual working gro
ups to use this information as they see fit".</t>
<section anchor="iit-cnr-registro-it-rdap-server" title="IIT-CNR/Registro.
it RDAP Server">
<t><list style="none">
<t>Responsible Organization: Institute of Informatics and Telematics of
National Research Council (IIT-CNR)/Registro.it<vspace blankLines='1' /></t>
<t>Location: https://rdap.pubtest.nic.it/<vspace blankLines='1' /></t>
<t>Description: This implementation includes support for RDAP queries u
sing data from the public test environment of .it ccTLD. Reverse search is allo
wed to authenticated users. Registrar users are allowed to perform reverse sear
ches on their own domains and contacts. This is achieved by adding an implicit
predicate to the search condition.<vspace blankLines='1' /></t>
<t>Level of Maturity: This is an &quot;alpha&quot; test implementation.
<vspace blankLines='1' /></t>
<t>Coverage: This implementation includes all of the features described
in this specification.<vspace blankLines='1' /></t>
<t>Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it</t>
</list></t>
</section>
<section anchor="registro-it-rdap-client" title="IIT-CNR/Registro.it RDAP Client
">
<t><list style="none">
<t>Responsible Organization: Institute of Informatics and Telematics of Nati
onal
Research Council (IIT-CNR)/Registro.it<vspace blankLines='1' /></t>
<t>Location: https://web-rdap.pubtest.nic.it/<vspace blankLines='1' /></t>
<t>Description: This is a Javascript web-based RDAP client. RDAP responses
are
retrieved from RDAP servers by the browser, parsed into an HTML representa
tion, and displayed in a format improving the user experience. Reverse search i
s allowed to authenticated users.<vspace blankLines='1' /></t>
<t>Level of Maturity: This is an &quot;alpha&quot; test implementation.<vspa
ce blankLines='1' /></t>
<t>Coverage: This implementation includes all of the features described in t
his
specification.<vspace blankLines='1' /></t>
<t>Contact Information: Francesco Donini, francesco.donini@iit.cnr.it</t>
</list></t>
</section>
</section> </section>
<section anchor="rdap-conformance">
<section title="IANA Considerations"> <name>RDAP Conformance</name>
<t>Servers complying with this specification <bcp14>MUST</bcp14> include t
<section anchor="rdap-extensions-registry" title="RDAP Extensions Registry he value "reverse_search" in the rdapConformance property of the help response <
"> xref target="RFC9083"/> and any other response including the "reverse_search_pro
perties_mapping" member. The information needed to register this value in the "
<t>IANA is requested to register the following value in the &quot;RDAP RDAP Extensions" registry is described in <xref target="rdap-extensions-registry
Extensions&quot; registry:</t> "/>.</t>
</section>
<t><list style="none"> <section anchor="impl-considerations">
<t>Extension identifier: reverse_search<vspace blankLines='1' /></ <name>Implementation Considerations</name>
t> <t>To limit the impact of processing the search predicates, servers are <b
<t>Registry operator: Any<vspace blankLines='1' /></t> cp14>RECOMMENDED</bcp14> to make use of techniques to speed up the data retrieva
<t>Published specification: This document.<vspace blankLines='1' / l in their underlying data store, such as indexes or similar. In addition, risk
></t> s with respect to performance degradation or result set generation can be mitiga
<t>Contact: IETF &lt;iesg@ietf.org&gt;<vspace blankLines='1' /></t ted by adopting practices used for standard searches, e.g., restricting the sear
> ch functionality, limiting the rate of search requests according to the user's a
<t>Intended usage: This extension identifier is used for both URI uthorization, truncating and paging the results <xref target="RFC8977"/>, and re
path segments and response extensions related to the reverse search in RDAP.</t> turning partial responses <xref target="RFC8982"/>.</t>
</list></t> </section>
</section> <section>
<name>IANA Considerations</name>
<section anchor="rdap-reverse-search-registries" title="RDAP Reverse Sear <section anchor="rdap-extensions-registry">
ch Registries"> <name>RDAP Extensions Registry</name>
<t>IANA has registered the following value in the "RDAP Extensions" regi
<section anchor="rdap-reverse-search-registries-creation" title="Creat stry:</t>
ion of the RDAP Reverse Search Registries"> <dl spacing="normal">
<dt>Extension Identifier:</dt> <dd>reverse_search</dd>
<t>IANA is requested to create the &quot;RDAP Reverse Search&quot; and <dt>Registry Operator:</dt> <dd>Any</dd>
&quot;RDAP Reverse Search Mapping&quot; registries within the group &quot;Regis <dt>Specification:</dt> <dd>RFC 9536</dd>
tration Data Access Protocol (RDAP)&quot;.</t> <dt>Contact:</dt> <dd>IETF &lt;iesg@ietf.org&gt;</dd>
<dt>Intended Usage:</dt> <dd>This extension identifier is used for bot
<t>These registries follow the Specification Required process as defin h URI path segments and response extensions related to the reverse search in RDA
ed in Section 4.5 of <xref target="RFC8126"/>.</t> P.</dd>
</dl>
<t>The designated expert should prevent collisions and confirm that su
itable documentation, as described in Section 4.6 of <xref target="RFC8126"/>, i
s available to ensure interoperability.</t>
<t>Creators of either new RDAP reverse searches or new mappings for re
gistered reverse searches SHOULD NOT replicate functionality already available b
y way of other documents referenced in these registries. Creators MAY register
additional reverse search mappings for existing properties, but they SHOULD NOT
map a registered reverse search property to a response field with a meaning othe
r than that of the response fields referenced by the mappings already registered
for that property. In other words, all the mappings for a reverse search prope
rty MUST point to response fields with the same meaning.</t>
</section> </section>
<section anchor="rdap-reverse-search-registries">
<section title="Submit Request to IANA"> <name>RDAP Reverse Search Registries</name>
<section anchor="rdap-reverse-search-registries-creation">
<name>Creation of the RDAP Reverse Search Registries</name>
<t>IANA has created the "RDAP Reverse Search" and "RDAP Reverse Search
Mapping" registries within the "Registration Data Access Protocol (RDAP)" categ
ory in the protocol registries.
</t>
<t>These registries follow the Specification Required registration pol
icy, as defined in <xref target="RFC8126" section="4.6" sectionFormat="of" />.</
t>
<t>The designated expert should prevent collisions and confirm that su
itable documentation, as described in <xref target="RFC8126" section="4.5" secti
onFormat="of" />, is available to ensure interoperability.</t>
<t>Creators of either new RDAP reverse searches or new mappings for re
gistered reverse searches <bcp14>SHOULD NOT</bcp14> replicate functionality alre
ady available by way of other documents referenced in these registries. Creator
s <bcp14>MAY</bcp14> register additional reverse search mappings for existing pr
operties, but they <bcp14>SHOULD NOT</bcp14> map a registered reverse search pro
perty to a response field with a meaning other than that of the response fields
referenced by the mappings already registered for that property. In other words
, all the mappings for a reverse search property <bcp14>MUST</bcp14> point to re
sponse fields with the same meaning.</t>
</section>
<section>
<name>Submit Requests to IANA</name>
<t>Registration requests can be sent to &lt;iana@iana.org&gt;.</t> <t>Registration requests can be sent to &lt;iana@iana.org&gt;.</t>
</section> </section>
<section anchor="rdap-reverse-search-registry">
<section anchor="rdap-reverse-search-registry" title="RDAP Reverse Searc <name>RDAP Reverse Search Registry</name>
h Registry"> <section anchor="rdap-reverse-search-registry-template">
<name>Template</name>
<section anchor="rdap-reverse-search-registry-template" title="Templat <dl newline="false" spacing="normal">
e"> <dt>Property:</dt>
<dd>The name of the reverse search property.</dd>
<t> <dt>Description:</dt>
<list style="hanging"> <dd>A brief human-readable text describing the reverse search prop
<t hangText="&quot;Searchable Resource Type&quot;:">The search erty.</dd>
able resource type of the reverse search query (<xref target="reverse-search-pat <dt>Searchable Resource Type:</dt>
h-segment-specification"/>) including the reverse search property. Multiple rev <dd>The searchable resource type of the reverse search query (<xre
erse search properties differing only by this field can be grouped together by l f target="reverse-search-path-segment-specification"/>) including the reverse se
isting all the searchable resource types separated by comma (see <xref target="r arch property. Multiple reverse search properties differing only by this field
dap-reverse-search-registry-initial-content"/>).</t> can be grouped together by listing all the searchable resource types separated b
</list> y comma (see <xref target="rdap-reverse-search-registry-initial-content"/>).</dd
</t> >
<t> <dt>Related Resource Type:</dt>
<list style="hanging"> <dd>The related resource type of the reverse search query (<xref t
<t hangText="&quot;Related Resource Type&quot;:">The related r arget="reverse-search-path-segment-specification"/>) including the reverse searc
esource type of the reverse search query (<xref target="reverse-search-path-segm h property.</dd>
ent-specification"/>) including the reverse search property.</t> <dt>Registrant:</dt>
</list> <dd>The name of the person registering the reverse search property
</t> .</dd>
<t> <dt>Contact Information:</dt>
<list style="hanging"> <dd>An email address, postal address, or some other information to
<t hangText="&quot;Property&quot;:">The name of the reverse se be used to contact the registrant.</dd>
arch property.</t> <dt>Reference:</dt>
</list> <dd>Document (e.g., the RFC number) and section reference where th
</t> e reverse search property is specified.</dd>
<t> </dl>
<list style="hanging"> <t>The combination of Searchable Resource Type, Related Resource Typ
<t hangText="&quot;Description&quot;:">A brief human-readable e, and Property <bcp14>MUST</bcp14> be unique across the registry entries.</t>
text describing the reverse search property.</t> </section>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Registrant Name&quot;:">The name of the per
son registering the reverse search property.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Registrant Contact Information&quot;:">An e
mail address, postal address, or some other information to be used to contact th
e registrant.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Reference&quot;:">Document (e.g. the RFC nu
mber) and section reference where the reverse search property is specified.</t>
</list>
</t>
<t>The combination of &quot;Searchable Resource Type&quot;, &quot;Rela
ted Resource Type&quot; and &quot;Property&quot; MUST be unique across the regis
try entries.</t>
</section>
<section anchor="rdap-reverse-search-registry-initial-content" title="Init <section anchor="rdap-reverse-search-registry-initial-content">
ial Content"> <name>Initial Content</name>
<t>IANA is requested to register the following entries in the &quot;RDAP <t>IANA has registered the following entries in the "RDAP Reverse Se
Reverse Search&quot; registry.</t> arch" registry. For all entries, the common values are shown in <xref target="t
able1"/>, whereas the specific values are shown in <xref target="table2"/>.</t>
<table anchor="table1">
<name>Common Values for All Entries in the RDAP Reverse Search Reg
istry</name>
<thead>
<tr>
<th align="left">Registry Property</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Searchable Resource Type</td>
<td align="left">domains, nameservers, entities</td>
</tr>
<tr>
<td align="left">Related Resource Type</td>
<td align="left">entity</td>
</tr>
<tr>
<td align="left">Registrant</td>
<td align="left">IETF</td>
</tr>
<tr>
<td align="left">Contact Information</td>
<td align="left">iesg@ietf.org</td>
</tr>
<tr>
<td align="left">Reference</td>
<td align="left">RFC 9536</td>
</tr>
</tbody>
</table>
<table anchor="table2">
<name>Specific Values for Entries in the RDAP Reverse Search Regis
try</name>
<thead>
<tr>
<th align="left">Property</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">fn</td>
<td align="left">The server supports the domain/nameserver/ent
ity search based on the full name (a.k.a. formatted name) of an associated entit
y</td>
</tr>
<tr>
<td align="left">handle</td>
<td align="left">The server supports the domain/nameserver/ent
ity search based on the handle of an associated entity</td>
</tr>
<tr>
<td align="left">email</td>
<td align="left">The server supports the domain/nameserver/ent
ity search based on the email address of an associated entity</td>
</tr>
<tr>
<td align="left">role</td>
<td align="left">The server supports the domain/nameserver/ent
ity search based on the role of an associated entity</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="rdap-reverse-search-mapping-registry">
<name>RDAP Reverse Search Mapping Registry</name>
<section anchor="rdap-reverse-search-mapping-registry-template">
<name>Template</name>
<dl newline="false" spacing="normal">
<dt>Property:</dt>
<dd>The same as defined in the "RDAP Reverse Search" registry.</dd
>
<dt>Property Path:</dt>
<dd>The JSONPath of the RDAP property this reverse search property
maps to.</dd>
<dt>Searchable Resource Type:</dt>
<dd>The same as defined in the "RDAP Reverse Search" registry.</dd
>
<dt>Related Resource Type:</dt>
<dd>The same as defined in the "RDAP Reverse Search" registry.</dd
>
<t>For all entries, the common values are shown in <xref target="table <!--[rfced] *AD - The authors removed the definition of "Description"
1"/> whereas the specific values are shown in <xref target="table2"/>.</t> in Section 11.2.4.1 in version -26 that was submitted after the
<texttable anchor="table1" title="Common values for all entries in the document was added to the RFC-ED queue. Please review and let us
&quot;RDAP Reverse Search&quot; registry"> know if the removal of this definition is acceptable. Note that
<ttcol align="left">Registry Property</ttcol> with this change, the template now matches the "RDAP Reverse
<ttcol align="left">Value</ttcol> Search Mapping" registry
<c>Searchable Resource Type</c><c>domains, nameservers, entities</ <https://www.iana.org/assignments/rdap-reverse-search-mapping/>.
c>
<c>Related Resource Type</c><c>entity</c>
<c>Registrant Name</c><c>IETF</c>
<c>Registrant Contact Information</c><c>iesg@ietf.org</c>
<c>Reference</c><c>This document, <xref target="reverse-search-on-
entities"/></c>
</texttable>
<texttable anchor="table2" title="Specific values for all entries in t Original:
he &quot;RDAP Reverse Search&quot; registry"> "Property Path": The JSONPath of the RDAP property this reverse search
<ttcol align="left">Property</ttcol> property maps to.
<ttcol align="left">Description</ttcol>
<c>fn</c><c>The server supports the domain/nameserver/entity searc
h based on the full name (a.k.a. formatted name) of an associated entity</c>
<c>handle</c><c>The server supports the domain/nameserver/entity s
earch based on the handle of an associated entity</c>
<c>email</c><c>The server supports the domain/nameserver/entity se
arch based on the email address of an associated entity</c>
<c>role</c><c>The server supports the domain/nameserver/entity sea
rch based on the role of an associated entity</c>
</texttable>
</section>
</section>
<section anchor="rdap-reverse-search-mapping-registry" title="RDAP Rev "Description": A brief human-readable text describing this reverse
erse Search Mapping Registry"> search property mapping.
<section anchor="rdap-reverse-search-mapping-registry-template" ti "Registrant Name": The name of the person registering this reverse
tle="Template"> search property mapping.
<t> Current:
<list style="hanging"> Property Path: The JSONPath of the RDAP property this reverse search
<t hangText="&quot;Searchable Resource Type&quot;:">Th property maps to.
e same as defined in the &quot;Reverse Search Registry&quot;.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Related Resource Type&quot;:">The s
ame as defined in the &quot;Reverse Search Registry&quot;.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Property&quot;:">The same as define
d in the &quot;Reverse Search Registry&quot;.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Property Path&quot;:">The JSONPath
of the RDAP property this reverse search property maps to.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Description&quot;:">A brief human-r
eadable text describing this reverse search property mapping.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Registrant Name&quot;:">The name of
the person registering this reverse search property mapping.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Registrant Contact Information&quot
;:">The same as defined in the &quot;Reverse Search Registry&quot;.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="&quot;Reference&quot;:">Document (e.g. th
e RFC number) and section reference where this reverse search property mapping i
s specified.</t>
</list>
</t>
<t>The combination of &quot;Searchable Resource Type&quot;, &q Registrant: The name of the person registering this reverse
uot;Related Resource Type&quot;, &quot;Property&quot; and &quot;Property Path&qu search property mapping.
ot; MUST be unique across the registry entries.</t> -->
</section>
<section anchor="rdap-reverse-search-mapping-registry-initial-cont <!-- Note: removed by authors in version -26
ent" title="Initial Content"> <dt>Description:</dt>
<t>IANA is requested to register the following entries in the <dd>A brief human-readable text describing this reverse search pro
&quot;RDAP Reverse Search Mapping&quot; registry.</t> perty mapping.</dd>
<t>For all entries, the common values are the same as defined -->
in the &quot;RDAP Reverse Search&quot; registry (see <xref target="table1"/>) wh <dt>Registrant:</dt>
ereas the specific values are shown in <xref target="table3"/>.</t> <dd>The name of the person registering this reverse search propert
<texttable anchor="table3" title="Specific values for all entr y mapping.</dd>
ies in the &quot;RDAP Reverse Search Mapping&quot; registry"> <dt>Contact Information:</dt>
<ttcol align="left">Property</ttcol> <dd>The same as defined in the "RDAP Reverse Search" registry.</dd
<ttcol align="left">Property Path</ttcol> >
<c>fn</c><c>$.entities[*].vcardArray[1][?(@[0]=='fn')][3]< <dt>Reference:</dt>
/c> <dd>Document (e.g., the RFC number) and section reference where th
<c>handle</c><c>$.entities[*].handle</c> is reverse search property mapping is specified.</dd>
<c>email</c><c>$.entities[*].vcardArray[1][?(@[0]=='email' </dl>
)][3]</c> <t>The combination of Searchable Resource Type, Related Resource Typ
<c>role</c><c>$.entities[*].roles</c> e, Property, and Property Path <bcp14>MUST</bcp14> be unique across the registry
</texttable> entries.</t>
</section>
</section> </section>
<section anchor="rdap-reverse-search-mapping-registry-initial-content"
</section> >
<name>Initial Content</name>
<t>IANA has registered the following entries in the "RDAP Reverse Se
arch Mapping" registry. For all entries, the common values are the same as defin
ed in the "RDAP Reverse Search" registry (see <xref target="table1"/>), whereas
the specific values are shown below (see <xref target="table3"/>).</t>
<table anchor="table3">
<name>Specific Values for Entries in the RDAP Reverse Search Mappi
ng Registry</name>
<thead>
<tr>
<th align="left">Property</th>
<th align="left">Property Path</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">fn</td>
<td align="left">$.entities[*].vcardArray[1][?(@[0]=='fn')][3]
</td>
</tr>
<tr>
<td align="left">handle</td>
<td align="left">$.entities[*].handle</td>
</tr>
<tr>
<td align="left">email</td>
<td align="left">$.entities[*].vcardArray[1][?(@[0]=='email')]
[3]</td>
</tr>
<tr>
<td align="left">role</td>
<td align="left">$.entities[*].roles</td>
</tr>
</tbody>
</table>
</section>
</section>
</section> </section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations"> <section anchor="privacy-considerations">
<t>The search functionality defined in this document may affect the pr <name>Privacy Considerations</name>
ivacy of entities in the registry (and elsewhere) in various ways: see <xref tar <t>The search functionality defined in this document may affect the privac
get="RFC6973"/> for a general treatment of privacy in protocol specifications. y of entities in the registry (and elsewhere) in various ways; see <xref target=
Registry operators should be aware of the tradeoffs that result from implementat "RFC6973"/> for a general treatment of privacy in protocol specifications. Regi
ion of this functionality.</t> stry operators should be aware of the trade-offs that result from implementing t
his functionality.</t>
<t>Many jurisdictions have laws or regulations that restrict the use o <t>Many jurisdictions have laws or regulations that restrict the use of "p
f &quot;Personal Data&quot;, per the definition in <xref target="RFC6973" />. G ersonal data", per the definition in <xref target="RFC6973"/>. Given that, regi
iven that, registry operators should ascertain whether the regulatory environmen stry operators should ascertain whether the regulatory environment in which they
t in which they operate permits implementation of the functionality defined in t operate permits implementation of the functionality defined in this document.</
his document.</t> t>
<t>In those cases where this functionality makes use of sensitive informat
<t>In those cases where this functionality makes use of sensitive info ion, the information <bcp14>MUST</bcp14> only be accessible to authorized users
rmation, it MUST only be accessible to authorized users supported by lawful basi under a lawful basis.</t>
s.</t> <t>Since reverse search requests and responses could contain Personally Id
entifiable Information (PII), reverse search functionality <bcp14>MUST</bcp14> b
<t>Since reverse search requests and responses could contain Personall e available over HTTPS only.</t>
y Identifiable Information (PII), reverse search functionality MUST be available <t>Providing reverse search in RDAP carries the following threats as descr
over HTTPS only.</t> ibed in <xref target="RFC6973"/>:</t>
<ul spacing="normal">
<t>Providing reverse search in RDAP carries the following threats as d <li>Correlation</li>
escribed in <xref target="RFC6973"/>:</t> <li>Disclosure</li>
<t><list style="symbols"> <li>Misuse of data</li>
<t>Correlation</t> </ul>
<t>Disclosure</t>
<t>Misuse of information</t>
</list></t>
<t>Therefore, RDAP providers need to mitigate the risk of those threats by implementing appropriate measures supported by security services (see <xref tar get="security-considerations"/>).</t> <t>Therefore, RDAP providers need to mitigate the risk of those threats by implementing appropriate measures supported by security services (see <xref tar get="security-considerations"/>).</t>
</section> </section>
<section anchor="security-considerations">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>Security services required to provide controlled access to the operatio <t>Security services that are required to provide controlled access to the
ns specified in this document are described in <xref target="RFC7481"/>. A non- operations specified in this document are described in <xref target="RFC7481"/>
exhaustive list of access control paradigms an RDAP provider can implement is pr . A non-exhaustive list of access control paradigms an RDAP provider can implem
esented in <xref target="access-control-paradigms"/>.</t> ent is presented in <xref target="access-control-paradigms"/>.</t>
<t>As an additional measure to enforce security by preventing reverse sear <t>As an additional measure to enforce security by preventing reverse sear
ches to be accessed from unauthorized users, the RDAP providers may consider to ches to be accessed from unauthorized users, the RDAP providers may consider phy
physically separate the reverse search endpoints from the other ones by configur sically separating the reverse search endpoints from the other ones by configuri
ing a proxy routing the reverse searches to a dedicated backend server and lever ng a proxy routing the reverse searches to a dedicated backend server and levera
aging further security services offered by other protocol layers such as digital ging further security services offered by other protocol layers, such as digital
certificates and IP whitelisting.</t> certificates and IP allow-listing.</t>
<t>Finally, the specification of the relationship within the reverse searc h path allows the RDAP servers to implement different authorization policies on a per-relationship basis.</t> <t>Finally, the specification of the relationship within the reverse searc h path allows the RDAP servers to implement different authorization policies on a per-relationship basis.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge the following individuals for the
ir contributions to this document: Francesco Donini, Scott Hollenbeck, Francisco
Arias, Gustavo Lozano, Eduardo Alvarez, Ulrich Wisser, James Gould and Pawel Ko
walik.</t>
<t>Tom Harrison and Jasdip Singh provided relevant feedback and constant s
upport to the implementation of this proposal. Their contributions have been gr
eatly appreciated.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&I-D.ietf-jsonpath-base; <name>References</name>
&RFC2119; <references>
&RFC6350; <name>Normative References</name>
&RFC7095;
&RFC7481;
&RFC7942;
&RFC8126;
&RFC8174;
&RFC9082;
&RFC9083;
&RFC9110;
</references>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC3912; 119.xml"/>
&RFC5730; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC6973; 350.xml"/>
&RFC8977; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&RFC8982; 095.xml"/>
<reference anchor='ICANN-RA' target='https://newgtlds.icann.org/sites/de <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
fault/files/agreements/agreement-approved-31jul17-en.pdf'> 481.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Registry Agreement</title> 126.xml"/>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<organization>Internet Corporation For Assigned Names and Numbers 174.xml"/>
</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</author> 082.xml"/>
<date year='2017' month='July' /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 083.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<reference anchor='ICANN-RDS1' target='https://www.icann.org/en/system/f 110.xml"/>
iles/files/final-report-06jun14-en.pdf'>
<front>
<title>Final Report from the Expert Working Group on gTLD Directo
ry Services: A Next-Generation Registration Directory Service (RDS)</title>
<author>
<organization>Internet Corporation For Assigned Names and Numbers
</organization>
</author>
<date year='2014' month='June' />
</front>
</reference>
<reference anchor='ICANN-RDS2' target='http://whois.icann.org/sites/defa
ult/files/files/final-issue-report-next-generation-rds-07oct15-en.pdf'>
<front>
<title>Final Issue Report on a Next-Generation gTLD RDS to Replac
e WHOIS</title>
<author>
<organization>Internet Corporation For Assigned Names and Numbers
</organization>
</author>
<date year='2015' month='October' />
</front>
</reference>
<reference anchor="OIDCC" target="http://openid.net/specs/openid-connect-cor
e-1_0.html">
<front>
<title>OpenID Connect Core incorporating errata set 1</title>
<author initials="" surname="">
<organization>OpenID Foundation</organization>
</author>
<date month="November" year="2014" />
</front>
</reference>
</references>
<section anchor="access-control-paradigms" title="Paradigms to Enforce Acc <!---[I-D.ietf-jsonpath-base] is now RFC 9535-->
ess Control on Reverse Search in RDAP"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>Access control can be implemented according to different paradigms 535.xml"/>
introducing increasingly stringent rules. The paradigms reported here in the fo
llowing leverage the capabilities either built-in or provided as extensions by t
he OpenID Connect <xref target="OIDCC"/>:</t>
<t><list style="symbols">
<t>Role-Based Access Control (RBAC): access rights are granted dep
ending on roles. Generally, this is done by grouping users into fixed categorie
s and assigning static grants to each category. A more dynamic approach can be
implemented by using the OpenID Connect &quot;scope&quot; claim;<vspace blankLin
es='1' /></t>
<t>Purpose-Based Access Control (PBAC): access rules are based on
the notion of purpose, being the intended use of some data by a user. It can be
implemented by tagging a request with the usage purpose and making the RDAP ser
ver check the compliance between the given purpose and the control rules applied
to the data to be returned;<vspace blankLines='1' /></t>
<t>Attribute-Based Access Control (ABAC): rules to manage access r
ights are evaluated and applied according to specific attributes describing the
context within which data are requested. It can be implemented by setting withi
n an out-of-band process additional OpenID Connect claims describing the request
context and making the RDAP server check the compliance between the given conte
xt and the control rules applied to the data to be returned;<vspace blankLines='
1' /></t>
<t>Time-Based Access Control (TBAC): data access is allowed for a
limited time only. It can be implemented by assigning the users with temporary
credentials linked to access grants whose scope is limited.</t>
</list></t>
<t>With regard to the privacy threats reported in <xref target="privac </references>
y-considerations"/>, correlation and disclosure can be mitigated by minimizing b <references>
oth the request features and the response data based on user roles (i.e. RBAC). <name>Informative References</name>
Misuse can be mitigated by checking for the purpose of the request (i.e. PBAC). <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
It can be accomplished according to the following approaches:</t> 912.xml"/>
<t><list style="symbols"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<t>Full Trust: the registry trusts the fairness of an accredited u 730.xml"/>
ser. The requestor is always legitimized to submit his requests under a lawful <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
basis. Additionally, he can be required to specify the purpose as either a claim 973.xml"/>
of his account or a query parameter. In the former case, the purpose is assume <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
d to be the same for every request. In the latter case, the purpose must be one 977.xml"/>
of those associated to the user;<vspace blankLines='1' /></t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>Zero Trust: the registry requires documents assessing that the 982.xml"/>
requestor is legitimized to submit a given request. It can be implemented by as
signing the requestor with temporary OpenID account linked to the given request
(i.e. TBAC) and describing the request through a set of claims (i.e. ABAC). The
association between the temporary account and the claims about the request is m
ade by an out-of-band application. In so doing, the RDAP server is able to chec
k that the incoming request is consistent with the request claims linked to the
temporary account.</t>
</list></t>
<t>The two approaches can be used together:</t>
<t><list style="symbols">
<t>The former is suitable for users carrying out a task in the pub
lic interest, or exercising their official authority (e.g. an officer of a cyber
crime agency). Similarly, registrars can submit reverse searches on their domai
ns and contacts based on their contractual relationship with the domain holders.
In this case, the query results can be restricted to those pertaining a regist
rar by adding an implicit predicate to the search condition.<vspace blankLines='
1' /></t>
<t>The latter can be taken to allow domain name dispute resolution
service providers to request information in defense of the legitimate interests
of complainants.</t>
</list></t>
</section>
<section title="Change Log"> <reference anchor="ICANN-RA" target="https://www.icann.org/en/registry-a
<t> greements/base-agreement">
<list style="hanging"> <front>
<t hangText="00:">Initial working group version ported from draft-loff <title>Base Registry Agreement</title>
redo-regext-rdap-reverse-search-04</t> <author>
<t hangText="01:">Updated &quot;Privacy Considerations&quot; s <organization>ICANN</organization>
ection.</t> </author>
<t hangText="02:">Revised the text.</t> <date month="January" year="2024"/>
<t hangText="03:">Refactored the query model.</t> </front>
<t hangText="04:">Keepalive refresh.</t> </reference>
<t hangText="05:">Reorganized "Abstract". Corrected "Conventions Use
d in This Document" section. Added &quot;RDAP Conformance&quot; section. Chang <reference anchor="ICANN-RDS" target="https://www.icann.org/en/system/fi
ed &quot;IANA Considerations&quot; section. Added references to RFC7095 and RFC les/files/final-report-06jun14-en.pdf">
8174. Other minor edits.</t> <front>
<t hangText="06:">Updated &quot;Privacy Considerations&quot;, &quot;S <title>Final Report from the Expert Working Group on gTLD Directory
ecurity Considerations&quot; and &quot;Acknowledgements&quot; sections. Added s Services: A Next-Generation Registration Directory Service (RDS)</title>
ome normative and informative references. Added <xref target="access-control-pa <author>
radigms"/>.</t> <organization>ICANN</organization>
<t hangText="07:">Updated normative references.</t> </author>
<t hangText="08:">Changed &quot;Implementation Status&quot; section. <date year="2014" month="June"/>
Updated informative references.</t> </front>
<t hangText="09:">Extended the query model to represent a reverse sea </reference>
rch based on any relationship between the RDAP object classes. Changed the path
segment &quot;role&quot; into a query parameter.</t> <reference anchor="OIDCC" target="http://openid.net/specs/openid-connect
<t hangText="10:">Updated &quot;Reverse Searches Based on Entity Deta -core-1_0.html">
ils&quot; section to consider the use of JSContact format instead of jCard. Add <front>
ed references to JSContact documents.</t> <title>OpenID Connect Core 1.0 incorporating errata set 2</title>
<t hangText="11:">Updated the document based on Tom Harrison and Jame <author initials="N" surname="Sakimura">
s Gould feedback: </author>
<list style="symbols"> <author initials="J" surname="Bradley">
<t>Updated section &quot;RDAP Path Segment Specification&quot;: </author>
<list style="symbols"> <author initials="M" surname="Jones">
<t>Clarified how servers must evaluate a reverse search </author>
including predicates that are for the same property.<vspace blankLines='1' /></t <author initials="B" surname="de Medeiros">
> </author>
<t>Specified the error response servers must return when <author initials="C" surname="Mortimore">
receiving a wrong reverse search request according to their policy.<vspace blan </author>
kLines='1' /></t> <date month="December" year="2023"/>
<t>Clarified that searchs for the related-resource-type </front>
values other than &quot;entity&quot; may be defined in future documents.<vspace </reference>
blankLines='1' /></t> </references>
</list> </references>
</t> <section anchor="access-control-paradigms">
<t>Reviewed text in section &quot;Reverse Searches Based on Enti <name>Paradigms to Enforce Access Control on Reverse Search in RDAP</name>
ty Details&quot; about reverse searches based on custom response extensions.<vsp <t>Access control can be implemented according to different paradigms intr
ace blankLines='1' /></t> oducing increasingly stringent rules. The paradigms listed below leverage the c
<t>Removed references to JSContact documents in section &quot;Re apabilities that are either built in or provided as extensions by the OpenID Con
verse Searches Based on Entity Details&quot;. Moved the mapping between jCard p nect <xref target="OIDCC"/>:</t>
roperties used in the RDAP response and JSContact counterparts to draft-ietf-reg <dl spacing="normal">
ext-rdap-jscontact.<vspace blankLines='1' /></t> <dt>Role-Based Access Control (RBAC):</dt> <dd>Access rights are granted
<t>Added section &quot;RDAP Response Specification&quot;.<vspace depending on roles. Generally, this is done by grouping users into fixed categ
blankLines='1' /></t> ories and assigning static grants to each category. A more dynamic approach can
<t>Changed the text to present reverse search as a single extens be implemented by using the OpenID Connect "scope" claim.</dd>
ion with multiple features.<vspace blankLines='1' /></t> <dt>Purpose-Based Access Control (PBAC):</dt> <dd>Access rules are based
<t>Changed the definition of searchable-resource-type and relate on the notion of purpose, being the intended use of some data by a user. It ca
d-resource-type to consider also the resource type extensions.<vspace blankLines n be implemented by tagging a request with the usage purpose and making the RDAP
='1' /></t> server check the compliance between the given purpose and the control rules app
<t>Replaced "reverse" with "reverse_search_0" in the generic rev lied to the data to be returned.</dd>
erse search path. Updated <xref target="reverse-search-request"/> accordingly.< <dt>Attribute-Based Access Control (ABAC):</dt> <dd>Rules to manage acce
vspace blankLines='1' /></t> ss rights are evaluated and applied according to specific attributes describing
<t>Removed the phrase &quot;but with a special focus on its priv the context within which data are requested. It can be implemented within an ou
acy implications&quot; from both the &quot;Abstract&quot; and the &quot;Introduc t-of-band process by setting additional OpenID Connect claims that describe the
tion&quot;. Moved the mapping between jCard properties used in the RDAP respons request context and make the RDAP server check for compliance between the given
e and JSContact counterparts to draft-ietf-regext-rdap-jscontact.<vspace blankLi context and the control rules that are applied to the data to be returned.</dd>
nes='1' /></t> <dt>Time-Based Access Control (TBAC):</dt> <dd>Data access is allowed fo
<t>Reviewed the text of &quot;Privacy Considerations&quot; secti r a limited time only. It can be implemented by assigning users temporary crede
on.<vspace blankLines='1' /></t> ntials linked to access grants with limited scopes.</dd>
<t>Text cleaning.<vspace blankLines='1' /></t> </dl>
</list> <t>With regard to the privacy threats reported in <xref target="privacy-co
</t> nsiderations"/>, correlation and disclosure can be mitigated by minimizing both
<t hangText="12:">Replaced &quot;reverse_search_0&quot; with &quot;re the request features and the response data based on user roles (i.e., RBAC). Mi
verse_search&quot; as both URI path segment, extension identifier and rdapConfor suse can be mitigated by checking for the purpose of the request (i.e., PBAC).
mance tag to match the working group consensus.</t> It can be accomplished according to the following approaches:</t>
<t hangText="13:">Done some minor text changes.</t> <dl spacing="normal">
<t hangText="14:">Revised text of first sentence and added references <dt>Full Trust:</dt> <dd>The registry trusts the fairness of an accredit
to RFC8977 and RFC8982 in the &quot;Implementation Considerations&quot; section ed user. The requestor is always legitimized to submit their requests under a l
.</t> awful basis. Additionally, they can be required to specify the purpose as either
<t hangText="15:">Moved RFC6973 from Normative References to Informat a claim of their account or a query parameter. In the former case, the purpose
ive References. Remnoved informative reference to draft-ietf-regext-rdap-openid is assumed to be the same for every request. In the latter case, the purpose m
. Rephrased text in Appendix A accordingly.</t> ust be one of those associated to the user.</dd>
<t hangText="16:">Moved OIDC from Normative References to Informative <dt>Zero Trust:</dt> <dd>The registry requires documents that assess whe
References. Added the &quot;Reverse Search Properties Discovery&quot; section. ther the requestor is legitimized to submit a given request. It can be implemen
Added &quot;RDAP JSON Values Registry&quot; as a subsection of the &quot;IANA ted by assigning the requestor a temporary OpenID account linked to the given re
Considerations&quot; section. Rephrased the &quot;Reverse Searches Based on Ent quest (i.e., TBAC) and describing the request through a set of claims (i.e., ABA
ity Details&quot; section to refer to the &quot;Reverse Search Properties Discov C). The association between the temporary account and the claims about the requ
ery&quot; section. Updated the &quot;Acknowledgements&quot; section. Minor tex est is made by an out-of-band application. In so doing, the RDAP server is able
t edits.</t> to check that the incoming request is consistent with the request claims linked
<t hangText="17:">Revised the &quot;Reverse Search Properties Discove to the temporary account.</dd>
ry&quot; section. Replaced &quot;RDAP JSON Values Registry&quot; section with t </dl>
he &quot;RDAP Reverse Search Properties Registry&quot; section.</t> <t>The two approaches can be used together:</t>
<t hangText="18:">Changed &quot;Expert Review&quot; with &quot;Specif <ul spacing="normal">
ication Required&quot; in the &quot;Creation of the RDAP Reverse Search Properti <li>The former is suitable for users carrying out a task in the public i
es Registry&quot; section. Renamed the "RDAP Reverse Search Properties Registry nterest or exercising their official authority (e.g., an officer of a cybercrime
" into "RDAP Reverse Search Registry". Aligned the RDAP Reverse Search Registry agency). Similarly, registrars can submit reverse searches on their domains an
template with the initial content. Introduced the "reverse_search_properties_m d contacts based on their contractual relationship with the domain holders. In
apping" response extension. Added the "RDAP Reverse Search Mapping Registry". this case, the query results can be restricted to those pertaining to a registra
Reorganized the document to separate the implementation of a generic reverse sea r by adding an implicit predicate to the search condition.
rch from that based on domain-entity relationship.</t> </li>
<t hangText="19:">Added the &quot;Reverse Search Query Processing&qu <li>The latter can be taken to allow domain name dispute resolution serv
ot; section. Changed the definition of search-condition in <xref target="revers ice providers to request information in defense of the legitimate interests of c
e-search-path-segment-specification"/>. Moved the "Reverse Search Response Spec omplainants.</li>
ification" section. Corrected <xref target="reverse-search-properties-mapping-e </ul>
xample"/>.</t> </section>
<t hangText="20:"> <section numbered="false">
<list style="symbols"> <name>Acknowledgements</name>
<t>Changed document title.</t> <t>The authors would like to acknowledge the following individuals for the
<t>Changed &quot;Servers MUST NOT provide or implement unreg ir contributions to this document: <contact fullname="Francesco Donini"/>, <cont
istered reverse searches or unregistered reverse search mappings.&quot; to &quot act fullname="Scott Hollenbeck"/>, <contact fullname="Francisco Arias"/>, <conta
;Servers MUST NOT provide or implement reverse searches or reverse search mappin ct fullname="Gustavo Lozano"/>, <contact fullname="Eduardo Alvarez"/>, <contact
gs that are not registered with IANA.&quot; in <xref target="reverse-search-defi fullname="Ulrich Wisser"/>, <contact fullname="James Gould"/>, and <contact full
nition"/>.</t> name="Pawel Kowalik"/>.</t>
<t>Changed &quot;...that the RDAP response property &quot;ro <t><contact fullname="Tom Harrison"/> and <contact fullname="Jasdip Singh"
les&quot; must contain at least the specified role&quot; to &quot;...that the RD /> provided relevant feedback and constant support to the implementation of this
AP response property &quot;roles&quot; MUST contain at least the specified role& proposal. Their contributions have been greatly appreciated.</t>
quot; in <xref target="reverse-search-on-entities"/>.</t>
<t>Changed the value of the &quot;Intended usage&quot; prope
rty of the &quot;RDAP Extensions Registry&quot; entry in <xref target="rdap-exte
nsions-registry"/>.</t>
<t>Changed &quot;..., reverse search functionality SHOULD be
available over HTTPS only.&quot; to &quot;..., reverse search functionality MUS
T be available over HTTPS only.&quot; in <xref target="privacy-considerations"/>
.</t>
</list>
</t>
<t hangText="21:">
<list style="symbols">
<t>Added a sentence about servers signaling the unsupported
reverse searches to <xref target="reverse-search-query-processing"/>.</t>
<t>Replaced "$.." with "$." in JSONPath expressions.</t>
<t>Clarified that the registry group the new registries must
be added to is &quot;Registration Data Access Protocol (RDAP)&quot;.</t>
<t>Removed unused normative reference to RFC7480.</t>
</list>
</t>
<t hangText="22:">
<list style="symbols">
<t>Expanded EPP acronym in <xref target="introduction"/>.</t
>
<t>Moved RFC3912 and RFC5730 from normative to informative r
eferences.</t>
</list>
</t>
<t hangText="23:">
<list style="symbols">
<t>Replaced IESG with IETF as the Registrant Name for each e
ntry in the IANA registries.</t>
<t>Rearranged the layout of the initial content for the IANA
registries.</t>
<t>Added titles to figures.</t>
<t>Repalced &quot;RDAP providers are REQUIRED to&quot; with
&quot;RDAP providers need to&quot; in <xref target="security-considerations"/>.<
/t>
<t>Text cleaning.</t>
</list>
</t>
<t hangText="24:">
<list style="symbols">
<t>Added text to <xref target="rdap-reverse-search-registrie
s-creation"/> to make the term "collisions" clear enough for future DEs.</t>
<t>Added titles to tables.</t>
</list>
</t>
<t hangText="25:">
<list style="symbols">
<t>Added text to <xref target="introduction"/> to reference
the implications of this specification on efficiency, security and compliance wi
th privacy regulations.</t>
<t>Changed text in Privacy Considerations to clarify that in
those cases where sensitive information are used, this feature MUST be accessbl
e to authorized users only.</t>
<t>Added text to <xref target="security-considerations"/> to
describe additional measures to enforce the security.</t>
<t>Added text to <xref target="access-control-paradigms"/> t
o clarify how the proposed access control paradigms can contribute to mitigate t
he threats listed in <xref target="privacy-considerations"/>.</t>
<t>Moved the reference to RFC3912.</t>
<t>Moved reference to draft-ietf-jsonpath-based to Normative
References.</t>
<t>Text cleaning.</t>
</list>
</t>
</list>
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 39 change blocks. 
1089 lines changed or deleted 773 lines changed or added

This html diff was produced by rfcdiff 1.48.