Hello, my name is Berry Cobb and I will be monitoring this chat room. When submitting a question or comment that you want me to read out loud, please start with a <QUESTION> and end with a <QUESTION>, or <COMMENT> <COMMENT>. I will read them aloud during the time set by the Chair or Moderator of this session. Text outside these quotes will be considered part of “chat” and will not be read out loud. If you wish to speak during this session, raise your hand in Zoom or queue at the aisle microphone as directed.

Taking part via audio: If you are remote, please wait until you are called upon and unmute your Zoom microphone. For those of you in the main room, please raise your hand in Zoom, and when called upon unmute your table mic. In the secondary room, please raise your hand in Zoom, and go to the standalone mic when called upon.

Please note that chat sessions are being archived and are governed by the ICANN Expected Standards of Behavior. http://www.icann.org/en/news/in-focus/accountability/expected-standards.

Hi all

Hello Goran and hi all

Hi All

Hello all

Hi Max!

I like WHOIS Disclosure System as a name. More accurate and less "sad" sounding

We have a new theory, to call things for what they are…

**Reminder, if you are in the room, pleases turn off your computer speakers to avoid feedback.

how about calling it the Whois Disclosure REQUEST sytem, then? ;-)

RDAP disclose system ? As whois no longer exists ?

We thought about that but from a user perspective, WHOIS is much more well known. Including in some legal texts.

Can any registry create their own WHOIS system in addition to the ICANN guidelines

This seems to lack the "unform" way a request should be processed.

Of course but the difference is that if this a policy accepted, it becomes mandatory for the CPH.

The data in [4] is the requestor's personal data? (It must be, at this point, right?)

Or maybe I misunderstood your question, it is the contracted parties who has all data, ICANN does not have the data.

Sarah, that is the assumption yes

Thank you Goran

what is the reason to store PII data in the system?

Maxim wouldn't it be necessary to identify who the requestor is?

the "encrypted PII" is the PII of the requestor?

Very glad to hear about the reports.

I imagined the Rars would get support in their handeling the "disclore". As in a set of forms they would run through.

We will not store that data, we will delete in the end process

Is there more information on icann’s website about current uses of Name Services portal?

@Sarah, if it is the requestor’s PII, or the avoidance of confusion it should be on the picture

Salesforce equals expensive unfortunately

Salesforce is extremely slow in CZDS

Jan, if you wonder why the data goes from the CP to the requester is due to data minimization from GDPR.

Maxim I think that was [4] in the previous slide?

the CZDS is few times slower than the previous system of CZDS

Are ICANN's Salesforce account fees usage sensitive?

Registries and Registrars receiving disclosure requests will be granted access to user data in Okta for user ID verification purposes?

It seems very sensible to build all of this on top of technology and internal expertise that ICANN altready has.

agreed Paul

My question has been answered by the current slide…

The contracted party needs to know who the requester is, it is part of the balancing test

Agreed. Good to build on existing work products.

@all panelists - Please be sure to change your chat drop down to Everyone, thank you!

@Goran: Agree, so trying to understand how that'd work in this scenario.

Question: @Ashwin, could you explain further the reason for the encrypted PII data please. If the disclosure is by the CP to the requestor then what is the purpose of this system having the PII data, what is it to be used for?

Hello, my name is Berry Cobb and I will be monitoring this chat room. When submitting a question or comment that you want me to read out loud, please start with a <QUESTION> and end with a <QUESTION>, or <COMMENT> <COMMENT>. I will read them aloud during the time set by the Chair or Moderator of this session. Text outside these quotes will be considered part of “chat” and will not be read out loud. If you wish to speak during this session, raise your hand in Zoom or queue at the aisle microphone as directed.

Salesforce is extremely slow in CZDS, it is few times worse than the previous czds system

what are the actual steps a CP would have to complete in responding? Are you expecting us to send the response in our own ticketing system and then manually updating the Ticket in the ICANN system?

Susan, as it said on the previously page. The private date will not be stored, it will be deleted.

In hindsight, ICANN could/should have done this in 2018. Still, seems like a good step to start with today, albeit insufficient to resolve EPDP long-term as accreditation, automation, etc. still need to be built out over time.

and speaking about Salesforce, scaling the system to full will not make it faster than the pilot (so it could be another stand alone system with authorization via some existing one)

Are these slides available? I couldn't find it in the meeting agenda link.

@Sarah - we will post these on the agenda wiki page shortly.

Thanks Marika

ejbccctnntghddltlghifdhdelughcghvhnhkvtulbgb

@Brian, hindsight may be 20/20 but the next best time to do this is as soon as practical after today. :-) I expect we will learn a lot through this effort which can inform future work and thinking. I'm so impressed by Ash's presentation - it makes it all seem so straightforward and understandable for us non-coders.

