[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 21 February

Wed Feb 21 20:02:07 UTC 2018

Dear All, 

Below, please find notes from today’s RDS PDP WG meeting.

To recap Action Items from today’s call: https://community.icann.org/display/gTLDRDS/2018-02-21+Next+Gen+RDS+PDP+Working+Group

Action: Leadership Team to regroup, consider input from today’s meeting and recommend next steps.  

Action: ICANN Staff to send doodle poll for time on Friday for Leadership Team to meet.              

Kind regards,

Caitlin

Action Items and Notes from RDS PDP WG Call – 21 February 2018

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.

1. Roll Call/SOI Updates

Wiki page: https://community.icann.org/x/nAu8B
Call Handout: https://community.icann.org/display/gTLDRDS/2018-02-21+Next+Gen+RDS+PDP+Working+Group?preview=/79432606/79435973/Handout-21February-RDSWGCall-v2.pdf

2. Discussion of suggestions on mailing list

WG members have suggested seeking additional legal advice
The Leadership team has discussed pros/cons of seeking legal analysis at this time, noting that a substantial amount of legal analysis is already available to the WG, and concluded that now is not the appropriate time. The leadership team suggests potentially seeking further analysis when the WG has developed a set of recommendations that can be usefully analyzed for compliance (or lack thereof) with applicable laws.
Note: there is no budget currently allocated for further legal analysis.
As such, at this time, the Leadership Team does not wish to pursue this route.

3. Complete deliberation on DN Certification

a. Resolution of this week's poll results on DN Certification as a purpose

Poll results: Poll-from-13February-Call.pdf
Refer to slide 3 of Call Handout (https://community.icann.org/display/gTLDRDS/2018-02-21+Next+Gen+RDS+PDP+Working+Group?preview=/79432606/79435973/Handout-21February-RDSWGCall-v2.pdf)
For Question 2, 72% of those who participated supported DN Cert as a purpose for PROCESSING
Roughly 62% either agreed or could live with DN Cert as an opt-in purpose for COLLECTION
Opposition centered around three concerns: (1) can ICANN specify purposes that are in the legitimate interest of third parties (in this case, CAs), (2) does processing imply data collection, and (3) the need for greater clarity around collection of data for this purpose.
With that in mind, WG is asked to now look at the data elements needed for DN Certification, and discuss whether these data elements are collected for another legitimate purpose already identified or a legitimate purpose not yet discussed. If certain data elements are not collected for another purpose the WG has already agreed on, note will be taken so that the WG can revisit those specific data elements after the WG has gone through all of the purposes for which data is collected.  

b. Deliberate on data needs associated with DN Certification

Refer to Slide 5 of Call Handout, which includes a table identifying the drafting team's proposed registration data elements for DN Cert (See: column 3). 
Note: Slide 5 data elements are footnoted with existing WG agreements
Already-agreed purposes for collection: Technical Issue Resolution & DN Management - are compatible with DN Certification. 

QUESTION: what, if any data elements would be appropriate for access for DN Cert?

Comments made by WG members on the call:
What assurance does DN Certifier have that this information has any relation to DN holder? In other words, is there any guarantee this is relevant or accurate information?
The answer largely depends on the type of certificate being authenticated/verified. In the case of highly-authenticated certificates, it is the job of the CA to ensure that the information in the WHOIS matches info from third party databases and that the same org/individual has control of the domain. 
Publishing this info in the WHOIS provides no authentication whether this info is relevant or accurate and serves as merely a hint, and leaves it to CA to take it from there. Note that the topic of accuracy will need to be considered by the WG at a later stage per its charter.
In the case of registrant email, that is one of the ways used to confirm the registrant controls the domain. All information on certificates is verified by means outside the RDS.
The current arrangements do not allow a CA to use RDS as a reliable pass-through mechanism, but the WG could consider making this a feature available through the RDS.  What is missing here: potential to enable the RDS to be valuable for these ancillary purposes.
NOTE: Kirk Hall, the Chair of the CA/Browser Forum has joined this WG, but could attend today’s call. 

QUESTION: We have to first decide whether DN Cert is a legitimate purpose for providing some sort of access, and if so, which elements?

Comments made by WG members on call
If we collect info and make it available, what consent is required by the individual providing that information as well as what guarantees are in place? 
In order for RDS to be truly useful for DN Cert, system will need to be adjusted accordingly, if the WG agrees to support DN Cert as a purpose. If we recommend some access, it would only be meaningful, if we offer assurances. If we offer assurances, which data elements are relevant?
When you try to identify who is doing something with you on the internet and you need strong evidence about who that person is, it is not a binary operation. If you look up an account and an email matches, it's fine. CAs do not work in that way. One thing they do - they get you to put something in a zone file and then they look it up. The RDS is about legitimate control over the records that should be in the record and what is in the DNS.
Current distinction between admin/tech contact and registrant email may have no value. Best to start with a clean slate. What info does the account holder want to supply, what level of assurance is given to that information?
We should define what the elements mean first - then it will be simpler to decide level of access and uses.
Maybe the difficulty is that we're going at this with the existing structure of what is currently in the WHOIS rather than thinking of what kinds of things we need?

Action: Leadership Team to regroup, consider input from today’s meeting and recommend next steps.  

Action: ICANN Staff to send doodle poll for time on Friday for Leadership Team to meet.

DEFERRED

4. Start deliberation on DN Purchase/Sale as a purpose and associated data needs  

5. Confirm agreements for polling & next steps

Action: Leadership Team to regroup, consider input from today’s meeting and recommend next steps.  

Action: ICANN Staff to send doodle poll for time on Friday for Leadership Team to meet.

6. Confirm next meeting: Tuesday 27 February at 17:00 UTC 

Meeting Materials: https://community.icann.org/display/gTLDRDS/2018-02-21+Next+Gen+RDS+PDP+Working+Group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180221/ceb118a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180221/ceb118a5/smime-0001.p7s>