Hi Andy, On 22 Aug 2023, at 16:41, Andrew Newton <a...@hxr.us> wrote:
[You don't often get email from a...@hxr.us. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Tue, Aug 22, 2023 at 4:54 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: [ML] Firstly, would say at the outset that the authors and the WG have never thought of this feature as uncontrolled whereas it is based on the use of sensitive information. But, if on one side there are the privacy concerns to consider, on the other side there are some legitimate interests to pursue. The reasonable compromise is to make the RDAP reverse search based on PII accessible only to authorized users who are supported by lawful basis. For example, allowing the reverse search based on domain-entity relationship to registrars users but solely on their own domains and contacts. Such a concept is summarized in the following sentence of Section 13: In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only. SHOULD has been used instead of MUST for two main reasons: 1) The document describes a generic reverse search query model. Therefore, there might be reverse searches that are based on public information. 2) Provided that I don't have a legal background but, either when PII is used, think we can't exclude implementations of this feature that are publicly accessible and are still compliant with laws or regulations that restrict the use of PII. The email addresses and full names are not necessarily PII. They can be, but they can also be related to role accounts and organizations as a whole. I think the issue (to me) is that the SHOULD is blurring the two types of access into one. If it’s PII, then I’d have hoped that there MUST be access control, but if there is no PII, it’s not such an issue. But the SHOULD just says "In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only.” Again, something for the IESG to consider. Tim
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