Serena +!

the most important part is a legal work by the hands of the legal advisors of the particular contracted party (it is not going to be automated)

Serena +1

Please note that attendees are also able to raise hands and get in the queue

Good point Thomas, there would need to be some retention period sufficient to review use

+1 Thomas. Why should requestors be anonymous?

Data should not be retained forever, but also it should be kept for the necessary period

it should at least be an option to not be anonymous

trade off on data minimization and accountability, but Thomas has a good point

Note that raising hands and speaking is also possible for those in the secondary room - please raise your hand and you can use the standing mic in the room.

It's all about finding the right balance

+1 to Thomas's comment - I think it will be important to track certain info about the use of this system … will be good to know types of requestors, numbers of requests, and number of types of responses to see how the system is working in terms of facilitating requests, how often it results in disclosure or rejection, if there are any issues in ensuring contracted parties timely respond etc.

anonymous requestors is not going to fly , in many jurisdictions

From a GDPR perspective, we can make my suggestion work with no problem. I am happy to help with specifics.

agree @Maxim re anonymous requestor

No billing here, and then transition to full SSAD with billing, will be a difficult transition, I think

The billing function is not inexpensive

@Milton - please raise your hand in chat.

@Goran, could you not as a minimum ask for consent to retain the data for tracking and reporting purposes. If there is no consent it is deleted as you propose, if there is consent you keep it?

In zoom

got it. When I first logged in there was no hand raise function

@Kurt: +1

I. agree with Thomas that retention for some reasonable period should be consistent witth GDPR

Agree that the intake of disclosure requests should be via a form to help maximize efficiency/effectiveness - I think contracted parties have already done some work in the area of a disclosure request form

To Griffin's point: https://rrsg.org/wp-content/uploads/2020/10/CPH-Minimum-Required-Information-for-a-Whois-Data-Requests.docx.pdf

The Phase 1 policy already defines what data must be provided in a request.

The Phase 1 policy already defines what data must be provided in a request.

A good reminder, thanks. I was more thinking about the actual format being workable.

Nothing is as permanent as a temporary solution :-)

+1

We have things to talk about, that is why we need more time to develop the system

Aka the six weeks

+1 Thomas

there should be an option to donate ‘cost of number of tickets’ - so some party could send it tokens , for example to Interpol

I really don't understand why ICANN should be involved with this. but that ship has sailed. I just have to transmit my skepticism.

I'm also interested in understanding if this is simply a step on our path to a system that fully supports the recommendations in the Phase 1 policy ... or something else.

so we will address access authorization another time?

+1 Alex

If at all possible with proportionate efforts, there should be a charge. Lots of folks will work on requests and the requestor should be seriously considering the need for data and pay a charge - even for the temporary system.

if everything fails - there should be a detailed explanation in many languages - how to request the data directly

didn't we set that policy about costs already? yes temp solution must have a billing mechanism

Credit cards are pretty global

Regardless of billing/no billing etc. I would caution against judging overall demand for a system that provides reasonable access to registration data to legitimate access seekers based on this solution

Including billing in SSAD Light would also provide more realistic stats on user adoption, if seeking missing data is the objective.

what do you mean Maxim?

+1 Amr

+1 Amr.

+1 Amr. We can't consider this a proof of concept unless there is some cost associated with requests

+1 Amr

@Farzaneh, I mean if the party has no positive answer - then the link to the detailed explanation should be offered

in many langauges

that is a bit too excessive for a light system, don't you think?

wouldn't one think that the demand on a free system would be strictly larger than the demand on a system that requires payment?

it could be in English only for the pilot

Two main questions remain : what is needed to submit a request and (from a GDPR point) how do you guarantee the requests are handled equal i.e. what does the balancing test look like

and there are already texts with roles and options to try

also are we charging everyone? including law enforcement? credit cards don't work in some countries but I am comfortable with those countries law enforcement not having access to people's data tbh

We should charge everyone. The idea that Interpol or FBI or national police forces can't afford paying for requests is not credible

thank you Ashwin

@Farzaneh, the local law usually prescribes how to interact with LEAs , and foreign LEAs do not exist from the local perspective (if there are no intergovernmental agreements of cross recognition of LEAs is in place )

One of the issues with using RDAP is that RDAP is an access protocol, but SSAD is a request protocol.

