Additional Information - Accuracy - Gnso-epdp-team

8 Dec 2018

Thanks for this Kurt.

To clarify a few things.

1. The ARS is the Accuracy Reporting System. It was created in response to recommendations from the first AoC WHOIS Review. In its form just prior to the Temp Spec, it was sampling 12,000 randomly selected domains every 6 months. Without going into details, among other results was that (in the most recent samples) 39% of these 12,000 domains at least one piece of contact information that was in error or strongly suspect.

2. The reference to new registrations only was not the ARS (which selects registrations randomly). It was the WHOIS Accuracy Program Specification, one of the sections of the 2013 RAA. It requires that Registrars perform certain validation and verification actions on contact info for all new registrations as well as on for registrations that are being transferred to a new Registrar and registrations for which WHOIS information is being voluntarily updated. That leaves an estimated 180,000,000 registrations that have not had such validation/verification carried out.

I confirm that what I said earlier is that I am not looking at any actions from the EPDP with an intent of improving accuracy. All I believe is within our scope is to formulate a purpose to allow ICANN to carry out studies on whether and to what extent contact information is accurate.

Regarding merging with Purpose O, that would depend on how the Purpose is formulated. If it would provide encrypted /anonymized data, then it would not be suitable for accuracy studies.

Alan

At 14/12/2018 03:56 PM, Kurt Pritz wrote:
Hi Everyone:

This email covers:

1) Why I think that, generally, Whois accuracy is not within the scope of this EPDP
2) Why we should have an accuracy discussion anyway � for pragmatic rreasons and how it might fit into the scope
3) What the bounds of that discussion should be
4) (Thinking in a glass half-full way) what the outcome might be

One. Not in scope.

While it is difficult to prove the “null set,” i.e., prove that a topic is not included in our scope, there are indications and assumptions indicating that Whois accuracy is not within our scope.

There are no Charter questions with respect to Whois accuracy. The GNSO Counsel poses fifty-some-odd questions, delving into every detail of the Temporary Specification and does not ask about accuracy. The words accurate and accuracy do not appear in the Charter, which is our only scoping document and statement of requirements.

The Temp Spec itself mentions accuracy. First with regards to ICANN’s Bylaws and mission to maintain and improve Whois accuracy. However, those requirements pre-date and survive GDPR and are not affected by GDPR. These objectives are addressed through other policies and the regular negotiations between ICANN and contracted parties. These efforts are ongoing and not affected by 25 May.

The other reference to accuracy in the Temp Spec is in the paraphrasing of the GDPR to maintain accurate and up-to-date data. The ICO states that "the main difference in practice [between the 1988 Act and the GDPR] is that individuals have a stronger right to have inaccurate personal data corrected under the right to rectification.” These and other statements lead one to believe that by accuracy, the GDPR requirement for accuracy is data subject focused, that the processor must accurately report data and updates to data made by the data subject.

There are other indications that accuracy is not in our scope but, as I said above, it is difficult to prove the null set and one can always point the word ‘accurate” in the GDPR>

Two. We should discuss accuracy.

>From a pragmatic standpoint, we should have a Whois accuracy discussion rather than:
1) talk about whether we should have it, or
2) having to explain to the Council and others why we are not having it

It is a better strategic approach for our group to hear proposals rather than not or rather than to discuss whether to hear them.

In addition, Alan Greenberg said in his email that the proposals about Whois accuracy are straightforward and high-level and (in my interpretation) referred to it being a “purpose for processing registration data.” One way for the discussion to come within scope, is that it would be under the rubric of a new purpose.

In any case, if we stick to the “solution space” in our discussion, we might find a mutually agreeable accommodation. If not, I understand that we might have spent some non-value-added time, but, out of respect for some of our team members, I am willing to spend some time to consider targeted proposals.

Three. Bounded discussion.

First here is what our discussion should not be about:

1) Our discussion should not be about whether to discuss accuracy.

2) A specific new contractual requirement for registrars to implement in order to improve accuracy that would win control of the group.

a. The current contractual requirements seem to address the key GDPR aspects. The GDPR call for keeping information current is addressed via the ICANN has the Whois Reminder Policy. Other contractual obligations require registrars to investigate reports of inaccuracies and to update data in a timely but careful manner as required by GDPR.

b. If other specific accuracy measures are sought, I know from personal experience that those discussions are detailed and take significant time as their is operational nuance and unintended effects that must be taken into account. I do not think it is for us to have that discussion.

