Whois/privacy and the SSAD

[Tomslin Samme-Nlar]

Thanks for sharing Milton.

Procedurally, personally I think there are too many unknowns to risk
starting working on a supplemental recommendation before a board decision
and report to the GNSO council. We need at least the Operational Design
Assessment (ODA) expected to be published in February for us to get a bit
more details.

On the substance, my understanding is that there are two aspects to the
system. Validating the requestors (accreditation) and validating the
requests for correctness (triage). You say you're "afraid that
accreditation will confer some kind of de facto expectation or right to
disclosure, and to mass, automated requests". As I understand it, the
current policy doesn't confer this expectation. Is your fear therefore that
if the EPDP group is consulted for either a supplemental recommendation or
modification of the recommendation, text might be added which confers such
expectations?
Usually, validation of the requestor is done before or as part of the
triage process of a request. How do you envision the whole process working
practically without the validation of the requestors bit?

Tomslin
@Twitter: https://twitter.com/tomsleen
@LinkedIn: https://www.linkedin.com/in/tomslin/


On Wed, 5 Jan 2022 at 07:04, Mueller, Milton L <milton at gatech.edu> wrote:

> Greetings all and happy new year.
> As one of your representatives on the EPDP dealing with Whois and privacy,
> I want to inform you of the latest development.
>
> You will remember that a lot of sensitive domain name registration data is
> now redacted (hidden), because ICANN had to come into compliance with GDPR.
> The SSAD (Standardized System of Access and Disclosure) was an elaborate
> mechanism developed by the EPDP to allow people who want to see the hidden
> data to request its disclosure. The proposed SSAD had an elaborate
> mechanism for accrediting users of the system, including a process for each
> national government to accredit its own law enforcement and government
> agencies.
>
> ICANN Org has done a study of the costs of the proposed SSAD and estimates
> that it will be very expensive and will take a long time to implement. The
> ICANN board has indicated that it may not approve the SSAD recommendation
> because of these problems.
>
> So now we are faced with a question about what to do next.
>
> There are basically two options being presented to us:
>
>    1. Let the ICANN Board formally refuse to adopt the recommendation,
>    tell us what's wrong with it, and then let the Council and the EPDP adopt a
>    supplemental recommendation that fixes the problems
>    2. Re-convene the EPDP and work out its own modification of the
>    recommendation.
>
> I've attached a more detailed analysis of the options that the ICANN staff
> circulated today. I have my own opinion about this - I think the SSAD does
> need to be simplified and agree with the staff's concerns about its
> complexity and cost. But I am not sure what is the best way procedurally to
> fix this problem. Hope we can discuss this as a SG and reach a unified
> position.
>
> Cheers,
>
> Dr Milton L Mueller, Professor
>
> School of Public Policy
>
> Georgia Institute of Technology
>
> Internet Governance Project <https://internetgovernance.org>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20220111/f0a409d6/attachment.htm>