[Gnso-epdp-team] Latest version of Automated Use Cases document

Tue Feb 4 11:13:16 UTC 2020

Mark,

Thanks for completing this. Noting we did discuss this, alas I must note
that this new document does not reflect my impression of the discussion
that we had:

   1. I recall we discussed that the decision for disclosure would be at
   the option of the controller, who on the basis of the data and risk profile
   before them, can initiate the automated response. This assumption was
   acceptable to me. This resultant document does not even contemplate this. I
   particularly note an expanded creep back into 'required' automated
   disclosure. This is not agreed, was not discussed, and should not be
   included in our interim report.
   2. The assumptions in this document assumes that the Gateway /
   authorization body will have the data to make the decision - although you
   note in VII that that singular assumption may modify the relationships, for
   the record this does actually completely depart from the swimlane model as
   presented. The model represented now effectively tries to avoid the central
   body actually processing of registration data (gateway/ Auth). Your
   assumptions are forcing that body into a decision making controllership
   role (automated is still a decision). Adhering to the swimlane as
   presented, the decision and the automation will still occur at the CP at
   their discretion - and imposition is not envisaged. (allowing a factual
   apportionment of a 'processor' role under a JCA).
   3. The additional mix of the 'recommendation' concept into nudging
   towards automation is new. It is also unhelpful. Calling a spade a spade, a
   "recommendation and feedback" imposition on the decision maker is flipping
   the actual requirement here. The controller may tell the central body that
   certain decisions can be automated (as we discussed)- not vice versa
   (notwithstanding that this is only possible where the central body has the
   data, which is again not currently envisaged in the swimlane model). To
   confirm the central body, acting in the factual guise of a processor, must
   act solely on the instructions of the controller in 'permitted' instances.
   To reverse this assumption i.e. to have the processor continually recommend
   chipping away at the clear and sole instructions of the controller is
   anathema to the spirit of article 28 and will draw the ire of privacy by
   default; disclosures on a sliding scale of automated 'recommendations',
   based on observed and solely empirical data from decisions; (assuming we
   are not commissioning an AI who can understand the nuance of a balancing
   test), then observed repetition of decisions does not a rule make; errors
   in judgment may occur, and repetition of that error does not make it less
   of an error.
   4. *"A requestor can selectively assert whether data specific disclosed
   in response to a particular request will be used in a way that has legal or
   similarly significant effects on the data subjects."* - this is a
   controller's job not the requester. Plus, objectively speaking, we cannot
   build an inherent bias in the requestor's request. All requesters (one
   assumes) have a subjective goal to achieve; surely they are not going to
   play up the impact, where they know that the greater impact, the more
   important such an impact plays in the balance. I understand the suggestion
   is well meaning, and a controller will certainly take any such an assertion
   into account - but let's be clear that the assertion of the requester is a
   single factor of the consideration, and should never be determinative.

As Volker noted, and as I discussed with you, most of these instances still
require human interaction, which is within the sole purview of the
controller. I agreed that some of the examples noted may be automated (e.g.
in jurisdiction request of a LEA or equivalent - i.e. where the controller
will process under 6(1)c or equivalent. I also agree that there are
instances where the controller wishes to voluntarily assume risk, and takes
measures to automate themselves (adhering to the swimlane) - that does not
mean that these 'use cases' support automation for all, merely that they
support a concept of 'automation at risk' to the controller. Such a
heightened risk profile cannot be imposed on other controllers not so
inclined or advised.

I also note that Brian King's separate missives seem to suggest that this
is to be included in the interim report. Again this was not the
understanding from our conversations. We had discussed that this was
reference material for the benefit of discussion, and not part of our
report. I do not support its inclusion in the report at this point; it has
not been properly discussed and does not align with the actual
understanding of the model as described. I also doubt that this will garner
such required discussion in the few days we have prior to publication.

Warm regards,

Alan

[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
------------------------------
Suite 1-31,
Block D, Iveagh Court
Harcourt Road
Dublin 2, County Dublin
Ireland

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
<https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.

On Tue, Feb 4, 2020 at 3:39 AM Mark Svancarek (CELA) via Gnso-epdp-team <
gnso-epdp-team at icann.org> wrote:

> Thanks you all for your patience waiting for this, and thanks to everyone
> who sent me feedback both privately and on-list.  Hopefully I have
> incorporated all the feedback*
>
>
>
> I’ve consolidated various use cases and assumptions.  Apologies in advance
> because this resulted in renumbering from the previous version.
>
>
>
> /marksv
>
>
>
> *except for the Trademark use case, where the feedback was inconsistent.
> We’ll have fun with that one.
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200204/da5c1e11/attachment.html>