[gnso-whois-wg] Re: legal authority for OPoC Reveal responsibilities

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

From: Summary of 18 July Whois Working Group call

At 2:45 PM +0200 7/19/07, Maria Farrell wrote:

>1. Section 3.2 "REVEAL" versus "on request rapid take down by Registrar
>when timely RELAY or REMEDY fail".
>
>Chair?s summary of discussion: Some agreement that if access proposals
>could be simple, cost effective and rapid, they may fulfil most but not
>all of the functions grouped under ?reveal?. There are certain reveal
>functions such as finding out from the registrar who the registrant is,
>notice on those engaged in criminal activity, and the potential cost of a
>manual process as opposed to automated one if burden is made a registrar
>responsibility rather than the responsibility of the OPoC.

-----

** This description seems a bit confused to me.

I don't see a "notice" function as part of Reveal, but rather Relay, which
is not in question as a legitimate function of the OPoC.

I'm not sure what "manual process" was referred to here, but I'm still not
certain why a Registrar would need to have any manual process involved in
providing Access, if the Access paradigm is properly designed.  I don't
recall any such point being agreed upon during the July 18 phone call.


Most importantly, if we are indeed to consider retaining any Reveal
function of the OPoC, then I would suggest that we absolutely must define
in some considerable detail under what legal jurisdiction and authority
such responsibilities would be established, enforced, and adjudicated.

What happens if an OPoC fails to Reveal?

Does the OPoC have legal liability, and if so, under what legal paradigm?
Is that paradigm naturally occurring under the laws of the sovereign nation
where the OPoC operates?  If under national law, I would assume there must
be some sort of contract involved, as ICANN has no jurisdiction to make
laws for sovereign nations.  If separate from national law, then ICANN
seems to be establishing its own private global law, and I'm not sure under
what authority it may do so (and what resources it has allocated to support
such activities).

If there is indeed some sort of contract, how exactly does it flow through
ICANN's contractual environment with registries, registrars and/or
registrants?  How is enforcement applied and by whom?  Do registrars take
on the responsibility of forcing OPoCs to Reveal, or do registrars take on
the Reveal function directly/manually, or do they simply take the offending
domain off the Net as the Damoclean Remedy when OPoC Remedy fails?

What happens if this paradigm runs into conflict with national laws?  If we
cannot ensure that the OPoC is legally unconflicted, then no one in their
right mind would agree to serve as an OPoC in the first place, as the legal
risks would be too high.


And, if we retain some Reveal function of the OPoC, then how do we define
legal standing of a Requestor to demand OPoC-Reveal?  If there are no
selective criteria to define Requestor standing for OPoC-Reveal, then
potentially any random Requestor can get the hidden contact data for any
natural-person Registrant and the privacy goals of having an OPoC in the
first place are systematically thwarted.  This yields a process for which
privacy-protection claims are made but where effective privacy protections
do not exist in practice.

In short, it seems to me that the same authentication issues that exist for
Access must exist for Reveal-Requestor as well, if Reveal is not to
constitute an abject loophole in the privacy protection process.  If we can
resolve meaningful authentication for Requestors of OPoC-Reveal, then we
might well be able to resolve it for Access.  If we can't resolve it for
Access, then we may not be able to resolve it for Requestors either, and
then we have a serious problem with fundamental efficacy of the whole OPoC
paradigm at root.

In my opinion, it would be far worse to institute a process that purports
to protect privacy but then fails to do so effectively, rather than simply
to decline to implement any such process at all at this time, and leave the
issue open for further work in the future, with the goal of devising an
adequate authentication paradigm to apply to the process.

To institute a sham process would foreclose further development of a truly
effective process.  It would also seriously erode ICANN's public
reputation, as it leaves wide open a bald charge of Orwellian double-speak
in claiming that it has a process to protect privacy of natural-person
registrants when in practice it has no such thing.  This would
systematically undermine the ICANN's institutional legitimacy.

This seriously threatens to prevent a consensus result for this WG, in my
opinion.

Dan