c. We are probably on the wrong side of the picket fence to have that discussion.

The discussion could be about providing the right level of information to ICANN community-developed programs to assess Whois accuracy providing there is a lawful basis for such a disclosure.

Four: Proposal

My thinking is (as I have written in an earlier email) that the ARS project (where ARS stands for something having to do with data accuracy) could be included in the Purpose O that has been discussed - a data disclosure to ICANN for research purposes. Alan’s recent email indicated that ARS applies to only new registrations and other programs might be useful in measuring existing registrations. In this case, Purpose O could contain language that would allow disclosure of data to ICANN for programs that pass the lawful basis test.

(Remember, we are still waiting for ICANN to aver that Purpose O is necessary and desired for the organization to accomplish its mission before we consider it further.)

This use of data might fall under Purpose B but, because ICANN is not a typical third-part, it might make sense to create this Purpose O and include ARS-type studies. In either case, each disclosure would have to pass the lawful basis test.

Thanks for reading all that. I hope it is helpful toward you thinking.

Best regards,

Kurt

On Dec 13, 2018, at 8:12 AM, Amr Elsadr < aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> wrote:

Hi Alan,

I don’t agree with your interpretation of the EPDP Team Charter. The intent is not to “ensure that ICANN can continue to fulfill its mission in compliance with GDPR”. It is “to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law”.

The scope of the EPDP Team’s mission is narrower than you suggest it is, which is appropriate to the whole purpose of any EPDP, which are only allowed to be initiated under very specific circumstances (Check Annex IV<https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-4-epdp-manual-18jun18-en.pdf> of the GNSO Operating Procedures):

  *   to address a narrowly defined policy issue that was identified and scoped after either the adoption of a GNSO policy recommendation by the ICANN Board or the implementation of such an adopted recommendation
  *   to provide new or additional policy recommendations on a specific policy issue that had been substantially scoped previously, such that extensive, pertinent background information already exists

As you surely recall, these specific circumstances detailed in the GNSO OPs resulted from the recommendations of the GNSO Policy and Implementation WG.

Thanks.

Amr

On Dec 13, 2018, at 4:34 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote:

Amr,

The intent of this PDP is to ensure that ICANN can continue to fulfill its mission in compliance with the GDPR. Implicit in this is to ensure that ICANN's contracted parties can also operate in compliance with the GDPR.

Registrant data accuracy is important as indicated by the accuracy provisions currently in the RAA and as evidenced by the ICANN resources put into the ARS. We are not asking that this PDP address accuracy    as such, or provide methodology to improve it. All we are looking for is a Purpose that will allow ICANN to continue to address the issue. Creating such a purpose is not a major undertaking and it will not unduly delay our entire process.e

You and Alan W reference the RAA Accuracy Program Specification. If that applied to all gTLD registrations it would indeed be sufficient. But it doesn't. It applies only to new registrations, registrations that are being transferred to a new registrar, or a change to the WHOIS or registrant account details. That leaves an estimated 180,000,000 registrations that it does not apply to.

Aside from being a crucial part of ICANN's responsibility. It is also a GDPR responsibility. GDPR Article 5 (d) reads "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’)".

So data must be accurate in regard to the purposes for which it is processed. We have purposes (2 and 6 are examples) where the processing is the transfer to parties who have a reasonable expectation of accuracy.

Alan

At 13/12/2018 08:15 AM, Amr Elsadr wrote:
Hi,

Very much agree with all 3 of the notes by Alan below. In terms of the EPDPâ��s li limited scope, I donâ��t see what we might be attemptinging to achieve by pursuing the topic of accuracy. Even if the practicalities involved (such as potential reasonable steps to be taken to correct or delete inaccurate data) might require further deliberation, either now or during the January F2F meeting, what is the overall objective we are aiming for that isnâ��t already addressed by existing policies, su such as the WHOIS Accuracy Program Specification? And considering Alanâ��s (in my view) accurate description of the scope of this is EPDP being to either confirm or amend the provisions of the Temporary Specification, how would this objective fit within this scope?

I donâ��t see any mention of accuracy in tn the Temporary Specification, except for one in which it is included in a quote from the bylaws in section 4.3, and another in Appendix C, where Article 5 of the GDPR is basically repeated, and which Alan has addressed in Note 1 below. Furthermore, I donâ��t see a review of WHOIS IS accuracy mentioned anywhere at all in the EPDP Teamâ��™s Charter. Unlike the topic of the access model, I donâ�℄�t even understand how accuracy fits within the mandate of the next phase of the EPDP.

