+1 Thomas. Face to face would be better for this topic

Hi all…, since this is my first EPDP call of the decade, happy new year.

Fair and accurate point to make Marc, although I do appreciate Thomas’ offer. We do need a detailed analysis in my view, partly because of the perennial missing decisions.

Agree with Marc…if we could agree (at least in principle) on a model ahead of LA, we would still have a TON of work to do to flush out all of the details

Agree with Marc. How much longer are we going to defer this discussion, and how will this affect our ability to consider the model when we ultimately become even tighter on time?

For attendance - who joined by phone number ending in 631?

I'm in

I'm in

@James: +1

To meet our 7 Feb deadline we only have 1 week to finalize the Initial Report.

...post F2F that is.

I volunteer too

I volunteer too

me too

me too

Happy to participate as well.

I am afraid the only time slot I have tomorrow is between 15 and 16 UTC tomorrow.

Anyone else has a klicking noise in the line? Amost like a type-writer

I hear it, too

We think it is Janis' line.

Confirmed the crackling is from Janis’s line.

I hope its not Janis banging his head against the wall :-)

at a very very fast rate I shoud say :-)

@Janis: Not banging your head against the wall…, yet? ;-)

Brian is assuming it is a data breach, i thought this alked more about breach of policy

talked

Milton that was my first point. It's not clear what kind of breach this attempts to address.

Nice cave!

you're right about that, Brian!

echo is bouncing off of Alan G line

How would you propose to hold ICANN accountable?

the Greenberg cave

@Alan G: +1, including notification of the affected data subjects/registrants that a breach resulted in data leaks (assuming this is the intent of breach here).

Existing accountability mechanisms are rather clumsy to deal swiftly with data breach issues.

"breach of the accreditation policy"

There’s still an echo.

agree with Alan, precision required

Someone was saying something earlier about discussing “convoluted” topics?

If ICANN is the accreditation authority, we should use the already existing mechanisms to address the noncompliance aspect.

@Stephanie even if it is clumsy this is what we currently have

you've heard of multistakeholderism, James, well, this is multiconvoluteism

@Milton: “convoluted” means “your complicated issue that’s getting in the way of my complicated issue.” :)

exactly.

One important concept to decide here is who gets to decide whether ICANN has breached the policy.

my point is merely that you will find out about the failure of the accreditation process through a much larger investigation of a data breach, potentially. A simple examination of data breach investigations under data protection law would illustrate this, I commend that research to you. ICANN is not the whole world.....

"Da community" gets to decide

Stephanie nailed it there IMHO

right, so also law gets to decide

Apologies, but I’m a little confused. We’re discussing “breaches” in the context of audits. Would data breaches be identified during these audits? I wouldn’t think so. Unless I’m mistaken, why are we discussing data breaches at all right now?

because we can

ok?

@Marc: +1

I think we decided we're not talking about data breaches.

@Brian: Yeah…, I thought so too, but there have still been a few comments about data breaches.

That might have been my fault :-(

That's what happens when we use multi-meaning words like "breach" without appropriate modifiers.

+1 Marc and we need to leave clear guidance for the IRT.

@Brian: Now worries. :-)

+1 Marc, and I could join a small team

Good points @Georgios

+1 Georgios

agree with Marc A re hashing this out in smaller team.

@Janis: Good summary of the issue we need to focus on.

So for my understanding: the paragraph assumes that ICANN is NOT outsourcing any accreditation activities and performs all activities by themselves

Janis’ proposal: If ICANN serves as the accreditation authority, existing accountability mechanisms are expected to address any breaches of the accreditation policy, noting that in such extreme case, the credentials issued during the time of the breach will be reviewed. Modalities of this review should be established in the implementation phase.

@Janis: Agree with your proposal, but would add that access by any SSAD users accredited during the period of the breach need to have their access to SSAD temporarily suspended until the breach is addressed.

proposal seems fine and think Amr’s point makes sense but probably need to build in flexibility to determine if that’s warranted in a specific case

I like Janis' suggestion. My inner lawyer wants to poke at it with a wordsmithing stick, but I think the concept is right where we want to be for this one.

Better: Agree with your proposal, but would add that any SSAD users accredited during the period of the breach need to have their access to SSAD temporarily suspended until the breach is addressed.

The operative question here in my mind is if credentials have been issued incorrectly, who takes the responsibility for ensuring that data released under those credentials is treated properly? the data has to be expunged from the repository or sharing arrangements, the registrants have to be notified, etc.

That is a rather large responsibility folks.

agree stephanie … based on of course on the weight placed on the accreditation in the decision.

in the first place

Agree with Janis. Would prefer "reviewed" to address Amr's point.

If we were to set out to clean the records of (for instance) Domain tools, who might have been vacuuming up and selling data that was released not in compliance with law, who would assume that responsibility? It needs to be in this new policy.

I tried. :)

+1 janis

There needs to be a concept of causality and proportionality between the breach (eg size, how bad) and the consequences.

the accreditation policy could be fine, there could be a rogue employee in the accredited body.

