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