<div dir="ltr">This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:<br>
<br>
> My biggest fear<br>
> is that in the monitoring that companies like mine do for banks, payment<br>
> providers, e-commerce companies, etc. that helps determine whether a<br>
> merchant is who they say they are, and whether they are engaged in other<br>
> bad activity (i.e., laundering money) will be unable to obtain access to<br>
> the Whois records we need in order to preserve the integrity of the<br>
> payments system, protect payment providers from risk, and derivatively<br>
> protect consumers.<br>
<br>
Modulo the inclusion of "Whois" in the above, that all seems<br>
reasonable. What you are saying is that you need a mechanism by which<br>
you can create risk analyses with respect to some domain name. But,<br>
<br>
> In other words, my fear is that we'll lose access to<br>
> Whois records, which we need for that purpose.<br>
<br>
this does not follow.<br>
<br>
Consider, for instance, that RDAP works via http(s), and that we have<br>
several kinds of authentication and authorization mechanisms related<br>
to https, and such things can be federated. It is a short hop from<br>
that knowledge to understanding that someone(s) could operate a<br>
service that authenticates service providers like you, using tokens<br>
provided by the to-be-evaluated domain names. A payment provider or<br>
whatever, when offering service to a customer, could obtain from that<br>
customer a token of consent allowing it to obtain the relevant data<br>
from the registries and registrars in question. That token could then<br>
be provided to the authorization service, which would then<br>
authenticate your request to the RDAP servers and they could provide<br>
you the data you request. This is by no means an impossible task --<br>
every time you apply for insurance online or log into a payment<br>
provider via Google or Facebook or Amazon, you're doing this. This is<br>
a technique that is already deployed all over the Internet where real<br>
money is involved, so I fail to see how it could not be used in our<br>
case. (In addition, you may not actually need the particulars of an<br>
individual -- it might be enough for you to be able to tell whether<br>
the domain and people behind it are related in some important ways to<br>
some other domain. But we're getting ahead of ourselves in the use<br>
case description here.)<br>
<br>
This is also why separating the collection of data from questions<br>
about display and so on is necessary: we need to understand as a group<br>
the compelling use cases that the RDS data can support. I agree that<br>
reputation-of-vendor systems are among those uses, and that we ought<br>
therefore to include support of such things in what we think we want<br>
the system to be able to support.<br>
<br>
Of course, all of this does represent some cost to you -- your<br>
existing service would need to change to reflect the new business<br>
logic and access rules and mechanisms and so on. But I don't think<br>
this WG has so far accepted, "But that's how we do it now," as a<br>
legitimate purpose.<br>
<br>
Best regards,<br>
<br>
A<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">_________________________________<br>Note to self: Pillage BEFORE burning.</div>
</div>