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

35:06
Thank you Becky and noted

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

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

38:12
Reminder to select all panelist and attendees for chat option.

38:50
Ack

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

56:19
I would at -EXTREMELY- hypothetical.

56:21
thx.

58:41
Identity Validation Procedures

59:00
(in lieu of "authentication" in the third line)

01:01:04
Margie raises some important concerns.

01:02:02
Isn't similar to presumption of innocense?

01:02:07
To clarify, this is not accreditation, just an identity provider

01:02:35
This isn't for bad guy requestors

01:02:44
That's a different section

01:03:16
Suspension of accreditation = suspension of access?

01:03:30
Yes b/c access requires accreditation

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

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

01:04:52
+1 Alan G

01:05:03
This isn’t all that dissimilar to when an SSL authority is revoked.

01:05:55
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….

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

01:07:12
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

01:07:15
You're fading out Marc.

01:07:36
Yes you are wobbling Marc

01:08:04
+1 Marc

01:08:13
Clearer now Marc thanks

01:09:55
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

01:10:04
@AlanW: +1

01:10:17
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

01:10:29
Thanks AlanW for remembering this is about the data subject’s rights

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

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

01:11:00
Agreed James , I think the two are hand in hand.

01:11:03
+1 James (and Marc from before)

01:11:04
Since we now recall the graduated responses, let's move on

01:11:09
Don’t forget the liability issue James.

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

01:11:41
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.

01:11:55
@James: +1

01:13:49
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….

01:14:23
Page 20 in the initial report

01:16:10
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

01:18:31
better call Saul

01:18:46
lol my thoughts exactly Volker

01:19:19
why do we need this clarification?

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

01:20:43
Security researchers may also appoint sole operators, other firms, etc.

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

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

01:23:44
Thanks!

01:26:01
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.

01:27:37
+1 to taking the definitions out to their own section

01:29:03
bye all

01:34:40
@Laureen: +1

01:39:36
+1 Stephanie

01:39:44
Very interesting suggestion

01:40:36
Agree Stephanie. Also raises the potential for due process issues.

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

01:41:13
+1 Stephanie

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

01:41:49
@Stephanie thanks for raising those important points

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

01:48:28
new category: other

01:52:44
30 seconds left

01:53:45
sorry, accept what?

01:55:00
Sorry - no I do have issue with the 2nd bullet point.

01:55:11
+1 Laureen

01:55:15
But again … let’s hear the B&B response

01:55:15
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.

01:55:24
So do I. Is this the bullet about pre-populated dropdown menus?

01:55:30
yup

01:55:51
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.

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

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

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

01:58:15
They were purposes for processing data

01:58:28
though, icann purposes, not third-party, that's a good point

01:58:41
Agree with Amr on cheat sheet.

01:59:04
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

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

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

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

02:01:42
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.

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

02:02:37
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

02:03:10
I would suggest a through read of some of the DPAs’ annual reports

02:03:14
+1 Alan

02:03:18
thorough

02:03:26
+1 stephanie

02:03:31
+1 AlanG

02:03:42
Brian - could you remind me what B&B memo that was you referred to?

02:03:51
Yep, the one on automation

02:04:02
Thanks

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

02:04:32
We have umpteen research reports on registrant abuse.

02:04:44
Pre-defined terms that are well defined gives more specificity, not less.

02:05:07
Pre-defined terms that are well defined gives more specificity, not less.

02:05:48
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

02:05:52
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

02:07:14
@AlanW: +1

02:07:27
+1 Alan W

02:07:40
+1000 Alan W

02:08:53
Can we drop the SLA so lol?

02:09:08
The benefit is that it requires the requestor to explain their purpose in their words.

02:09:46
How does not having the checkbox make your life difficult, MarkSV?!

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

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

02:11:16
we should not put 'as applciable'

02:11:25
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.

02:12:01
I like options

02:13:18
@Sarah: +1

02:15:24
Is the sla for the incomplete request response not already 'without undue delay'?

02:15:52
Agree with the expectation that the request cannot be submitted if it is incomplete

02:16:02
Thanks for clarifying the requirements Sarah!

02:16:04
as Janis says, I think it's not a problem to solve

02:16:57
SLA for an *amended* request is something we should discuss though yes

02:17:16
In that case, the requestor would be subject to the SLA, not the CGM

02:19:34
+1 Marc

02:20:55
+1 Brian

02:23:02
I have a hard stop in a few min. Thx.

02:28:41
Thanks all. Bye.

02:29:15
Thanks, all

02:29:17
Thanks all

02:29:23
Thanka