In terms of a substantive look at the existing WHOIS Accuracy Program Specification, I would be happy to review this specification at some point in the future (in another PDP). It does include a few â��reasonableâ�� scenacenarios in which data accuracy might need to be enhanced, either by validation or verification of this data. However, the very tight deadline of 15 days in which this is required to be done - with  failure to do so resulting in the RNH being penalized by suspension of a domain name involved - does not seem reasonable to me at all. GDPR addresses accuracy as a right of the data subject, not as an obligation that would result in the data subject being held accountable. So again�¦, this seems to me to be commpletely out of scope of what we need to get done over the next couple of months.

Unless we first have a clear understanding and agreement on how this is relevant to our current work, and what we would like to achieve by pursuing it, I donâ��t see howhow it is constructive to spend more of the little time we have left on this issue.

Thanks.

Amr

On Dec 11, 2018, at 2:02 PM, Alan Woods <alan@donuts.email<mailto:alan@donuts.email>> wrote:

Thank you Margie for this comprehensive review.

I have 3 notes.

1) Regarding the ICO statement:  "So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy."   To be clear the 'you' here is relating to the controller's use of the data and whether that use, by the controller, in the processing of inaccurate data, has asignificant impact on the rights of the data subject, or 'others'. The USE of this data by the controller is the registration of a domain or the application of our T&Cs; this is not referring to the use by a 3rd party (be that the registrant or indeed from your POV, Facebook). So from the Controller's POV, all registration data is tested and the registrant is indeed required to confirm that data (WHOIS Accuracy Specifications). This seems very reasonable, given the data collected and the use to which it is put. Are you expecting the controller to second guess, not 1 but 2 (collection and confirmation process) approvals of the data subject, when the objective is to ensure that the registrant is contactable, in the event of query on the domain. Furthermore, there is a secondary system of accuracy testing, insofar as where WHOIS data is found to be inaccurate, a complaints process does exist, and let's not forget that the consequence for the registrant for not updating their data, is the suspension of their domain. (Which, as Stephanie Perrin has rightly reminded us, is a pretty severe and hefty consequence for the data subject on a very tight turnaround)

"Other" interests : Beyond this, the impact of inaccurate registration data in the USE by the controller, i.e. the registration of the domain, to your interests as an 'other', if I may surmise, only goes so far as to your ability to seek redress for matter you perceive to be IP infringement in the domain name itself. Continued inaccuracy of the registrant data (if any remains) does not however affect the availability of the RPMs which do not require the registration data to be accurate, as under the temp spec, even doe claims are now valid. In addition should you choose to go the court route, obtaining service, substituted or otherwise, should be a simple matter for any lawyer. I fail to see the how the 'use', therefore is objectively prejudicing you, or how more watertight accuracy would make any substantial difference on the avenues already available. I must say it seems pretty unnecessary, and likely unreasonable, given the use to which the data is put!

So my point is I fail to see how the use of the data, by the controller, is substantially prejudicing the interests for which the BCs stand. Accuracy in this context, and the safeguards inbuilt are objectively reasonable given the nature of the data and the avenues of redress present. As such, this is accuracy sufficient to meet the requirements of the GDPR.

2) SCOPE I am also struggling to see how this is in scope of the ePDP team. Our task, again, is to decide whether the provisions of the temp spec are capable of being confirmed as consensus policy, with or without modification, as is necessary, to ensure compliance with Data Protection law. Our job is not to rewrite the WHOIS accuracy specification, but to apply the expectations of the GDPR (and other legislation as may be applicable). As written, the temp spec's approach to accuracy vis Ã¡ vis the use of the data in the registration process, is reasonable in the circumstances, and prejudice caused by inaccuracy present is mitigated by the availability of redress mechanisms that are not actually dependent on the accuracy of the data, surely this is objectively a sufficient level of accuracy for that purpose.

3) Viable Alternative? Although I don't believe an alternative is necessary, nor do I believe this task is in scope for the ePDP, you have also have not provided us with a workable or viable alternative . Perhaps you could provide us with such a viable option as to how you think accuracy may be improved in the registration of a domain, in a manner that is proportional to the objective of the use (i.e the registration). Perhaps then we may be in a position to make a recommendation to the GNSO for future policy development?

