The next GNSO Next-Gen RDS PDP Working Group meeting will take place at ICANN59 in Johannesburg on Wednesday, 28 June at 08:30 local time
For other times:
PROPOSED AGENDA:
Primary Objective: Maximize use of F2F time to start deliberation beyond "min public data set" (MPDS)
1. Introductions and SOI Updates (08:30-08:35)
2. Background (08:35-08:45)
a) Brief overview of WG charter and work plan
b) WG rules and expectations of PDP WG members
3. Brief updates on: legal analysis, ccTLD responses (08:45-09:00)
4. Cross-Community Session results (09:00-09:30)
a) Plan to consolidate/review/reflect feedback
b) Plan to finish deliberation on "min public data set" (MPDS)
5. Start deliberation beyond "minimum public data set" (09:30-12:00, including break)
a) gTLD registration data element buckets (MPDS)
- Minimum public data set
- "Thin data" elements not yet addressed
- "Thick data" elements, including Registrant data, Admin/Tech contact data
- New data elements that may be required
b) Choose most effective starting point for Tasks 12/cd
- See Work Plan Task 12 for approach to reach consensus on Foundational Question
- 12c = Key concepts for UP, DE, PR for data beyond MPDS
- 12d = Key concepts for GA for data beyond MPDS
- Initial focus on Legal person data or Natural person data?
c) Deliberate on chosen charter question for chosen data "bucket"
6. Confirm action items, proposed agreements, and next meeting date
Abstract and links to all session recordings
Adobe Connect
English Audio
AC Chat
Transcript part 1 (before break) and part 2 (after break)
Notes - RDS PDP WG F2F Meeting at ICANN59
These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki here.
1. Introductions and SOI Updates
- Attendance will be taken from AC
- Please remember to state your name before speaking and remember to mute your microphones when not speaking
- SOI updates: Maxim Alzoba
2. Background
a) Brief overview of WG charter and work plan
- See slide deck: ICANN59-RDS-PDP-WG-F2F-Slides-v3.pdf
- GDPR session yesterday – Theresa Swinehart announced formation of a task force to examine existing contract requirements with respect to data protection and privacy. Michele Neylon is our WG’s representative to that task force. The task force will do their best to not duplicate our efforts, and their findings may even contribute to our work.
b) WG rules and expectations of PDP WG members
- History of WHOIS has been volatile with many diverse views. All view must be voiced and recognized, but that creates tension. In a WG with over 190 members and 70 observers, there are additional challenges.
- ICANN Ombudsman Herb Waye shared a few remarks about communicating in a respectful and civil manner. Please report any instance of disrespectful behavior to the ombudsman: herb.waye@icann.org
- Goal is to collaborate constructively to find compromises and come up with solutions to our charter mandate.
- Note WG rules (RDS PDP WG List Discussion Rules.pdf). As the list is large, please think before replying +1 whether that reply is really needed. Try to remain focused and succinct in your contributions to topic under discussion.
3. Brief updates on: legal analysis and ccTLD responses
- Legal analysis sought based on WG member requests for independent analysis by outside counsel. Leadership team evaluated proposals from several firms, with help from WG member advisors, and selected a firm for this project. We are now completing contracting with a firm that appears to be broadly respected by stakeholders. The project will produce a report with their analysis of WG questions within 6 weeks.
- Noted that this is just the first legal analysis; additional legal analysis needs are anticipated in the future, each project to address specific WG requests. It was suggested that we consider whether a retainer arrangement would be appropriate for on-going Q&A on applicable laws.
- Noted that the WG’s question list originally prepared for ICANN58 session may need to be refined; confirmed that refinement is anticipated as part of the legal analysis project.
- ccTLD responses to questions sent to 18 ccTLD operators have been received from .me, .ie, .ca thus far – after more are received, we will look for common threads. See ccTLD responses wiki page for links to all responses; all responses to be added to this page as they are received.
4. Cross-Community Session results
a) Plan to consolidate/review/reflect feedback
b) Plan to finish deliberation on "minimum public data set" (MPDS)
- To allow us to move on beyond what’s been covered thus far, we will consolidate cross-community session feedback for consideration during our second pass on these agreements
- Also the plan for loose ends on MPDS – remember and address during our second pass
Action: Staff to document cross-community feedback for WG consideration during second pass on fundamental charter questions. For links to session recordings, scribe feed, and notes from the cross-community session, visit this link: https://community.icann.org/x/ygffAw
5. Start deliberation beyond "minimum public data set"
a) gTLD registration data element buckets
- Registration data elements defined in the 2013 RAA can be subdivided into these buckets:
- Minimum public data set (MPDS)
- "Thin data" elements not yet addressed
- "Thick data" elements, including Registrant data, Admin/Tech contact data
- New data elements that may be required
- We spent the past few months deliberating on the MPDS; it is now time to move on to deliberating on the same questions, but expanding scope of deliberation to other data elements
b) Choose most effective starting point for Tasks 12/cd
- See Work Plan Task 12 for approach to reach consensus on Foundational Question
- Task 12c = Key concepts for UP, DE, PR for data beyond MPDS
- Task 12d = Key concepts for GA for data beyond MPDS
- Would it help to focus first on Legal person data or Natural person data?
Discussion
- See slide 21 – leadership team proposes focusing on Legal Person Registrant Data next
- Some ccTLDs take this approach – distinguishing at time of collection, but are these separable?
- Should we be looking at the superset of contact data, to determine how we’ll deal with contact data overall, then figure out how to display/collect/process Legal versus Natural person data?
- Alternate proposal: Look at the superset of all elements that the EWG came up with as first step
- In some jurisdictions a natural person can't be involved in entrepreneurship without forming of a legal body reported to the tax agency, so he's something between natural and legal person.
- Consider having a special flag for fields which clearly says that these fields (e.g., address, name) are personal data or not. In Russian Federation as a registrar, we came to the conclusion that until clearly shown, it's not possible to distinguish between natural and legal persons.
- If you start with a small subset, it will be a problem that you haven't actually defined your perimeters. Figure out your superset -the legal perspective is figure out all the data elements you want to gather - and then figure out how they sort [into natural person data or not]
- Currently most entities self-identify in the Registrant Organization field by indicating their legal name. However, many natural persons also put their own name in the Organization field.
- There are necessary distinctions between Legal/Personal and Commercial data subjects, but the priority now should be the personal data for individuals. The deadline for conformity with GDPR in and for EU individuals is rather short.
- The requirements we establish in this PDP are for the future, not for immediate resolution of existing Whois system compliance with GDPR.
- If we start with elements that are clearly Legal Person, we might be able to make progress on those quickly, then deal with the harder agreements
- Legal/Natural Person distinction applies in EU law but does not apply in all national laws. In some countries, privacy rights go to the speaker, which may be a group and not an individual, due to risk of persecution for some groups.
- Different jurisdictions need to be applied to data elements as a meta set, and then apply specific laws within each jurisdiction to the data
- If we look at an element like Registrant Organization, which is clearly Legal Person, we know we won’t convey personal privacy rights to that entity and that might simplify agreements on how we’ll collect and display that data element
- Want ability for an organization to put all the data out there, if they choose
- Note that EWG identified a purpose-based contacts approach, which included data elements beyond today’s Admin and Tech contacts (it’s not just the Registrant’s entity type)
- Data elements are not different, it’s just that it belongs to different data subjects – for example, people enter their own name in the Organization Field, so it is not as simple as checking the Org field to determine entity type
- Self-identified registrants as entities is a different discussion than looking at commercial activity on a website using that domain name registration
- Commercial vs non-commercial discussion has already been settled in PPSAI PDP, as it pertains to provision and use of Privacy/Proxy services
- Don't believe the PPSAI debate (and result) is relevant to the current discussion, because PPSAI PDP [charter and scope] was different.
- Self-identification as a Legal Person could allow a given set of rules to apply
- Important to talk about design of data before talking about processing. For fields marked as personal data, there might be different storage requirements, etc.
- Even in the case of a Legal Person entity, there may be fields that are personal data
- Focusing on edge cases and grey areas is not a great place to start – there will always be registrations associated w Legal Persons and registrations associated with Natural Persons, if we start with those, we can make progress and then we can tackle edge cases
- If we examine the data set, need to avoid straying into how data will be used when establishing the universe of data.
- Proposal: Concentrate on the superset of data elements that may be collected and possibly displayed in the RDS. That is, review the entire table of proposed elements, decide what to delete/add, and then decide what to collect/display.
- Based on straw poll, we will approach this from a data set perspective first
- Note: Still need capacity to add or remove data elements in the future – this could be one of the WG’s recommendations (e.g., communication methods may change for contact in the future)
c) Deliberate on chosen charter question for chosen data "bucket" --
- See above discussion and straw poll. Agreed next focus area: Data Element requirements overall
- See ADDITIONAL MATERIAL: Data Elements Handout.pdf,
- Quickly excerpted during the break from EWG Report Annex D to support deliberation using the approach identified above
- Contains list of data elements proposed in the EWG Final report; these are the data elements agreed upon by the EWG as needed to serve the set of permissible purposes in that report
- Question: You don’t collect data that is not required, so shouldn’t you start with the purposes and the data elements they need, then review the set of data elements? (Yes)
- The list contains data elements that somebody COULD use; these data elements were not all obligatory (i.e., mandatory to collect or display)
- Could this result in needing two separate systems – one for personal data and another for the rest?
- Making something opt in / consent does not justify inclusion, if it is completely unnecessary for the purpose (i.e. the registration of a domain name). Under Data Minimization things like social media details - regardless if they 'could be used' – still should not even be an option
- If you have a form with optional fields, there must be knowledgeable consent. Why would you create two separate systems to accommodate this?
- We’re using purpose in a lot of different ways. The purpose under EU DP laws isn’t the same as the “hallway” definition of purpose – which may be uses of data
- Might you need to know the type of entity for each data element? For example, Registrant Type identifies the type of entity for all of the Registrant data elements. But perhaps you need something more granular than on the block level?
- Is there a requirement for the ability to signify something on a per-element basis, such as data subject type, interest of data subject, purpose for collection
- Suggestion to add a Remarks column to the table to allow for indication of other information about the data element
- Some remarks might be information determined at time of collection, while other remarks might be information determined by policy like purpose served
- Telephone numbers may not be the most desirable way to be contacted in the future – there might be a need for alternative contact methods (twitter handles, etc.) instead of telephone #.
- Note: In the EWG Report Annex D list of elements, Registrant SMS, IM, Social Media – those were examples of this, possibly not comprehensive.
- It might be possible to have multiple values for each data element to allow for a list of alternative methods of contact.
- Stephanie Perrin: Use cases developed by EWG were more of a wish list and possibly outside the bounds of data protection law. Endorsed this approach because it might help us weed out those uses that were out of bounds. Need to identify purpose for each data element.
- Data elements such as SMS may introduce new risks – for example, people may not want to be contacted by SMS, or SMS may be used in two-factor authentication so could be used
- Need to make distinction between fields that are mandatory and fields that specific TLD operators may wish to offer (e.g., trademarks)
- Another value in “third column” is public/private – whether or not the data subject considers the data to be public or private
- Anything ICANN supervises puts them in position of data controller. If ICANN requires a data element in a contractual agreement, then ICANN is responsible and accountable for that data element.
- However, Registrars and Registries have their own contracts with each other, not controlled by ICANN. Any TLD-specific requirements in those contracts are not set by ICANN.
- We are talking about minimum data elements from ICANN's perspective, are we not? Anything outside ICANN's remit is not within ICANN's remit.
- Registrant postal address and geographic location may no be longer needed. This data isn’t needed when I create a Facebook account or many other kinds of service accounts, so why is it needed for the DNS?
- Given the existence of IDN gTLDs, we might need the Language of the Domain Name as the Data Element? Will this list ultimately go through translation and transliteration processes?
- Yes. Both the T/T recommendations and the IRD WG final report are included in the background documents for this PDP found here: https://community.icann.org/x/R4xlAw
- Regarding the list and assessment of personal data versus not personal data, what does accountability mean? What are the particular respects of accountability? In the GDPR, there are at least seven or eight rights for the data subject for which the data controller can be held accountable for, but in every other international data protection legislation there are at least four: The right to access data, right of deletion, right of rectification, and sometimes right of blocking as well. So for all of these rights, the data controller must put in place a mechanism to ensure this right. Data protection authorities would look at how directly or how easily they can exercise those rights.
- Registrant Name may not be needed for natural persons, particularly if there is something like Registrant Contact ID that allows identification of that Registrant. So long as the Registrar has the name of the Registrant, collected at point of sale, possibly the need for access to Registrant Name can be served outside the RDS.
- As we heard in the Cross Community Working Group, you need to know the person or the contact -- whether it' a company or otherwise – a way to access that. So completely disagree: do not think contact ID is at all the same as the name of the person. For accountability purposes, you absolutely must have the name of the Registrant.
- Not suggesting that the data is not collected at the point of sale, the point of activation, registration or what have you. If you could actually collapse that entire registrant block of data elements down to a registrant ID, it can contain whether it’s validated or not, the last update, etc.
- In the ccTLD space, there are several registries (e.g., .fr) where the name can just completely disappear. It’s still accessible via other means but it isn’t necessarily appearing in [WHOIS]. We do have the information if somebody comes to us with through proper channels.
- We might be conflating data collected for RDS and data collected by the Registrar so they can do their business. Two different data sets, overlapping.
- Mixed views on this data element (Registrant Name) and associated block.
- Registrars did not have any need for contact ID until the 2013 RAA required it; it was not needed for their business purposes.
- Registrants should be educated about taking responsibility for what data they disclose. No one is being tricked into disclosing their PII.
- Question: How many of you are comfortable with the five data elements listed:
Registrant Name/Org, Type, Contact ID, Contact Validation Status, Last Updated Timestamp - Show of hands demonstrated more support than opposition, but not all weighed in
Action: Staff to distribute an expanded version of the data elements table reviewed during this F2F session (Data Elements Handout.pdf) to include a description of each new data element and further information about each element, extracted from the EWG Final Report, for WG member review in preparation for participating in this week’s poll and our next meeting.
Action: Leadership team to draft poll to gather WG member rationale for or against each data element, to inform on-list discussion and continued deliberation in our next meeting. Staff to implement this poll on data elements as directed by the leadership team. All WG members are encouraged to respond to the poll no later than 15 July COB.
6. Confirm action items, proposed agreements, and next meeting date
UPDATED: The next RDS PDP WG meeting has been rescheduled to 18 July at 16.00 UTC.
This date change was made after the F2F session concluded. Upon reviewing the action items listed below, WG leadership concluded that time allocated for the 11 July meeting would be better spent by each WG member individually reviewing the listed data elements and then providing rationale for or against each data element in response to this week’s longer-than-usual poll. Rationale gathered through this poll will then be used to inform data element deliberation on-list and during the 18 July meeting.
Action: Staff to document cross-community feedback for WG consideration during second pass on fundamental charter questions. For links to session recordings, scribe feed, and notes from the cross-community session, visit: https://community.icann.org/x/ygffAw
Action: Staff to distribute an expanded version of the data elements table reviewed during this F2F session (Data Elements Handout.pdf) to include a description of each new data element and further information about each element, extracted from the EWG Final Report, for WG member review in preparation for participating in this week’s poll and our next meeting.
Action: Leadership team to draft poll to gather WG member rationale for or against each data element, to inform on-list discussion and continued deliberation in our next meeting. Staff to implement this poll on data elements as directed by the leadership team. All WG members are encouraged to respond to the poll no later than 15 July COB.
Meeting Materials
28 June Call Poll (closes at COB Saturday 15 July)