Option 1
Stephanie E Perrin
stephanie at DIGITALDISCRETION.CA
Wed May 5 14:22:17 EEST 2021
I do not know who you are arguing for Milton, but certainly not our
members. Please read the legal memos, they back everything I have been
arguing for.
FIrstly, they reject the arguments put forward by the other side of the
EPDP, that RIPE and .eu are a fit model for us and the SSAD. Secondly,
they reiterate the advice they gave us over a year ago to avoid
discriminating between legal and natural in a manner that automates
disclosure. I don't know what happened to the old Milton who fought
automated disclosure tooth and nail, but with outside counsel backing
our position, in my view it would be daft to give in now and agree to
create guidance.
If we as a matter of policy create guidance, it will be examined by any
DPA investigating a complaint about the SSAD. The co-controllers will
be held accountable for whether or not they adhere to it. It may be
reference in the Registrars Accreditation Agreements, negotiations for
which are going on as we argue about this. There is no reason that I
can see to include the guidance that has been developed in our policy, I
do not agree that this particular ship has sailed. As far as I am
concerned, it is still in drydock.
What we have been discussing in the EPDP is the guidance that the
registrars have already developed on a voluntary basis. We can simply
leave them to do this. There is no need to treat the deliberations of
this EPDP as holy writ that cannot be set aside, we have debated all
kinds of nonsense over the past three years. Putting it in a google doc
does not mean it cannot land on the cutting room floor.
I attach that guidance for those who are interested.
Kind regards, Stephanie Perrin
This chart provides guidance for how a Registrar could comply with GDPR
principles in each of the three example scenarios (see section below),
along with some notes about risks present for various options.
Principle
Data subject self-identification at time of data collection resulting in
publication of non-personal data
Data subject self-identification after initial data collection resulting
in publication of non-personal data
Registrar determines type based on data provided resulting in
publication of non-personal data
Lawfulness, Fairness and Transparency:
Controller must identify their legal basis (or bases) for processing
data and ensure the data subject is aware of the processing prior to
when it occurs. If the legal basis is consent, then consent must be
obtained prior to the processing.
See also:
Transparency:RAA 3.7.7.4
Consent:RAA 3.7.7.5
Identify and document legal basis for each processing activity
(collection, retention, publication, erasure); provide explanation to
data subject when data is collected and data subject selects person type.
Risk: Data subject identifies person type/provides consent on behalf of
a third party (Bird & Bird Memo II on Consent)
Identify and document legal basis for each processing activity
(collection, retention, publication, erasure); provide explanation at
the time when data subject self-identifies (post collection) and when
option to change or correct self-designation is provided.
Risk: Data subject identifies person type/provides consent on behalf of
a third party (Bird & Bird Memo II on Consent)
Identify and document legal basis for each processing activity
(collection, retention, publication, erasure); provide explanation at
the time when data is collected and person type is inferred.
Risk: Registrar identification post-collection does not allow for
pre-processing disclosure to data subject.
Purpose Limitation: Controller must ensure that data is not processed
beyond the purposes disclosed to the data subject
See also: RAA 3.7.7.4.1, 3.7.7.4.2, EPDP Phase 1 and Phase 2 Addendum
Purposes
All relevant processing activities (including post-publication
activities) must be included in the explanation to the data subject.
Risk: post-publication processing may be unknown to both the controller
and the data subject and thus cannot be adequately disclosed
All relevant processing activities (including post-publication
activities) must be included in the explanation to the data subject.
Risk: post-publication processing may be unknown to both the controller
and the data subject and thus cannot be adequately disclosed
All relevant processing activities (including post-publication
activities) must be included in the explanation to the data subject.
Risk: post-publication processing may be unknown to both the controller
and the data subject and thus cannot be adequately disclosed
Data Minimisation:
Controller must ensure that no data is collected/processed beyond what
is required to achieve the identified purpose(s)
See also: RAA 3.7.7.4.3, EPDP Phase 1 exercise justifying all data
elements collected
Only the minimum required data must be collected and published.
Only the minimum required data must be collected and published.
Only the minimum required data must be collected and published.
Accuracy:
Controller must take all reasonable steps to ensure data subject can
keep person type data updated and accurate
See also:WHOIS Accuracy Program Specification
Allow the data subject to provide person type information and make
updates when needed.
Allow the data subject to provide person type information and make
updates when needed.
Allow the data subject to view their inferred person type designation
and make updates when needed.
Risk:registrar incorrectly infers data subject person type, resulting in
improper publication of natural person data
Storage Limitation:
Controller must retain data only as long as is necessary for the
purposes for which the data are processed
See also: RAA 3.4, EPDP Phase 1 data retention requirement
Ensure that personal data is erased as soon as it is no longer required
to fulfill the processing purposes
Risk: When data is public and erasure is required, controller has
obligation to inform other controllers that the data subject has
requested erasure.
Ensure that personal data is erased as soon as it is no longer required
to fulfill the processing purposes
Risk: When data is public and erasure is required, controller has
obligation to inform other controllers that the data subject has
requested erasure.
Ensure that personal data is erased as soon as it is no longer required
to fulfill the processing purposes
Risk: registrar incorrectly infers data subject person type, resulting
in disclosure of data which cannot be recalled and redacted; when data
is public and erasure is required, controller has obligation to inform
other controllers that the data subject has requested erasure.
Integrity and Confidentiality: Controller must process personal data in
a way that ensures security, protects against unlawful processing
See also: RAA 3.4.1 “securely maintain, in its own electronic database…”
Ensure that only non-personal data is published
Ensure that only non-personal data is published
Ensure that only non-personal data is published.
Risk: publishing personal data due to mis-identification
Accountability:
Controller must be able to demonstrate that they comply with GDPR Principles
Document processing activities with explanation of how the chosen
implementation complies with GDPR Principles for processing data
Document processing activities with explanation of how the chosen
implementation complies with GDPR Principles for processing data
Document processing activities with explanation of how the chosen
implementation complies with GDPR Principles for processing data
Example scenarios
The EPDP Team has identified three different high-level scenarios for
how differentiation could occur based on who is responsible and the
timing of such differentiation. It should be noted that other approaches
and/or a combination of these may be possible.
1.
Data subject self-identification at time of data collection /
registration
1.
The Registrar informs the Registrant (per guidance #3 above) and
requests the Registrant (data subject) at the moment of
Registration data collection to designate legal or natural
person type. The Registrar must also request the Registrant to
confirm whether only non-personal data is provided for legal
person type.
2.
If the Registrant (data subject) has selected legal person and
has provided a confirmation that the registration data does not
include any personal data, the Registrar should (i) contact the
provided contact details to verify the Registrant claim(ii) sets
the registration data set to automated disclosure in response to
SSAD queries and (iii) Ppublishes the data (to provide
Registration Data in the publicly accessible Registration Data
Directory Services).
3.
If the Registrant (data subject) has selected natural person or
has confirmed that personal data is present, the Registrar does
not set that registration data to automated Disclosure and
Publication, unless the data subject consents to Publication.
4.
If the Registrant (data subject) makes any substantive change to
the registration data, the Registrar is expected to confirm that
these updates do not result in changes to the registrant type or
the previous confirmation of whether only non-personal data is
provided for legal person type. If the updates do result in
changes, Registrar must repeat Steps a-c above.
2.
Data subject self-identification after initial collection
1.
The Registrar collects Registration Data and provisionally
redacts the data.
2.
The Registrar informs the Registrant (per guidance #3 above) and
requests the Registrant (data subject) to designate legal or
natural person type. The Registrar must also request the
Registrant to confirm whether only non-personal data is provided
for legal person type.
3.
Registrant (data subject) indicates legal or natural person type
and whether or not the registration contains personal
information after registration is completed. For example, the
Registrant may confirm person type at the time of initial data
verification, in response to its receipt of the Whois data
reminder email for existing registrations, or through a separate
notice requesting self-identification.
4.
If the data subject identifies as a legal person and confirms
that the registration data does not include personal data, the
Registrar should (i) contact the provided contact details to
verify the Registrant claim(ii) (i) sets the registration data
set to automated disclosure in response to SSAD queries and
(iii) pPublishes the data.
3.
Registrar determines type based on data provided
1.
The Registrar collects Registration Data and provisionally
redacts the data.
2.
The Registrar uses collected data to infer legal or natural
person type.
3.
If legal person is inferred by the Registrar and subsequently
the Registrant (data subject) is informed (per guidance #3
above) and confirms that no personal data is present, the
Registrar should (i) contact the provided contact details to
verify the Registrant claim(ii) (i) sets the registration data
set to automated disclosure in response to SSAD queries and
(iii) Ppublishes the data.
4.
If the Registrar has inferred natural person or has detected
personal data, the Registrar must not disclose registration data
unless the Registrant provides consent for publication or the
Registrar Discloses the data in response to a legitimate
disclosure request.
Registrars shall not be prohibited from voluntarily utilizing a third
party to verify that a registrant has correctly identified its data,
provided that provided such verification is compliant with applicable
data protection regulations.
The EPDP Team recognizes that in all of the above scenarios, there is
the possibility of misidentification, which may result in the
inadvertent disclosure of personal data. In this regard, Bird & Bird
<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%20Phase%202a%20-%20Memo%20re.%20VSC%20and%20consent%20options%20-%2020210406.docx?version=1&modificationDate=1617804552000&api=v2>has
noted the following:
11.11.1 If the (person representing the) Registrant incorrectly
characterises personal data as non-personal, then the verification
process this triggers should confer reasonable protection against GDPR
Accuracy Principle liability for Contracted Parties, as explained at
paragraph 11.7 above, as might the legal argument set out at paragraph
11.8 above.
11.11.2 Alternatively, if the (person representing the) Registrant
incorrectly characterises non-personal data as personal data, then
whether or not they subsequently consent to its publication, the data
would still not actually be personal data, so GDPR liability cannot arise.
(…)
13. However, in our view the risk to Contracted Parties seems low, if
they take the measures described in the question presented, to avoid
personal data being (or if reported, staying) published in Registration
Data.
(…)
14.3 The data in question is likely to be low sensitivity. The scenario
being envisaged here (mistaken inclusion of personal data in published
Registration Data) seems to be most likely to occur when a legal entity
(e.g. a company or non-profit organisation) is registering / maintaining
its own domains. In those scenarios, we assume the personal data that
could be disclosed would ordinarily relate to an employee’s work details
(e.g. a company email address), not an individual’s private life.
Although the GDPR confers protection even in the workplace, the data in
question here may arguably be less capable of causing harm to an
individual than data relating to the data subject’s private life.
(…)
18. We cannot exclude the possibility of some courts or regulators
seeing things differently. Even then, an order to correct the issue
(likely accompanied by a reasonable period in which to implement
changes), rather than a fine, seems most likely, having regard to the
GDPR Article 83(2) factors discussed at paragraph 8 above. Having
checked in a selection of Member States, we can find no examples of
enforcement in relation to this. Accordingly, there is little guidance
available besides what is set out in the GDPR itself.
On 2021-05-05 12:01 p.m., Mueller, Milton L wrote:
> Kathy,
>
> > You have given us options and we chose not to differentiate legal and
> natural persons.
>
> Sorry if you misinterpreted this. As I explained, no differentiation
> is _/not/_ an option anymore.
>
> The actual choice is, Do contracted parties get to decide entirely on
> their own whether and how to differentiate? Or do we offer them guidance?
>
> *>*. As Stephanie says, “The moment you drag anything into policy, it
> will become mandatory.”
>
> Nope. The EPDP will develop guidance. After it does so, there will be
> a vote on whether it should be mandatory or not. We, the CPs, and ISPs
> will vote against that, the other crew will vote for it. There will
> not be consensus, ergo it will not be mandatory. There is no way
> guidance that has been explicitly deemed not mandatory can suddenly
> become mandatory without a new PDP.
>
> Technically, it is possible for NCSG to suddenly turn against offering
> any guidance, but I don’t think there is NCSG support for that. Both
> Manju and I have opposed it. Anyone else on the EPDP care to speak up?
>
>
> --------------------------------------------------------------------
>
> Quoting "Mueller, Milton L" <milton at gatech.edu
> <mailto:milton at gatech.edu>>:
>
> > Kathy, Stephanie, and NCSG members:
> >
> > Personally, I would have no problem falling in line with your
> > position. But there are two fatal flaws that you need to address.
> > First, you are describing only what _we_ want and not thinking at all
> > about how you get consensus. Second, your description of what we want
> > does NOT correspond to what will actually happen if we “hold the
> > line.” As much as I would like to promote harmony and unity among
> > NCSG EPDP representatives, I don’t think you have thought things
> > through.
> >
> > I know perfectly well that we don’t want any differentiation and that
> > the registrars don’t either. What you are overlooking is that the
> > other half of the EPDP does want it, and the board will see the EPDP
> > as deadlocked. So Option 1 will make you feel very self-righteous in
> > the short term, but what happens next? You are, as I will show,
> > leading us down a blind alley.
> >
> > I can think of 3 scenarios we can discuss as a basis for action.
> >
> > Scenario 1.
> > We “hold the line,” and we revert to Phase 1 recommendations
> > unchanged. There is _no guidance_. The other half of the EPDP just
> > gives up and accepts it. This result is not bad, I admit, if that
> > last bit happens.
> > But what are the Phase 1 recommendations? You have misrepresented the
> > “status quo” as not differentiating legal and natural. WRONG. What
> > will happen under this option is that any registrar or registry can
> > choose to differentiate in any way they like. And there will be no
> > guidance that you can appeal to if they do it wrong. You say you
> > don’t want registrars asking users whether they are legal or natural.
> > Well, sorry, that can happen under your Option 1. A deadlock on EPDP
> > means that differentiation is neither prohibited or required, it is
> > up to the contracted parties. Many registrars won’t do it, but some
> > will. Registries could do it, too. This is the “let the market
> > decide” option. Stephanie has become a libertarian, I guess.
> >
> > Scenario 2
> > Scenario 1 assumes the other side accepts defeat. But what if we
> > “hold the line,” and the other half of the EPDP doesn’t accept it?
> > The European Commission, the US justice department, the GAC, SSAC,
> > and of course the IPC/BC and ALAC join a strong chorus telling the
> > board “something must be done.” The Board is influenced, and refuses
> > to accept the recommendation, as it has done with the SSAD (which the
> > same group of stakeholders opposed). We have seen the Board cave to
> > GAC and governmental demands again and again, the latest example
> > being “curative rights” for IGO acronyms, which the GNSO never
> > approved. Worse, the EC may modify its NIS2 legislation to require
> > ICANN to differentiate. The US congress could intervene. The issue
> > festers for another three – five years. Several powerful players
> > start attacking the multistakeholder process. Maybe ICANN corrupts
> > its process once again.
> >
> > Scenario 3
> > Scenario 3 is that we don’t require differentiation of legal persons,
> > but we develop consensus guidance on how contracted parties should do
> > it if they choose to do it. This is the most likely scenario, and
> > it’s one that your position paper completely ignores. If you do want
> > guidance, the approach to guidance that I have suggested is best,
> > because it is a very lightweight process of self-identification by
> > registrants. By offering some differentiation it may defuse the
> > opposition of the other stakeholders. On the other hand Stephanie’s
> > complicated, expensive and power-surrendering approach is not the
> > kind of guidance we want.
> >
> > By now it should be clear to anyone who’s read this far that Scenario
> > 1 is not as wonderful as you say and may not be possible. The EPDP is
> > already deeply invested in developing guidance about how registrars
> > should and should not differentiate. We have been working on it for
> > weeks. Unless something changes radically in the next week, we will
> > actually produce some guidance about differentiation. So, I suggest
> > that we confine our debate to Scenario 2: the developing of
> > nonbinding guidance. I suggest again that allowing registrants to
> > choose to identify their registration as one of a legal person, with
> > their data published or automatically available via SSAD, creates a
> > path to consensus and to resolving the issue, whereas your preferred
> > path does not.
> >
> > To conclude, I call your attention to a pathology that is paralyzing
> > nearly all of ICANN’s working groups. Defining your position and
> > “holding the line” is a strategy that all the SGs and ACs seem to
> > adopt now. It turns all these deliberations into a bunch of people
> > re-stating their position again and again for 3-4 years,
> > re-litigating issues endlessly, avoiding any serious middle ground.
> > No thought is given to finding a solution that achieves a critical
> > mass of consensus.
> >
> > Anyone who wants to be a serious participant in developing the NCSG’s
> > position in EPDP has to answer a very basic question:
> >
> > How does this end?
> > What is your scenario for achieving the level of agreement needed to
> > pass a policy?
> >
> > Looking forward to your response.
> >
> > Dr. Milton L Mueller
> > Georgia Institute of Technology
> > School of Public Policy
> > Internet Governance Project<https://internetgovernance.org/
> <https://internetgovernance.org/>>
> >
> >
> >
> > From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU
> <mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU>> On Behalf Of
> > kathy at DNRC.TECH <mailto:kathy at DNRC.TECH>
> > Sent: Tuesday, May 4, 2021 5:35 PM
> > To: NCSG-DISCUSS at LISTSERV.SYR.EDU <mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU>
> > Subject: Option 1
> >
> >
> > Tx to Milton, Stephanie, Manju, Tapani, Farzi, Mark Leiser, Kim von
> > Arx and everyone else who commented on our dicussion of options for
> > the EPDP.
> >
> > As it's time to wrap up this issue so our EPDP members can present
> > our view to the EPDP Group, I co-wrote the email Stephanie posted
> > earlier today (attached below too). Best regards, Kathy
> > ------------------------------------------------------------------------
> >
> > Fellow NCSG members,
> >
> >> We would like to work together to share our rationale for Option 1 –
> >
> > maintaining the status quo and not asking further follow-up
> > questions, mandatory or otherwise, about legal and natural persons.
> > While the EPDP phase 2a discussions have been an educational and
> > interesting exercise, we are not under any obligation to change the
> > existing policy, or further complicate it.
> >
> > As we have all discussed, legal/natural person questions are very
> > complicated for many of our members who are often noncommercial and
> > non-profit organizations whose structure and ways of obtaining domain
> > names do not resemble those of the large corporations other
> > stakeholder groups represent. Our members may have many layers of
> > privacy protection in less-well-known sections of the GDPR, other
> > local law, Constitutions and international conventions.
> >
> > We learned that recent studies show that 50% of gTLD domain name
> > registrations are for natural persons – and at least 25% more have
> > overlapping entity and personal data (e.g., the organization name has
> > personal data in it and is thus protected as personal data).
> >
> > Stephanie and Kathy shared their concerns for legal/natural person
> > questions during our long work on the Proxy and Privacy
> > Accreditation Working Group. We worked closely with the Registrars
> > Stakeholder Group to protect registrant privacy – including Battered
> > Women’s Shelters, family planning clinics, and girls educational
> > institutions – all of which may be legal entities, but have
> > protectable data due to obvious danger from disclosure in certain
> > countries.
> >
> > In light of the complicated world around us, we support Option 1- the
> > Status Quo. We ask the NCSG to adopt this as our stance. Based on
> > the existing policy which makes differentiation of legal/natural
> > persons optional for each registrar, we believe we already have the
> >
> > - best way to fight DNS Abuse,
> >
> > - best way to protect individuals and noncommercial
> organizations, and
> >
> > - best way to follow GDPR and other applicable human rights
> > and free speech laws
> >
> > Therefore, we recommend NCSG “hold the line” and stick with Option 1.
> >
> > As the Registrars wrote in their EPDP Statement on Thursday April 29:
> > We have heard plenty of vocal support in this group to
> > [differentiate between legal and natural persons in a mandatory
> > fashion], but to date the RrSG have not heard any compelling reason
> > to create policy that makes this dramatic shift to the domain
> > registration landscape.
> >
> > We agree. Nothing will stop other stakeholder groups from demanding
> > further disclosure of data, and lobbying other parties including
> > governments. What we can do in ICANN is come up with the best
> > solution for us at this time.
> >
> > Many thanks to the members of our NCSG EPDP Team for your hard work.
> > This has been a long road. With new studies, new information and
> > legal opinions, we think we have a clear and strategic path forward.
> > We believe our position to be closely aligned with that of the
> > Registrar Stakeholder Group, which they articulated on April 29 (see
> > below).
> >
> > Best, Kathy Kleiman and Stephanie Perrin
> >
> > ---------------------------------------------------------
> > The Registrar Stakeholder Group issued their position statement on
> > Thursday (4/29):
> >
> > The members of the RrSG EPDP team have participated in this process
> > in good faith since day one and will continue to do so; however, we
> > need to be crystal clear that members of our Stakeholder Group, whom
> > we are here to represent, have voiced and recently reconfirmed their
> > strong opposition to any policy coming out of this group that makes
> > differentiation between natural and legal persons for domain
> > registrations mandatory.
> >
> > We have heard plenty of vocal support in this group to do just that,
> > but to date the RrSG have not heard any compelling reason to create
> > policy that makes this dramatic shift to the domain registration
> > landscape. The Contracted Party can make the most accurate assessment
> > of their own legal, technical, and commercial risks and obligations,
> > and is the only party that can determine what level of risk they
> > should assume. The scope of this EPDP Phase 2a is to consider if
> > changes are required for the relevant Recommendation; it has become
> > clear through this process that no such changes are required
> >
> > To the extent this group can focus its energies on guidance to
> > contracted parties which choose on their own to make this
> > differentiation, we continue to believe that is a worthwhile
> > exercise. We believe that guidance materials including educational
> > information provided by ICANN in multiple languages would help
> > contracted parties educate registrants and this would be a valuable
> > effort.
> >
> > That said, based on analysis done by our stakeholder group's members,
> > we reject the notion that the majority of registered domain names are
> > registered to legal entities. We further remind this team that we
> > have not yet seen evidence that increased publication of registration
> > data will address any of the problems which have been mentioned so
> > far in this phase, and that the registration data is reliably and
> > promptly available to those who do have a legitimate reason to access
> > it.
> >
> > Finally we note that this statement represents the official position
> > of the Registrar Stakeholder group, and statements from members of
> > other groups participating in the EPDP do not represent our group’s
> > position.
> >
> > (Source: Transcript of EPDP-Phase 2A Team Call, 29 April 2021,
> > Statement of Volker Greimann on behalf of the Registrars Stakeholder
> > Group read into the record)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20210505/e93317e6/attachment.htm>
More information about the Ncsg-discuss
mailing list