draft-ietf-regext-rdap-reverse-search-07.txt   draft-ietf-regext-rdap-reverse-search-08.txt 
Registration Protocols Extensions M. Loffredo Registration Protocols Extensions M. Loffredo
Internet-Draft M. Martinelli Internet-Draft M. Martinelli
Intended status: Standards Track IIT-CNR/Registro.it Intended status: Standards Track IIT-CNR/Registro.it
Expires: 8 April 2022 5 October 2021 Expires: 31 May 2022 27 November 2021
Registration Data Access Protocol (RDAP) Reverse search capabilities Registration Data Access Protocol (RDAP) Reverse search capabilities
draft-ietf-regext-rdap-reverse-search-07 draft-ietf-regext-rdap-reverse-search-08
Abstract Abstract
The Registration Data Access Protocol (RDAP) does not include query The Registration Data Access Protocol (RDAP) does not include query
capabilities to find the list of domains related to a set of entities capabilities to find the list of domains related to a set of entities
matching a given search pattern. In the RDAP context, an entity can matching a given search pattern. In the RDAP context, an entity can
be associated to any defined object class. Therefore, a reverse be associated to any defined object class. Therefore, a reverse
search can be applied to other use cases than the classic domain- search can be applied to other use cases than the classic domain-
entity scenario. This document describes RDAP query extensions that entity scenario. This document describes RDAP query extensions that
allow servers to provide a reverse search feature based on the allow servers to provide a reverse search feature based on the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 April 2022. This Internet-Draft will expire on 31 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4
3. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 5 3. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 5
4. Implementation Considerations . . . . . . . . . . . . . . . . 6 4. Implementation Considerations . . . . . . . . . . . . . . . . 6
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
5.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 6 5.1. IIT-CNR/Registro.it RDAP Server . . . . . . . . . . . . . 6
5.2. IIT-CNR/Registro.it RDAP Client . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Paradigms to Enforce Access Control on Reverse Search Appendix A. Paradigms to Enforce Access Control on Reverse Search
in RDAP . . . . . . . . . . . . . . . . . . . . . . . . . 10 in RDAP . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Reverse Whois is a service provided by many web applications that Reverse Whois is a service provided by many web applications that
allow users to find domain names owned by an individual or a company allow 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 starting from the owner's details, such as name and email. Even if
it has been considered useful for some legal purposes (e.g. it has been considered useful for some legal purposes (e.g.
uncovering trademark infringements, detecting cybercrime cases), its uncovering trademark infringements, detecting cybercrime cases), its
availability as a standardized Whois capability has been objected for availability as a standardized Whois capability has been objected for
two main reasons, which now don't seem to conflict with an RDAP two main reasons, which now don't seem to conflict with an RDAP
skipping to change at page 4, line 35 skipping to change at page 4, line 35
* role: it MUST be one of the roles described in Section 10.2.4 of * role: it MUST be one of the roles described in Section 10.2.4 of
[RFC9083]. For role independent reverse searches, the value [RFC9083]. For role independent reverse searches, the value
"entity" MUST be used; "entity" MUST be used;
* property: it identifies the entity property to be used in matching * property: it identifies the entity property to be used in matching
the search pattern. A pre-defined list of properties includes: the search pattern. A pre-defined list of properties includes:
fn, handle, email, city, country, cc. The mapping between such fn, handle, email, city, country, cc. The mapping between such
properties and the RDAP properties is shown in Table 1. Some of properties and the RDAP properties is shown in Table 1. Some of
the properties are related to jCard elements [RFC7095] but, being the properties are related to jCard elements [RFC7095] but, being
jCard the JSON format for vCard [RFC6350], the corresponding jCard the JSON format for vCard [RFC6350], the corresponding
definitions are included in vCard specification. Servers MAY definitions are included in vCard specification. Servers MAY
implement additional properties to those defined in this document. implement other properties than those defined in this document.
Partial string matching is allowed as defined in section 4.1 of Partial string matching is allowed as defined in section 4.1 of
[RFC9082]. [RFC9082].
+=========================+===============+==========+=======+======+ +=========================+===============+==========+=======+======+
| Reverse search property | RDAP property | RFC | RFC | RFC | | Reverse search property | RDAP property | RFC | RFC | RFC |
| | | 9083 | 6350 | 8605 | | | | 9083 | 6350 | 8605 |
+=========================+===============+==========+=======+======+ +=========================+===============+==========+=======+======+
| handle | handle | 5.1. | | | | handle | handle | 5.1. | | |
+-------------------------+---------------+----------+-------+------+ +-------------------------+---------------+----------+-------+------+
skipping to change at page 6, line 44 skipping to change at page 6, line 44
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to RFC 7942, "this will allow reviewers and working groups According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
5.1. IIT-CNR/Registro.it 5.1. IIT-CNR/Registro.it RDAP Server
* Responsible Organization: Institute of Informatics and Telematics * Responsible Organization: Institute of Informatics and Telematics
of National Research Council (IIT-CNR)/Registro.it of National Research Council (IIT-CNR)/Registro.it
* Location: https://rdap.pubtest.nic.it/ * Location: https://rdap.pubtest.nic.it/
* Description: This implementation includes support for RDAP queries * Description: This implementation includes support for RDAP queries
using data from the public test environment of .it ccTLD. using data from the public test environment of .it ccTLD. Reverse
search is allowed to authenticated users. Registrar users are
allowed to perform reverse searches on their own domains and
contacts. This is achieved by adding an implicit condition to the
search pattern.
* Level of Maturity: This is an "alpha" test implementation. * Level of Maturity: This is an "alpha" test implementation.
* Coverage: This implementation includes all of the features * Coverage: This implementation includes all of the features
described in this specification. described in this specification.
* Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it * Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it
5.2. IIT-CNR/Registro.it RDAP Client
* Responsible Organization: Institute of Informatics and Telematics
of National Research Council (IIT-CNR)/Registro.it
* Location: https://web-rdap.pubtest.nic.it/
* Description: This is a Javascript web-based RDAP client. RDAP
responses are retrieved from RDAP servers by the browser, parsed
into an HTML representation, and displayed in a format improving
the user experience. Reverse search is allowed to authenticated
users.
* Level of Maturity: This is an "alpha" test implementation.
* Coverage: This implementation includes all of the features
described in this specification.
* Contact Information: Francesco Donini, francesco.donini@iit.cnr.it
6. IANA Considerations 6. IANA Considerations
IANA is requested to register the following value in the RDAP IANA is requested to register the following value in the RDAP
Extensions Registry: Extensions Registry:
* Extension identifier: reverse_search * Extension identifier: reverse_search
* Registry operator: Any * Registry operator: Any
* Published specification: This document. * Published specification: This document.
* Contact: IETF <iesg@ietf.org> * Contact: IETF <iesg@ietf.org>
* Intended usage: This extension describes reverse search query * Intended usage: This extension describes reverse search query
skipping to change at page 8, line 12 skipping to change at page 8, line 34
non exhaustive list of access control paradigms an RDAP provider can non exhaustive list of access control paradigms an RDAP provider can
implement is presented in Appendix A. implement is presented in Appendix A.
The specification of the entity role within the reverse search path The specification of the entity role within the reverse search path
allows the RDAP servers to implement different authorization policies allows the RDAP servers to implement different authorization policies
on a per-role basis. on a per-role basis.
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge the following individuals for The authors would like to acknowledge the following individuals for
their contributions to this document: Tom Harrison, Scott Hollenbeck, their contributions to this document: Tom Harrison, Jasdip Singh,
Francisco Arias, Gustavo Lozano, Eduardo Alvarez and Ulrich Wisser. Scott Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez
and Ulrich Wisser.
10. References 10. References
10.1. Normative References 10.1. Normative References
[OIDCC] OpenID Foundation, "OpenID Connect Core incorporating [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating
errata set 1", November 2014, errata set 1", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 9, line 46 skipping to change at page 10, line 22
DOI 10.17487/RFC9082, June 2021, DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>. <https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021, RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>. <https://www.rfc-editor.org/info/rfc9083>.
10.2. Informative References 10.2. Informative References
[draft-ietf-regext-rdap-openid] [I-D.ietf-regext-rdap-openid]
Hollenbeck, S., "Federated Authentication for the Hollenbeck, S., "Federated Authentication for the
Registration Data Access Protocol (RDAP) using OpenID Registration Data Access Protocol (RDAP) using OpenID
Connect", <https://datatracker.ietf.org/doc/draft-ietf- Connect", Work in Progress, Internet-Draft, draft-ietf-
regext-rdap-openid/>. regext-rdap-openid-08, 8 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-regext-rdap-
openid-08.txt>.
[ICANN-RA] Internet Corporation For Assigned Names and Numbers, [ICANN-RA] Internet Corporation For Assigned Names and Numbers,
"Registry Agreement", July 2017, "Registry Agreement", July 2017,
<https://newgtlds.icann.org/sites/default/files/ <https://newgtlds.icann.org/sites/default/files/
agreements/agreement-approved-31jul17-en.pdf>. agreements/agreement-approved-31jul17-en.pdf>.
[ICANN-RDS1] [ICANN-RDS1]
Internet Corporation For Assigned Names and Numbers, Internet Corporation For Assigned Names and Numbers,
"Final Report from the Expert Working Group on gTLD "Final Report from the Expert Working Group on gTLD
Directory Services: A Next-Generation Registration Directory Services: A Next-Generation Registration
skipping to change at page 10, line 50 skipping to change at page 11, line 30
categories and assigning each category with static grants. A more categories and assigning each category with static grants. A more
dynamic approach can be implemented by using the OpenID Connect dynamic approach can be implemented by using the OpenID Connect
"scope" claim; "scope" claim;
* Purpose-Based Access Control: access rules are based on the notion * Purpose-Based Access Control: access rules are based on the notion
of purpose which means the intended usage of some data by a user. of purpose which means the intended usage of some data by a user.
It can be implemented by tagging a request with the usage purpose It can be implemented by tagging a request with the usage purpose
and making the RDAP server check the compliance between the given and making the RDAP server check the compliance between the given
purpose and the control rules applied to data to be returned. The purpose and the control rules applied to data to be returned. The
purpose can be stated within an out-of-band process by setting the purpose can be stated within an out-of-band process by setting the
OpenID Connect RDAP specific "purpose" claim as defined in OpenID Connect RDAP specific "purpose" claim as defined in
[draft-ietf-regext-rdap-openid]; [I-D.ietf-regext-rdap-openid];
* Attribute-Based Access Control: rules to manage access rights are * Attribute-Based Access Control: rules to manage access rights are
evaluated and applied according to specific attributes describing evaluated and applied according to specific attributes describing
the context within which data are requested. It can be the context within which data are requested. It can be
implemented by setting within an out-of-band process additional implemented by setting within an out-of-band process additional
OpenID Connect claims describing the request context and making OpenID Connect claims describing the request context and making
the RDAP server check the compliance between the given context and the RDAP server check the compliance between the given context and
the control rules applied to data to be returned; the control rules applied to data to be returned;
* Time-Based Access Control: data access is allowed for limited time * Time-Based Access Control: data access is allowed for limited time
only. It can be implemented by assigning the users with temporary only. It can be implemented by assigning the users with temporary
credentials linked to access grants whose scope is limited. credentials linked to access grants whose scope is limited.
skipping to change at page 11, line 32 skipping to change at page 12, line 11
03: Refactored the query model. 03: Refactored the query model.
04: Keepalive refresh. 04: Keepalive refresh.
05: Reorganized "Abstract". Corrected "Conventions Used in This 05: Reorganized "Abstract". Corrected "Conventions Used in This
Document" section. Added "RDAP Conformance" section. Changed Document" section. Added "RDAP Conformance" section. Changed
"IANA Considerations" section. Added references to RFC7095 and "IANA Considerations" section. Added references to RFC7095 and
RFC8174. Other minor edits. RFC8174. Other minor edits.
06: Updated "Privacy Considerations", "Security Considerations" and 06: Updated "Privacy Considerations", "Security Considerations" and
"Acknowledgements" sections. Added some normative and informative "Acknowledgements" sections. Added some normative and informative
references. Added Appendix A. references. Added Appendix A.
07: Updated normative refernces. 07: Updated normative refernces.
08: Changed "Implementation Status" secion. Updated informative
references.
Authors' Addresses Authors' Addresses
Mario Loffredo Mario Loffredo
IIT-CNR/Registro.it IIT-CNR/Registro.it
Via Moruzzi,1 Via Moruzzi,1
56124 Pisa 56124 Pisa
Italy Italy
Email: mario.loffredo@iit.cnr.it Email: mario.loffredo@iit.cnr.it
 End of changes. 19 change blocks. 
22 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/