Kind regards,

Alan

Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
________________________________
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

  <https://twitter.com/DonutsInc>   <https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

On Sat, Dec 8, 2018 at 12:49 AM Margie Milam <margiemilam@fb.com<mailto:margiemilam@fb.com>> wrote:

Hi-
I was asked to provide further background for the accuracy discussion after yesterdayâ��s EPDP call.   Here is some information to fo frame our further  analysis:

SCOPE

This EPDP was chartered â��to determine if the Temporary Specificationon...should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law.â��  In order to fully comply with GDPR, data --- the very subject of this EPDP -- is required to be accurate.

According to Article 5.1(d)  of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay."  Article 39 also has similar language.  Within the GDPR, this is the second of three principles about data standards, along with data minimization and storage limitation that needs to be addressed.  While we have had much discussion about data minimization and storage limitations, whatâ��s clearly missing to finalize our deliberaerations and output about data standards is our discussion about data accuracy requirements.

The ico. (Information Commissionerâ��™s Office in the UK) points out in its writings on â��Principle (d): Accuracyâ��<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_accuracy_-23steps&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=RhTeIrHiyk5mS4H700KfDrYVVkEJElZPkbQjxDs2DOs&e=> that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a â��clearer proactive obligation to take reasonable ststeps to delete or correct inaccurate personal data.â�� The ICO notes that while â��[t]here are clear links hehere to the right to rectification, which gives individuals the right to have inaccurate personal data correctedâ�� � â â��[i]n order to ensure that your records aare not inaccurate o or misleading in [the case of personal data someone else provides], you must:
                …
take reasonable steps in the circumstances to ensure the accuracy of the information; and
carefully consider any challenges to the accuracy of the information.â��

The ico. goes on to say that â��The more impmportant it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy. So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy. This may mean you have to get independent confirmation that the data is accurate.â€�  We can all agree that the accuracy of domain name ownership is paramount to collection of WHOIS/Registered Name Holder data in the first instance.  In addition, since this data will be used by others (with a lawful interest), ensuring that it is accurate for them is relevant.

This isnâ��t a new concept for discussion, as as you may recall that the European Commissionâ��s technchnical input on ICANN's proposed GDPR-compliant WHOIS models<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_gdpr-2Dcomments-2Deuropean-2Dcommission-2Dunion-2Dicann-2Dproposed-2Dcompliance-2Dmodels-2D07feb18-2Den.pdf&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=YxaHZrnJlPuW_9bhzSZjJ7TOa-8_9ht63KuwYlhHWxA&e=>underscored the GDPR's "Accuracy" principle and made clear that â��reasonable steps should be taken toto ensure the accuracy of any personal data obtainedâ�� forr WHOIS databases and that ICANN should be sure to incorporate this requirement in whatever model it adopts.

The ico. points out that<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_accountability-2Dand-2Dgovernance_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=UWaASFRkG2npkSZLHMfzDbjdajEbgoyFxk7wLtqAmbc&e=> â��[o]ne of the biggest changes introduced by the GDPR is arounund accountability � a new data prrotection principle that says organnisations are responsible for, and must be able to demonstrate, compliance with the other principles ... [y]ou now need to be proactive about data protection, and evidence the steps you take to meet your obligations and protect peopleâ��s rights.â�� With the maie main thrust of the EPDP being to ensure that the WHOIS policies ICANN and the contracted parties adopt comply with the principles of the GDPR, these accountability principles shouldnâ��t be taken lightly.

Consistent with these commitments and the GDPR, accuracy is an issue fully within scope of the EPDP so that ICANN and contracted parties proactively address how they will ensure the accuracy of data in the first place, not just how they rectify inaccurate data brought to their attention after collection -- we simply see no way around the EPDP affirmatively addressing the GDPRâ��s accuracy principle in our deliberatiations and output.  Especially since accuracy is addressed in the Temp Spec itself (see 4.1), which states ICANN is responsible for â���Maintenance of and access to accurate and up-to-date information concerning registered names and name serversâ��.

Additional Information - Accuracy

Margie Milam

Alan Woods

Amr Elsadr

James M. Bladel

Alan Greenberg

Alan Greenberg

Amr Elsadr

Kurt Pritz

Alan Greenberg

Alan Greenberg

tags

participants (6)