Hi all,
I agree with Rick about the opportunity to extend the milestones of all
the three drafts in order to collect further technical feedbacks and,
consequently, have most comprehensive documents at the end of the
standardization process. Soon I will publish new versions considering
the feedbacks from Tom Harrison and others updates from me. Tom has done
a basic not yet publicly available implementation that will be hopefully
added to the "Implementation Status" section in the next future. Anyway,
I don't think that the number of implementations reported in that
section could be considered a good measure for estimate the
exhaustiveness of a proposal because otherwise some recent documents
would have not been exhaustive enough. Surely, the general feeling
within the WG is a better estimator.
With regards to the possibility to expand the "Privacy Considerations"
section of the reverse-search draft, I have no objections but, at the
same time, I'm sure that the technical solution described in the draft
will remain compliant with one of the basic GDPR concepts (Art.1)
stating that personal data can be processed when supported by an
appropriate lawful basis. I believe that any possible privacy violation
is due to a data processing uncompliant with that statement and it is
common to all the applications/protocols dealing with personal data. We
have recently discussed about a possible EPP registry lock mechanism in
the light of the recent attacks to registration interfaces and the
conclusion was to think about new measures enforcing security. Despite
the (more or less assessed) risk of a possible privacy violation, we
didn't conclude to drop EPP!! And what about the privacy risks inherent
to other EPP/RDAP operations which involve the delivery of contact
sensitive information??
As it is clearly outlined in the "Privacy Considerations" section of the
reverse-search draft, allowing only authorized users to access and
process personal data is the key constraint for reverse-search
availability. For the sake of clarifying the meaning of "legitimated
user" concept, the section also includes three examples of potential
users which are legitimated to execute a reverse search by three of the
six GDPR lawful basis:
1) Registrars can execute a reverse search only on their own contacts by
the "contract" basis
2) Offical authorities can execute a reverse search by the "public task"
basis
3) Reverse search on information undisclosed by the owner can be
executed by the "consent" basis
Honestly, unless the WG requires to add more samples, I don't see how
this section could be furtherly expanded without saying something which
is already covered by its incipit.
I would like to outline as well that some of the examples above
correspond to as many examples of current reverse WHOIS services. There
are examples available on the web taking into account public contact
information and some registries already provide their registrars with a
reverse lookup on their own contacts. As far as I know, no privacy
objections have been raised to those services so far and I would be
surprised to know that a data provider is so fool to make sensitive
information available to everyone indiscriminately when this causes the
infringement of some law.
Finally, RDAP has been designed to provide different users with
different profiles which means not only to let servers to return
different views of the same response but also to diversify the query
capabilities. Reverse search is a scenario of applicability of a
profile-based capability supported by the security measures as described
in RFC7481. An RDAP provider can implement additional security services
by leveraging other measures, for example IP whitelisting, but this is
something related to security not to privacy.
In conclusion, I agree to extend for a limited time period the
milestones of the three RDAP documents just because of going more deeply
into the technical aspects.
I apologise for the long mail.
Regards,
mario
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email protected]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