is it possible to use average data (like a continent, type of the requestor (not precise , just a LEA, researcher e.t.c.)?

+1 Steve

A question for Steve DelBianco and BC/IPC: wouldn't the standardization of the interface and the central point of request be a major convenience improvement for requestors?

You have to maintain information of requestor for accountability purposes, Get Bird and Bird to answer that question, if you don't believe me.

Also there is a logical flaw in Steve's argument about the volume of requests: he seems to be saying that stronger guarantees of disclosure will increase the amount of requests, but no ICANN system can guarantee disclosure

Speaking Personally: @Milton - there are some of us within the IPC that think it will be a significant convenience over tracking down individual requests processes across all the various registrar websites. And, again personally, I think some data is better than no data as to how many requests are being made, by whom, to whom, on what basis, and how it was handled. .

+1 Steve

i hope the feedback loop is as low maintenance as possible. Ideally the requests would flow into our ticketing system, so the response to the requestor can flow from there, and include a link for each response type. No logging into the bloody Okta platform, please!

+1 Goran - a great discussion and your team is very impressive.

Hi -- yes I am back.

Thanks Volker for your kind words..but the answer is really a policy question…how should the reporting look like…?

We seem to be talking about a technical proof of concept but we seem to be focusing on the proof of use. technical solution is about seeing if the process can be streamlined and easier to use by CPH. It is not a proof of concept of use for now - is how I read it.

current proposal seems like a step in the right direction.

@Milton -- BC believes that a centralized SSAD operated by ICANN would provide a faster and more fair evaluation of the GDPR balance text. The BC voted against the SSAD reccomendation because it did not centralize decision making. So we understand that no system can guarantee disclosure, we seek a centralized system where appropriate disclosure happens reliably and quickly enough to mitigate fraud and security threats.

@Sebastien lowering my hand. That was my exact question.

understand, Steve. But that ship has sailed, no?

@John Thank you

+1 Milton

@Sebastian - lowered my hand

@Desiree thank you

Steve, that was the Strawberry project, we never really got an answer to it.

The 6 weeks seems like a good investment to take concrete steps to begin to solve a problem that has plagued the community for years. I know there are many that are anxious for the next round to start, and I am sympathetic. But, this WHOIS Disclosure System can be a meaningful step to making the ecosystem much safer.

wow, interesting idea, Thomas

@Steve: as was stated repeatedly during EDPD Phase 2, centralized decision making was a non-starter for contracted parties. They would still retain liability under GDPR for any fines, and thus need to retain the ability to make decisions. It's time to accept that fact and move on.

centralization was a non-starter for ICANN, too I believe.

Sorry have to leave room

+1 Owen and Milton. There is the controllership issue.

We are not likely to have time to discuss here, but the as-agreed NIS2 text will create new disclosure and accuracy obligations for registrars and registries. (I circulated the text today). How will NIS2 affect this project, in terms of measuring scope of disclosure, speed of disclosure, and accuracy of data?

Steve DelB - I'm not sure that it does, I'd be interested in hearing more about what you think NIS2 changes for us

We seem to be designing a row boat....not the ship that the phase 1 final report defined.

@Stephanie do you mean censorship here 🤔, I am just thinking far

@Owen @Milton not going to rehash the arguments here, but ICANN did offer to undertake centralized decisionmaking (strawberry project), and reasonable minds can differ as to whether CPs would have liability for ICANN-decided disclosure under the right model.

so what is the purpose for this system Steve is presenting on? are we going to have plural disclosure systems? and who is gonna run them?

@milton, thinks it’s more accurate to say that ICANN agrees that because contracted parties will he held accountable for GDPR violations (which we think, absent input we sought from EDPB, is. the case) centralized. decision-making might well be inconsistent with GDPR

@Milton, “I think”

@Becky: +1

+1 Becky

this diagram looks the power flow screen on a Prius

I agree completely Steve D!

so how is this system going to complement what ICANN presented?

Support Farzaneh's question, how does this fit in with the current status of the SSAD recommendations?

Are the operators of other data disclosure request platforms also going to be given a space to present their systems?

Agreed, Farzi and Sarah!

oh finally we mentioned RDAP! calling it WHOIS disclosure might not be in trend

+1 Sarah

the question I have on Steve's technology is how much. does he see decision-making being automated

Agree Farzi- I don't like that “whois" is making a comeback. I thought it was killed/replaced by “registration data" and “RDAP”

I guess I don't understand why a requestor would want to make the request in two places. If ICANN has a system up and running quickly, it seems like most folks would be happy to use that first-to-market option, especially if it is going to produce reports on usage which will be helpful to the entire community.

+1 Owen ... but it seems "whois" is what people know

at least replaced with RDDS (RDAP, whois for some time)

if it is automated, who is the controller?

could there be a cheaper /free option for the requestors - to check who is the party for the potential request?

I don't see how this system complements ICANN’s. also there are other operators so what are we gonna do with them? are they gonna present?

without using the system

@ Benjamin, when I use the word controller I am referring to the accountable party under data protection law, who is answerable not only for the disclosure of PI that we anticipate, but for any unanticipated data breaches, security breaches, bias in any automation tools, etc

Thank you all! Great discussion!

thanks all