@terri and Caitlin, Chris D. has informed me that he will be a few minutes late in joining this call

Thank you Becky and noted

Merger?! Assuming that was GoDaddy's idea ;-)

Apologies for joining late, GNSO council meeting ran a bit over.

Reminder to select all panelist and attendees for chat option.

Ack

Agree, Marc. And agree query policy is good place to address this (not SLAs)

I would at -EXTREMELY- hypothetical.

thx.

Identity Validation Procedures

(in lieu of "authentication" in the third line)

Margie raises some important concerns.

Isn't similar to presumption of innocense?

To clarify, this is not accreditation, just an identity provider

This isn't for bad guy requestors

That's a different section

Suspension of accreditation = suspension of access?

Yes b/c access requires accreditation

if an identity provider is WIPO as an example — that means that all underneath it - all IP holders would be suspended during the appeal

+1 Margie. We're sympathetic to the concerns raised by James. This is the wrong section though.

+1 Alan G

This isn’t all that dissimilar to when an SSL authority is revoked.

This does require further thought, I agree with Alan but if there is abuse you need to stop it right away. The controller will be liable if it provides access with knowledge of abuse….

So you need secondary procedures for the instances when an identity provider has a credibility issue

The authorization policy for Identity providers SHOULD include graduated penalties. In other words, not every violation of the policy will result in De-authorization; however, De-authorization may occur if it has been determined that the Identity Provider has materially breached the conditions of its contract and failed to cure based on: a) a third-party complaint received

You're fading out Marc.

Yes you are wobbling Marc

+1 Marc

Clearer now Marc thanks

This does require further thought, I agree with Alan but if there is abuse you need to stop it right away. The controller will be liable if it provides access with knowledge of abuse….
So you need secondary procedures for the instances when an identity provider has a credibility issue

@AlanW: +1

another excerpt from that sectionDepending upon the nature and circumstances leading to the de-authorization of an Identity Provider, some or all of its outstanding credentials may be revoked or transitioned to a different Identity Provider

Thanks AlanW for remembering this is about the data subject’s rights

The rights of the data subject cannot be waived until the identity provider issue is resolved.

Agree Alan, but it is also to protect the integrity (and legality) of the SSAD itself.

Agreed James , I think the two are hand in hand.

+1 James (and Marc from before)

Since we now recall the graduated responses, let's move on

Don’t forget the liability issue James.

@Stephanie: +1. Doesn’t the liability issue become even more serious, if breaches by the identity provider are identified?

One can imagine that an SSAD that is unable to enforce its own controls would be (1) sued to death by data subjects or (2) ruled as not fit for purpose/incompetent by some DPA somewhere.

@James: +1

Absolutely, that was what I was aiming at in response to Alan G. These accreditation instruments are to streamline the process and relieve burden on data controllers, but if they have been shown to be responsible for data breach (i.e. inappropriate release) then you have to stop the streamlined approach and find a way to reintroduce the rigour in the requestor validation process. I will resist the urge to refer again to the famous Equifax case….

Page 20 in the initial report

Examples of additional information the Accreditation Authority or IdentityProvider MAY require an applicant for accreditation to provide could include:o a business registration number and the name of the authority thatissued this number (if the entity applying for accreditation is a legalperson);o information asserting trademark ownership

better call Saul

lol my thoughts exactly Volker

why do we need this clarification?

I don’t believe we do need it, I think it actually un-clarifies it. Lawyers can act for anyone.

Security researchers may also appoint sole operators, other firms, etc.

Retired cops may be hired by law enforcement authority….I shall not go on.

I need to drop for another call so Sarah Wyld will be taking over for me…thanks

Thanks!

Thanks to Staff for that and for all your hard work on this. Rec 2 was formatted very well, so Rec 1 would benefit from that type of change. And definitely support taking the Definitions out to their own section.

+1 to taking the definitions out to their own section

bye all

@Laureen: +1

+1 Stephanie

Very interesting suggestion

