| Subject: | [Gnso-epdp-team] Consensus calls, SSAC - Bundle 3 |
|---|---|
| Date: | Fri, 15 Feb 2019 23:41:45 +0000 |
| From: | Ben Butler <bbutler@godaddy.com> |
| To: | Kurt Pritz <kurt@kjpritz.com> |
| CC: | gnso-epdp-team@icann.org <gnso-epdp-team@icann.org> |
Hi Kurt,
As requested, and after deliberating
with SSAC members, here are the consensus call positions
from SSAC for Bundle 3/3B. I have grouped the
recommendations based on our position. We have provided
comments on a few for inclusion/consideration in the report
to GNSO Council. SSAC will likely provide additional
comments next week as well based on the extended deadline
referred to in your last correspondence.
Supported Recommendations:
Recommendation
#5
(old #4) - Data elements to be collected by Registrars – SSAC concurs with
the recommendation with the understanding that Registrars
must support / process Tech Contact data if it is provided
by the RNH
Explanation:
There
is some confusion whether Recommendation 5 requires
registrars to offer the Tech Contact fields to their
Registered Name Holders or not. This is because
Recommendation 5's table marks the Tech Contact fields as
mandatory to collect, but Recommendation 5 also says "if the
Registrar provides this option".
SSAC
understands that there are legal requirements for collecting
and transferring the Tech Contact data which will need to be
discussed in the implementation phase.
SSAC
believes that the ePDP Team's discussion was: Registrars
MUST offer the Registered Name Holder the opportunity to
provide Technical Contact data. Technical Contact data
should be optional for the Registered Name Holder to
provide. If Technical Contact data is provided to the
registrar, the data must be provisioned to the registry.
If that is what Recommendation 5 delivers, SSAC can endorse
Recommendation 5. If Recommendation 5 does not deliver that,
SSAC cannot endorse Recommendation 5.
Recommendation
#7
(old #5)– Data elements to be transferred from Registrars to
Registries – SSAC concurs with
the recommendation as written
Recommendation
#9
(old #7) – Contractual Compliance – SSAC concurs with
the recommendation as written
Recommendation
#10
(old #8) – Data Redaction – SSAC concurs with
the recommendation as written
Recommendation
#12
(old #9) – Organization field – SSAC concurs with
the recommendation as written
Recommendation
#13
(old #10) – Email communication – SSAC concurs with
the recommendation as written
Recommendation
#14
– Privacy/Proxy Registrations – SSAC concurs with
the recommendation as written
Recommendation
#19
(old #13) - Controller Agreement – SSAC concurs with
the recommendation as written
Recommendation
#20
(old #14) - Responsible Parties – SSAC concurs with
the recommendation as written
Recommendation
#27
(old #22) – Impact on other policies – SSAC concurs with
the recommendation as written
Recommendation
#29
– Admin Contact Transition – SSAC concurs with
the recommendation as written
Recommendation
#2
–Additional Purposes – SSAC concurs with
the recommendation as written
Dissentions:
Recommendation
#16
– Geographic Basis – SSAC cannot support
the recommendation as written (See Below)
Recommendation
#17
– Natural vs. legal – SSAC cannot support
the recommendation as written (See Below)
Reasoning:
Recommendations 16
and 17 have a negative effect on security and legitimate
contactability. Recommendation 16 allows significant
over-redaction of
data
not required by GDPR (or other laws currently in place), and
enables a race to the bottom, allowing venue-shopping
without respect to the actual
location
of registrars or registrants. Recommendation 17 enables
ongoing redaction of information about legal persons that do
not have the rights of
natural
persons. These outcomes are not balanced, and are neither
necessary nor desirable. We believe that better, more
balanced solutions are both
legally
and technically possible and should be discussed.
It
is the SSAC's position that:
Regarding
Recommendation 17:
Should
Recommendation 17 be adopted by Council, SSAC notes that the
study criteria in section #2 are unbalanced and must be
updated. They
assume
that the main decision-making criteria are the costs and
risks to contracted parties. The list is missing
consideration of how policy affects
third
parties with legitimate interests, and how the law imposes
new responsibilities(and therefore costs) on the Contracted
Parties . As SAC104
notes:
"The GDPR imposes certain new obligations and therefore risk
and costs on registrars and registry operators. It has also
imposed risk and
costs
on the parties who rely upon domain registration data for
the wide array of legitimate purposes. The GDPR calls for
balancing and the
accommodation
of legitimate security interests, explicitly called out in
Recital 49. ICANN policy should also provide balanced
solutions. In some
cases
the Initial [and now the Final] Report asks what costs will
be borne by the Contracted Parties, but does not also
evaluate the costs on all other
parties,
or the cost of not putting a balanced solution into place.
Cost or risk to registrars or registry operators alone is
not a persuasive argument
against
balanced solutions."
Supporting
Documentation:
SAC104: https://www.icann.org/en/system/files/files/sac-104-en.pdf
SAC101v2: https://www.icann.org/en/system/files/files/sac-101-v2-en.pdf
As
SSAC stated in SAC104:
"The
GDPR states clearly that it 'does not cover processing of
personal data which concerns legal persons.' We recommend
that registrars be required to
deploy
mechanisms that ensure a reliable declaration or
determination of natural or legal person status for new
registrations going forward, and to
eventually
obtain those declarations or determinations for existing
registrations and their registrants.
"Contact
data associated with natural persons should be published in
RDS where such is not prohibited by local law. In SAC101,
SSAC stated: 'The new
policy
[The Temporary Specification] allows RDDS operators complete
freedom to choose when to redact domain contact data from
publication, whether or
not
a domain contact is protected by GDPR or by any other local
privacy law. The result has been blanket redactions, hiding
more data than is legally
called
for. A more balanced and justified approach is needed..
access should not be less timely, more restricted, and less
public than law requires....
We
also note that as of this writing, most ccTLD operators in
the European Union continue to publish some (and sometimes
all) contact data fields for
domains
registered by legal persons. Some continue to publish some
personal data for natural person registrants in public WHOIS
output.'
"SAC101
also highlights RIPE-NCC's solution, which allows for the
publication of data about natural persons contained in the
contact data for
legal
persons. This process provides mechanisms that RIPE-NCC says
were specifically designed to comply with GDPR. The
RIPE-NCC solution seems to
be
balanced in that it provides contactability and does not
overapply the law. SSAC believes that RIPE's model deserves
a full examination and neutral
legal
evaluation.... We also recommend the following:
1.
Introduction of a policy requiring registrants to make a
legal or natural person declaration.
2.
Obtaining declaration would be mandatory for registrars to
implement within a reasonable time.
3.
A declaration would only be required during registration
events, i.e. when a new domain is registered, or when an
existing domain is renewed or
transferred
(by gaining registrar). This would eventually "fill in"
status data about existing/historical registrations.
4.
Registrar may make declaration on behalf of registrant if
the registrar has reasonable knowledge of registrant's
status and the registrant has not
made
a declaration of its own. This would be applicable to
registrars with specific business models, for instance when
they only process registrations
on
behalf of organizations where it is clear that the
registrant falls into a particular category based on their
relationship with the registrar.
5.
Registrant may change its declaration at any time.
6.
The absence of a declaration results in assumption that the
registrant is a natural person; i.e. a default redaction of
data.
7.
Inaccurate declarations will be subject to a revised WHOIS
inaccuracy complaint process."
Cluster #3B
Recommendation
#11
City Field – SSAC concurs with
the recommendation as written
Recommendation
#15
(new #11) - Data retention – SSAC concurs with
the recommendation as written
Recommendation
#18
(old #12) – Reasonable access – SSAC concurs with
the recommendation as written
Recommendation
#28
- Implementation Transition Period – SSAC concurs with
the recommendation as written
As always, please reach out if we
can provide any additional context or clarification.
-Ben