Diff: rfc9536xml2.original.xml

	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 " ">
	<!ENTITY RFC2119 PUBLIC ''	<!ENTITY zwsp "">
	'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>	<!ENTITY nbhy "‑">
	<!ENTITY RFC3912 PUBLIC ''	<!ENTITY wj "⁠">
	'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="April"/>
	<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}?<search-condition></t>

	<t>The path segments are defined as in the following:</t>
	<t>
	<list style="hanging">
	<t hangText=""searchable-resource-type":">it MUST be o
	ne of the resource types for search defined in Section 3.2 of <xref target="RFC9
	082"/> (i.e. "domains", "nameservers" and "entities&quo
	t;) or a resource type extension;<vspace blankLines='1'/></t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""related-resource-type":">it MUST be one
	of the resource types for lookup defined in Section 3.1 of <xref target="RFC9082
	"/> (i.e. "domain", "nameserver", "entity", "
	ip" and "autnum") or a resource type extension;<vspace blankLines
	='1'/></t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""search-condition":">a sequence of "
	property=search pattern" predicates separated by the ampersand character ('
	&', 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 "entity". 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 <searchabl
	e resource type, related resource type, property> 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 "fn" relies on the value of th
	e "fn" 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 "reverse_search_properties" 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 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=""searchableResourceType":">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=""relatedResourceType":">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=""property":">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 "reverse_search_
	properties" 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}?<s
		earch-condition></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 ('&', 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 <searchable
		resource type, related resource type, property> 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
	"reverse_search_properties_mapping" 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=""property":">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=""propertyPath":">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 "reverse	</section>
	_search_properties_mapping" 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 "entity".</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 "role
	" means that the RDAP response property "roles" 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 "reverse_search_properties_mapping" 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 "reverse_search_properties" 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" in the rdapConformance property of the help response <x
	ref target="RFC9083"/> and any other response including the "reverse_search
	_properties_mapping" member. The information needed to register this value
	in the "RDAP Extensions" 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 "alpha" 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 "alpha" 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 "RDAP	RDAP Extensions" registry is described in <xref target="rdap-extensions-registry
	Extensions" 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 <iesg@ietf.org><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 "RDAP Reverse Search" and	<dt>Registry Operator:</dt> <dd>Any</dd>
	"RDAP Reverse Search Mapping" registries within the group "Regis	<dt>Specification:</dt> <dd>RFC 9536</dd>
	tration Data Access Protocol (RDAP)".</t>	<dt>Contact:</dt> <dd>IETF <iesg@ietf.org></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 <iana@iana.org>.</t>	<t>Registration requests can be sent to <iana@iana.org>.</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=""Searchable Resource Type":">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=""Related Resource Type":">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=""Property":">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=""Description":">A brief human-readable	e, and Property <bcp14>MUST</bcp14> be unique across the registry entries.</t>
	text describing the reverse search property.</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Registrant Name":">The name of the per
	son registering the reverse search property.</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Registrant Contact Information":">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=""Reference":">Document (e.g. the RFC nu
	mber) and section reference where the reverse search property is specified.</t>
	</list>
	</t>
	<t>The combination of "Searchable Resource Type", "Rela
	ted Resource Type" and "Property" MUST be unique across the regis
	try entries.</t>
	</section>

	<section anchor="rdap-reverse-search-registry-initial-content" title="Init
	ial Content">
	<t>IANA is requested to register the following entries in the "RDAP
	Reverse Search" registry.</t>

	<t>For all entries, the common values are shown in <xref target="table
	1"/> whereas the specific values are shown in <xref target="table2"/>.</t>
	<texttable anchor="table1" title="Common values for all entries in the
	"RDAP Reverse Search" registry">
	<ttcol align="left">Registry Property</ttcol>
	<ttcol align="left">Value</ttcol>
	<c>Searchable Resource Type</c><c>domains, nameservers, entities</
	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
	he "RDAP Reverse Search" registry">
	<ttcol align="left">Property</ttcol>
	<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
	erse Search Mapping Registry">

	<section anchor="rdap-reverse-search-mapping-registry-template" ti
	tle="Template">

	<t>
	<list style="hanging">
	<t hangText=""Searchable Resource Type":">Th
	e same as defined in the "Reverse Search Registry".</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Related Resource Type":">The s
	ame as defined in the "Reverse Search Registry".</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Property":">The same as define
	d in the "Reverse Search Registry".</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Property Path":">The JSONPath
	of the RDAP property this reverse search property maps to.</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Description":">A brief human-r
	eadable text describing this reverse search property mapping.</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Registrant Name":">The name of
	the person registering this reverse search property mapping.</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Registrant Contact Information&quot
	;:">The same as defined in the "Reverse Search Registry".</t>
	</list>
	</t>
	<t>
	<list style="hanging">
	<t hangText=""Reference":">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 "Searchable Resource Type", &q
	uot;Related Resource Type", "Property" and "Property Path&qu
	ot; MUST be unique across the registry entries.</t>
	</section>

	<section anchor="rdap-reverse-search-mapping-registry-initial-cont
	ent" title="Initial Content">
	<t>IANA is requested to register the following entries in the
	"RDAP Reverse Search Mapping" registry.</t>
	<t>For all entries, the common values are the same as defined
	in the "RDAP Reverse Search" registry (see <xref target="table1"/>) wh
	ereas the specific values are shown in <xref target="table3"/>.</t>
	<texttable anchor="table3" title="Specific values for all entr
	ies in the "RDAP Reverse Search Mapping" registry">
	<ttcol align="left">Property</ttcol>
	<ttcol align="left">Property Path</ttcol>
	<c>fn</c><c>$.entities[*].vcardArray[1][?(@[0]=='fn')][3]<
	/c>
	<c>handle</c><c>$.entities[*].handle</c>
	<c>email</c><c>$.entities[*].vcardArray[1][?(@[0]=='email'
	)][3]</c>
	<c>role</c><c>$.entities[*].roles</c>
	</texttable>
	</section>
	</section>	</section>


		<section anchor="rdap-reverse-search-registry-initial-content">
		<name>Initial Content</name>
		<t>IANA has registered the following entries in the "RDAP Reverse Se
		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
		>
		<dt>Registrant:</dt>
		<dd>The name of the person registering this reverse search propert
		y mapping.</dd>
		<dt>Contact Information:</dt>
		<dd>The same as defined in the "RDAP Reverse Search" registry.</dd
		>
		<dt>Reference:</dt>
		<dd>Document (e.g., the RFC number) and section reference where th
		is reverse search property mapping is specified.</dd>
		</dl>
		<t>The combination of Searchable Resource Type, Related Resource Typ
		e, Property, and Property Path <bcp14>MUST</bcp14> be unique across the registry
		entries.</t>
		</section>
		<section anchor="rdap-reverse-search-mapping-registry-initial-content"
		>
		<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>	<section anchor="privacy-considerations">
		<name>Privacy Considerations</name>
	<section anchor="privacy-considerations" title="Privacy Considerations">	<t>The search functionality defined in this document may affect the privac
	<t>The search functionality defined in this document may affect the pr	y of entities in the registry (and elsewhere) in various ways; see <xref target=
	ivacy of entities in the registry (and elsewhere) in various ways: see <xref tar	"RFC6973"/> for a general treatment of privacy in protocol specifications. Regi
	get="RFC6973"/> for a general treatment of privacy in protocol specifications.	stry operators should be aware of the trade-offs that result from implementing t
	Registry operators should be aware of the tradeoffs that result from implementat	his functionality.</t>
	ion of this functionality.</t>	<t>Many jurisdictions have laws or regulations that restrict the use of "p
		ersonal data", per the definition in <xref target="RFC6973"/>. Given that, regi
	<t>Many jurisdictions have laws or regulations that restrict the use o	stry operators should ascertain whether the regulatory environment in which they
	f "Personal Data", per the definition in <xref target="RFC6973" />. G	operate permits implementation of the functionality defined in this document.</
	iven that, registry operators should ascertain whether the regulatory environmen	t>
	t in which they operate permits implementation of the functionality defined in t	<t>In those cases where this functionality makes use of sensitive informat
	his document.</t>	ion, the information <bcp14>MUST</bcp14> only be accessible to authorized users
		under a lawful basis.</t>
	<t>In those cases where this functionality makes use of sensitive info	<t>Since reverse search requests and responses could contain Personally Id
	rmation, it MUST only be accessible to authorized users supported by lawful basi	entifiable Information (PII), reverse search functionality <bcp14>MUST</bcp14> b
	s.</t>	e available over HTTPS only.</t>
		<t>Providing reverse search in RDAP carries the following threats as descr
	<t>Since reverse search requests and responses could contain Personall	ibed in <xref target="RFC6973"/>:</t>
	y Identifiable Information (PII), reverse search functionality MUST be available	<ul spacing="normal">
	over HTTPS only.</t>	<li>Correlation</li>
		<li>Disclosure</li>
	<t>Providing reverse search in RDAP carries the following threats as d	<li>Misuse of data</li>
	escribed in <xref target="RFC6973"/>:</t>	</ul>
	<t><list style="symbols">
	<t>Correlation</t>
	<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'>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<front>	535.xml"/>
	<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	</references>
	ess Control on Reverse Search in RDAP">	<references>
	<t>Access control can be implemented according to different paradigms	<name>Informative References</name>
	introducing increasingly stringent rules. The paradigms reported here in the fo	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	llowing leverage the capabilities either built-in or provided as extensions by t	912.xml"/>
	he OpenID Connect <xref target="OIDCC"/>:</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<t><list style="symbols">	730.xml"/>
	<t>Role-Based Access Control (RBAC): access rights are granted dep	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	ending on roles. Generally, this is done by grouping users into fixed categorie	973.xml"/>
	s and assigning static grants to each category. A more dynamic approach can be	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	implemented by using the OpenID Connect "scope" claim;<vspace blankLin	977.xml"/>
	es='1' /></t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<t>Purpose-Based Access Control (PBAC): access rules are based on	982.xml"/>
	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	<reference anchor="ICANN-RA" target="https://www.icann.org/en/registry-a
	y-considerations"/>, correlation and disclosure can be mitigated by minimizing b	greements/base-agreement">
	oth the request features and the response data based on user roles (i.e. RBAC).	<front>
	Misuse can be mitigated by checking for the purpose of the request (i.e. PBAC).	<title>Base Registry Agreement</title>
	It can be accomplished according to the following approaches:</t>	<author>
	<t><list style="symbols">	<organization>ICANN</organization>
	<t>Full Trust: the registry trusts the fairness of an accredited u	</author>
	ser. The requestor is always legitimized to submit his requests under a lawful	<date month="January" year="2024"/>
	basis. Additionally, he can be required to specify the purpose as either a claim	</front>
	of his account or a query parameter. In the former case, the purpose is assume	</reference>
	d to be the same for every request. In the latter case, the purpose must be one
	of those associated to the user;<vspace blankLines='1' /></t>
	<t>Zero Trust: the registry requires documents assessing that the
	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-RDS" target="https://www.icann.org/en/system/fi
	<t>	les/files/final-report-06jun14-en.pdf">
	<list style="hanging">	<front>
	<t hangText="00:">Initial working group version ported from draft-loff	<title>Final Report from the Expert Working Group on gTLD Directory
	redo-regext-rdap-reverse-search-04</t>	Services: A Next-Generation Registration Directory Service (RDS)</title>
	<t hangText="01:">Updated "Privacy Considerations" s	<author>
	ection.</t>	<organization>ICANN</organization>
	<t hangText="02:">Revised the text.</t>	</author>
	<t hangText="03:">Refactored the query model.</t>	<date year="2014" month="June"/>
	<t hangText="04:">Keepalive refresh.</t>	</front>
	<t hangText="05:">Reorganized "Abstract". Corrected "Conventions Use	</reference>
	d in This Document" section. Added "RDAP Conformance" section. Chang
	ed "IANA Considerations" section. Added references to RFC7095 and RFC	<reference anchor="OIDCC" target="http://openid.net/specs/openid-connect
	8174. Other minor edits.</t>	-core-1_0.html">
	<t hangText="06:">Updated "Privacy Considerations", "S	<front>
	ecurity Considerations" and "Acknowledgements" sections. Added s	<title>OpenID Connect Core 1.0 incorporating errata set 2</title>
	ome normative and informative references. Added <xref target="access-control-pa	<author initials="N" surname="Sakimura">
	radigms"/>.</t>	</author>
	<t hangText="07:">Updated normative references.</t>	<author initials="J" surname="Bradley">
	<t hangText="08:">Changed "Implementation Status" section.	</author>
	Updated informative references.</t>	<author initials="M" surname="Jones">
	<t hangText="09:">Extended the query model to represent a reverse sea	</author>
	rch based on any relationship between the RDAP object classes. Changed the path	<author initials="B" surname="de Medeiros">
	segment "role" into a query parameter.</t>	</author>
	<t hangText="10:">Updated "Reverse Searches Based on Entity Deta	<author initials="C" surname="Mortimore">
	ils" section to consider the use of JSContact format instead of jCard. Add	</author>
	ed references to JSContact documents.</t>	<date month="December" year="2023"/>
	<t hangText="11:">Updated the document based on Tom Harrison and Jame	</front>
	s Gould feedback:	</reference>
	<list style="symbols">	</references>
	<t>Updated section "RDAP Path Segment Specification":	</references>
	<list style="symbols">	<section anchor="access-control-paradigms">
	<t>Clarified how servers must evaluate a reverse search	<name>Paradigms to Enforce Access Control on Reverse Search in RDAP</name>
	including predicates that are for the same property.<vspace blankLines='1' /></t	<t>Access control can be implemented according to different paradigms intr
	>	oducing increasingly stringent rules. The paradigms listed below leverage the c
	<t>Specified the error response servers must return when	apabilities that are either built in or provided as extensions by the OpenID Con
	receiving a wrong reverse search request according to their policy.<vspace blan	nect <xref target="OIDCC"/>:</t>
	kLines='1' /></t>	<dl spacing="normal">
	<t>Clarified that searchs for the related-resource-type	<dt>Role-Based Access Control (RBAC):</dt> <dd>Access rights are granted
	values other than "entity" may be defined in future documents.<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
	</list>	be implemented by using the OpenID Connect "scope" claim.</dd>
	</t>	<dt>Purpose-Based Access Control (PBAC):</dt> <dd>Access rules are based
	<t>Reviewed text in section "Reverse Searches Based on Enti	on the notion of purpose, being the intended use of some data by a user. It ca
	ty Details" about reverse searches based on custom response extensions.<vsp	n be implemented by tagging a request with the usage purpose and making the RDAP
	ace blankLines='1' /></t>	server check the compliance between the given purpose and the control rules app
	<t>Removed references to JSContact documents in section "Re	lied to the data to be returned.</dd>
	verse Searches Based on Entity Details". Moved the mapping between jCard p	<dt>Attribute-Based Access Control (ABAC):</dt> <dd>Rules to manage acce
	roperties used in the RDAP response and JSContact counterparts to draft-ietf-reg	ss rights are evaluated and applied according to specific attributes describing
	ext-rdap-jscontact.<vspace blankLines='1' /></t>	the context within which data are requested. It can be implemented within an ou
	<t>Added section "RDAP Response Specification".<vspace	t-of-band process by setting additional OpenID Connect claims that describe the
	blankLines='1' /></t>	request context and make the RDAP server check for compliance between the given
	<t>Changed the text to present reverse search as a single extens	context and the control rules that are applied to the data to be returned.</dd>
	ion with multiple features.<vspace blankLines='1' /></t>	<dt>Time-Based Access Control (TBAC):</dt> <dd>Data access is allowed fo
	<t>Changed the definition of searchable-resource-type and relate	r a limited time only. It can be implemented by assigning users temporary crede
	d-resource-type to consider also the resource type extensions.<vspace blankLines	ntials linked to access grants with limited scopes.</dd>
	='1' /></t>	</dl>
	<t>Replaced "reverse" with "reverse_search_0" in the generic rev	<t>With regard to the privacy threats reported in <xref target="privacy-co
	erse search path. Updated <xref target="reverse-search-request"/> accordingly.<	nsiderations"/>, correlation and disclosure can be mitigated by minimizing both
	vspace blankLines='1' /></t>	the request features and the response data based on user roles (i.e., RBAC). Mi
	<t>Removed the phrase "but with a special focus on its priv	suse can be mitigated by checking for the purpose of the request (i.e., PBAC).
	acy implications" from both the "Abstract" and the "Introduc	It can be accomplished according to the following approaches:</t>
	tion". Moved the mapping between jCard properties used in the RDAP respons	<dl spacing="normal">
	e and JSContact counterparts to draft-ietf-regext-rdap-jscontact.<vspace blankLi	<dt>Full Trust:</dt> <dd>The registry trusts the fairness of an accredit
	nes='1' /></t>	ed user. The requestor is always legitimized to submit their requests under a l
	<t>Reviewed the text of "Privacy Considerations" secti	awful basis. Additionally, they can be required to specify the purpose as either
	on.<vspace blankLines='1' /></t>	a claim of their account or a query parameter. In the former case, the purpose
	<t>Text cleaning.<vspace blankLines='1' /></t>	is assumed to be the same for every request. In the latter case, the purpose m
	</list>	ust be one of those associated to the user.</dd>
	</t>	<dt>Zero Trust:</dt> <dd>The registry requires documents that assess whe
	<t hangText="12:">Replaced "reverse_search_0" with "re	ther the requestor is legitimized to submit a given request. It can be implemen
	verse_search" as both URI path segment, extension identifier and rdapConfor	ted by assigning the requestor a temporary OpenID account linked to the given re
	mance tag to match the working group consensus.</t>	quest (i.e., TBAC) and describing the request through a set of claims (i.e., ABA
	<t hangText="13:">Done some minor text changes.</t>	C). The association between the temporary account and the claims about the requ
	<t hangText="14:">Revised text of first sentence and added references	est is made by an out-of-band application. In so doing, the RDAP server is able
	to RFC8977 and RFC8982 in the "Implementation Considerations" section	to check that the incoming request is consistent with the request claims linked
	.</t>	to the temporary account.</dd>
	<t hangText="15:">Moved RFC6973 from Normative References to Informat	</dl>
	ive References. Remnoved informative reference to draft-ietf-regext-rdap-openid	<t>The two approaches can be used together:</t>
	. Rephrased text in Appendix A accordingly.</t>	<ul spacing="normal">
	<t hangText="16:">Moved OIDC from Normative References to Informative	<li>The former is suitable for users carrying out a task in the public i
	References. Added the "Reverse Search Properties Discovery" section.	nterest or exercising their official authority (e.g., an officer of a cybercrime
	Added "RDAP JSON Values Registry" as a subsection of the "IANA	agency). Similarly, registrars can submit reverse searches on their domains an
	Considerations" section. Rephrased the "Reverse Searches Based on Ent	d contacts based on their contractual relationship with the domain holders. In
	ity Details" section to refer to the "Reverse Search Properties Discov	this case, the query results can be restricted to those pertaining to a registra
	ery" section. Updated the "Acknowledgements" section. Minor tex	r by adding an implicit predicate to the search condition.
	t edits.</t>	</li>
	<t hangText="17:">Revised the "Reverse Search Properties Discove	<li>The latter can be taken to allow domain name dispute resolution serv
	ry" section. Replaced "RDAP JSON Values Registry" section with t	ice providers to request information in defense of the legitimate interests of c
	he "RDAP Reverse Search Properties Registry" section.</t>	omplainants.</li>
	<t hangText="18:">Changed "Expert Review" with "Specif	</ul>
	ication Required" in the "Creation of the RDAP Reverse Search Properti	</section>
	es Registry" section. Renamed the "RDAP Reverse Search Properties Registry	<section numbered="false">
	" into "RDAP Reverse Search Registry". Aligned the RDAP Reverse Search Registry	<name>Acknowledgements</name>
	template with the initial content. Introduced the "reverse_search_properties_m	<t>The authors would like to acknowledge the following individuals for the
	apping" response extension. Added the "RDAP Reverse Search Mapping Registry".	ir contributions to this document: <contact fullname="Francesco Donini"/>, <cont
	Reorganized the document to separate the implementation of a generic reverse sea	act fullname="Scott Hollenbeck"/>, <contact fullname="Francisco Arias"/>, <conta
	rch from that based on domain-entity relationship.</t>	ct fullname="Gustavo Lozano"/>, <contact fullname="Eduardo Alvarez"/>, <contact
	<t hangText="19:">Added the "Reverse Search Query Processing&qu	fullname="Ulrich Wisser"/>, <contact fullname="James Gould"/>, and <contact full
	ot; section. Changed the definition of search-condition in <xref target="revers	name="Pawel Kowalik"/>.</t>
	e-search-path-segment-specification"/>. Moved the "Reverse Search Response Spec	<t><contact fullname="Tom Harrison"/> and <contact fullname="Jasdip Singh"
	ification" section. Corrected <xref target="reverse-search-properties-mapping-e	/> provided relevant feedback and constant support to the implementation of this
	xample"/>.</t>	proposal. Their contributions have been greatly appreciated.</t>
	<t hangText="20:">
	<list style="symbols">
	<t>Changed document title.</t>
	<t>Changed "Servers MUST NOT provide or implement unreg
	istered reverse searches or unregistered reverse search mappings." to &quot
	;Servers MUST NOT provide or implement reverse searches or reverse search mappin
	gs that are not registered with IANA." in <xref target="reverse-search-defi
	nition"/>.</t>
	<t>Changed "...that the RDAP response property "ro
	les" must contain at least the specified role" to "...that the RD
	AP response property "roles" MUST contain at least the specified role&
	quot; in <xref target="reverse-search-on-entities"/>.</t>
	<t>Changed the value of the "Intended usage" prope
	rty of the "RDAP Extensions Registry" entry in <xref target="rdap-exte
	nsions-registry"/>.</t>
	<t>Changed "..., reverse search functionality SHOULD be
	available over HTTPS only." to "..., reverse search functionality MUS
	T be available over HTTPS only." 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 "Registration Data Access Protocol (RDAP)".</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 "RDAP providers are REQUIRED to" with
	"RDAP providers need to" 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. 31 change blocks.
	1096 lines changed or deleted	746 lines changed or added
This html diff was produced by rfcdiff 1.48.