hello all, apologies for joining late

ditto

@Janis: Of course, as part of its compliance function.

Why don’t we hash this out offline?

I understand that people want to separate breach and breach investigation from policy, but under the law breach disclosure and attendant mechanisms are important, I fail to see how we can separate them without examining. Audit rarely finds potential breach in my view….(I do not have stats at hand to back that up, but I am pretty sure they exist in the DP community)

Please note that, at the beginning of our call, we deferred discussion of the CPH proposal to immediately begin working on a Hybrid model because it was too convoluted. We have now spent over an hour discussing how to audit accreditors. Many months from now, when folks ask why we aren’t further in our work, this call transcript should be Exhibit A.

I don’t think my point came across clearly. A breach in policy will likely result in improper disclosure of personal information. All I’m saying is that the audit, once it has identified a breach in policy, should also identify what data was improperly disclosed, as well as all parties affected.

This is important, because GDPR requires notification of data subjects of such situations.

Have to agree with James…feels like this VERY detailed discussion is very in the weeds and feels ill-timed given our lack of ability to agree on a draft model to march forward with

Way back in the mists of time, the NCSG pushed for thorough education of members of this group. I think it would have avoided these lengthy detours, because unfortunately some of us feel duty bound to not allow complex issues to slip by through failure to examine the impact of our words.

Only if accreditation is determinative Amr. Which is in a very small set of possibilities

can I get it in chat please?

and/or identity provider (if applicable)

we should build redundancies into the actual decision. This harks back to earlier thoughts .. accreditation is a complex check of ID and system credential distribution no?

@Alan W: Yup. Isn’t this whole discussion taking place under the assumption that a breach in the accreditation policy has occurred and been identified during an audit?

yes … agreed. But a person (again except in limited LEA etc circs) should not get disclosure because of who they are but, for what reason, legal basis and the balance of the rights in the instance. Probably why this conversation was a tad frustrating as, it is not the most important element ...by faaar!

Yes @Stephanie, while I agree that data breaches don’t usually turn up in an audit, I think that the failure to disclose in accordance with policy is more likely to be spotted in an audit and/or via spot checks.

definitely a factor - but one hopes in all but the most extreme of circumstances, the decision could stand, despite the 'accreditation; issue - but perhaps not...

data breaches may be outed in an audit, but if the controller hasn’t noticed them before hand, it’s difficult for an auditor to do so

Alan W: Good point!!

exactly Becky. I would suggest that we are going to be revoking more credentials as the result of complaint and data breach than through audit.

Sorry to slow things down.

But I am presuming that the audit mechanism we set up through these words has to be robust enough to manage the investigation of data breaches and complaints.

+1 james

i think a footnote might make sense here as Janis offered

loaded with what?

loaded with cheese, bacon, and chives

sour cream on the side

funny …. if unhelpful

The cost of examining the data management practices of potential accredited entities could be substantial. Who covers that? in an ISO quality system, the accredited entity does....

I am talking about onsite audit here, just for added clarity

with a team of experts

This talks about maintaining the system as James is highlighting…

@James that clarity would be helpful

Staff please add me to Brian-Amr tag team drafting language re cost

@James: +1. There are cost-recovery provisions in play for whatever ICANN needs to fund upfront, right?

@Alan G I think that we all agreed on that.

I'm confident that we can get to agreement here

I was addressing a comment from Brian in the doc on this section, where he indicates that several groups object to the sentence as a whole. Did I misunderstand what was being objected to?

Can we get this by COB Wednesday?

@Berry: Are you referring to the task assigned to Brian, Steph, Franck and myself?

Yes, but Janis said for next Thursday, so CoB next Monday?

+1 Volker

@Berry: Yeah…, that sounds more doable. :-)

Agree with Volker.

Does not the language I suggested for the next para cover all of that?

I think Thomas' language does that

Really like Thomas' suggestion. It gives sufficient flexibility.

Thanks, Staff

yep sorry my bad

sorry all have to drop a little early today

Given the number of policy options implicit in the various models, there are various implementation details that may have policy implications, particularly with respect to cost distribution and choice of party who performs various data protection functions. These issues are collected here under Implementation Guidance for consideration.

gotcha… that makes sense. Thanks

The team may wish not to confuse Implementation Guidance as a policy recommendation. If this review is important, should it be a recommendation.

@Berry: Was wondering the same.

+1 Amr

reviewed and changed over time?

May we also agree to consider what Berry suggested in the chat above?

+1 to having SSAD fee structure may need ….. as a recommendation

Just noting that the text I typed above should be in quotes, as the text requested by Janis to introduce implementation guidance. Whether it is called implementation guidance or some other title (e.g. Policy Implications of Implementation choices)

Need to drop. Thanks all.

+1000 Thomas

Also need to leave.

Need to drop too

thanks, all.

We should include them in the report and also work on them more.

i need to drop…thanks all

+1 Thomas I need to drop as well

Doodle has been sent to those who wanted to join small team call tomorrow - please check your emails.

Thanks all. Bye.

bye