Agree Stephanie. Also raises the potential for due process issues.

Thx for raising these issues re: delegation to 3rd parties and the need to ensure trustworthiness Stephanie.

+1 Stephanie

@Stephanie: There should be a clear reference to a law to entrust the third non-governmental party

@Stephanie thanks for raising those important points

Rec 2 had very clear section headers, we should consider using that for the combined rec

new category: other

30 seconds left

sorry, accept what?

Sorry - no I do have issue with the 2nd bullet point.

+1 Laureen

But again … let’s hear the B&B response

Re the second bullet on the left-side page, we need to be careful to balance standardization of request format (e.g. checkboxes, dropdowns) against the ability of requestors to simply select what they think will be most expedient rather than what is true.

So do I. Is this the bullet about pre-populated dropdown menus?

yup

Re Item 1. remaining, I do not think we need a list of purposes. We already have a Phase 1 rec. on purposes, and we shouldn't restrict requestors in this way. It should be a free-form text box.

@Sarah: +1, and no need to provide a cheat-sheet of permissible purposes either.

well said Amr. Plus, although it's a potentially permissible purpose it still depends on the specific case at hand.

Just note that Phase 1 purposes were purposes for the collection. We're talking about purposes for third parties here. Important distinction.

They were purposes for processing data

though, icann purposes, not third-party, that's a good point

Agree with Amr on cheat sheet.

So, Phase 1 purposes aside, the point still stands that requestors will be able to identify why they need the data and clearly indicate their purpose without a menu of options

I just think we can spend our time on other more essential topics rather than a non-exhaustive list of purposes.

@MarkSV: The whole reason this system exists is because Registrants are criminals, even though they agree to registrar T&Cs, and a registration agreement.

Experience provides ample proof of that Mark SV. We are trying to create a system that assures trust.

The more a group of requestors thinks they are entitled to this information anyway (having, for instance, had free and unencumbered access to it for 20 years) the more they will treat the process as a cheat sheet.

@Stephanie - I haven’t seen studies that support the type of abuse you are worried about;

Anyone who has dealt with requestors has encountered misrepresentation. We need to figure out how to defend against that, even if it slows things down

I would suggest a through read of some of the DPAs’ annual reports

+1 Alan

thorough

+1 stephanie

+1 AlanG

Brian - could you remind me what B&B memo that was you referred to?

Yep, the one on automation

Thanks

The fact that ICANN has not studied the issue of requestor abuse is in my view not enhancing its credibility in these matters.

We have umpteen research reports on registrant abuse.

Pre-defined terms that are well defined gives more specificity, not less.

Pre-defined terms that are well defined gives more specificity, not less.

We are building in a lot of logging & audits to address abuse so the new system is already building in data that ICANN can look at to see the level of abuse by requestors

As I said earlier, I don't think spending time on a necessarily incomplete list of purposes is the best use of our limite dtime here

@AlanW: +1

+1 Alan W

+1000 Alan W

Can we drop the SLA so lol?

The benefit is that it requires the requestor to explain their purpose in their words.

How does not having the checkbox make your life difficult, MarkSV?!

Grand, ignore our valid concerns should oyou believe our experience of applying the actual law is somehow inconvenient to your requests

Never in the history of checkboxes has a checkbox checked this many boxes.

we should not put 'as applciable'

To be clear, I’m not saying that anybody on this call is trying to game the SSAD. Everybody here will presumably be perfectly capable of submitting a solid disclosure request, wether pre-populated lists exist, or not.

I like options

@Sarah: +1

Is the sla for the incomplete request response not already 'without undue delay'?

Agree with the expectation that the request cannot be submitted if it is incomplete

Thanks for clarifying the requirements Sarah!

as Janis says, I think it's not a problem to solve

SLA for an *amended* request is something we should discuss though yes

In that case, the requestor would be subject to the SLA, not the CGM

+1 Marc

+1 Brian

I have a hard stop in a few min. Thx.

Thanks all. Bye.

Thanks, all

Thanks all

Thanka