[gnso-rds-pdp-wg] List discussion topics

Rod Rasmussen rod at rodrasmussen.com
Thu Jul 27 17:22:44 UTC 2017


Clipping off most of the long thread here.

So, we actually discussed this issue of “contact permission" at length in the EWG and covered it in our report.  At the time we were thinking more along the lines of fraudsters putting in a company’s actual contact data in various fields of whois (say the corporate address and phone) to make it look more authentic, but keeping the all-important admin e-mail address to one of their throw-aways.  This is quite common.  The issue Volker brings up makes it even more important to have mechanisms for listed contacts to approve of their information being used for the designated role.  This is important for web hosting operations for example, who may be listed as the “technical contact” for a domain they haven’t hosted in many years.  Such a mechanism has to allow for that contact to opt out of their role in the future.  Again, this was very nicely covered in the treatment of contacts as separate data objects that are actually controlled/edited/moved about by the contact entity themselves.  When a domain registrant wishes to list a particular contact for a role, they can either get something like a code from that entity to use ahead of time, or use an approval process.  Most of this can be automated by a registrar for most domains, and corporate registrars would be able to automate most of the more complex situations that large companies may have.  This makes it easy for registrants to change contacts if they change service providers (e.g. they change law firms and need to update legal contacts) and let’s contacts easily opt-out of handling roles for domains they no longer support (e.g. a proxy service that isn’t getting paid any more).

Again, territory where I think we did a really good job anticipating issues within the EWG - see sections III g. RDS Contact Use Authorization on pages 39-40 of the final EWG report for a description.  I would suggest being familiar with the entire section though for full context.  This also ties into validation and an entity’s desire to be a globally unique contact that is touched on later in the report.  The whole system described allows for contacts to ensure they are unique (non-spoofed), know about every domain they are associated with, and know their roles for their domains - very elegant.  Given the technologies and services that have been developed for automating notifications and handling of notifications for a bevy of Internet services out there, IHMO, this is far easier to implement, maintain, and provide customer service for than many of the more manually driven processes we’ve traditionally seen in the domain name ecosystem.

Cheers,

Rod

> On Jul 27, 2017, at 9:58 AM, Volker Greimann <vgreimann at key-systems.net> wrote:
> 
> Sadly it is no longer solved as we simply cannot rely on such assurances anymore. The data processor has to ensure that the data subject has consented to the use of his data and that simply is not the case if the single touch point is the registrant, or even his agent. 
> 
> It is the data processor and the data controller that will ultimately face the consequences, not the registrant.
> 
> And yes, identity validation is too hard and expensive for this industry and the prices people have come to expect. 
> 
> And while you personally may not have heard of Admins suing a registrant, we have seen many cases where our privacy contacts (legal entity) or local presence services (legal entity or indivisual, dependent on registry requirements) are used by registrants without permission. This usually leads to a domain delection request to the registrar or registry by the admin. And we receive requests for removal of contact data from people who did not know their data was used on a regular basis.
> 
> Best,
> 
> Volker
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170727/7db8abf2/attachment.html>


More information about the gnso-rds-pdp-wg mailing list