[Gnso-epdp-team] [EXTERNAL] Re: Latest version of Automated Use Cases document
Volker Greimann
vgreimann at key-systems.net
Wed Feb 5 10:34:29 UTC 2020
Hi,
I think the disconnect is on the nature of the recommendation. You seem
to favor a strong recommendation with near binding power whereas we see
it as a more or a shopping cart style ("people who liked this also liked
that") recommendation with no binding power or strong indication
whatsoever. A helpful guide, but nothing more.
Best,
Volker
Am 05.02.2020 um 01:49 schrieb Mark Svancarek (CELA) via Gnso-epdp-team:
>
> <resending with ambiguous phrasing corrected>
>
> Hi Alan, my comments are inline below. Perhaps we are closer than you
> think.
>
> Note that the Gateway plays a more authoritative role in this version
> because that’s how I perceived the feedback received over the last few
> days – it seemed there was an expectation that the Gateway would be
> making very strong recommendations for certain use cases and CPs might
> be inclined to automatically accept them, to the extent that the
> Gateway could be considered an authorizer for such use cases. If I
> misjudged that, it’s easily remedied by only a few edits to the document.
>
> *From:* Alan Woods <alan at donuts.email>
> *Sent:* Tuesday, February 4, 2020 3:13 AM
> *To:* Mark Svancarek (CELA) <marksv at microsoft.com>
> *Cc:* gnso-epdp-team at icann.org
> *Subject:* [EXTERNAL] Re: [Gnso-epdp-team] Latest version of Automated
> Use Cases document
>
> 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.
>
> */[Mark Svancarek] &$!#^! Please replace “/*make a decision to
> require*/” in Assumption VII /**/à “/*make a decision to request*/”.
> I can see how that Assumption would have colored your reading of the
> rest of the document./*
>
> 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.
>
> */[Mark Svancarek] Correct/*
>
> The model represented now effectively tries to avoid the central body
> actually processing of registration data (gateway/ Auth).
>
> */[Mark Svancarek] Clarifying, is “model represented now” the model in
> the current draft report?/*
>
> Your assumptions are forcing that body into a decision making
> controllership role (automated is still a decision).
>
> */[Mark Svancarek] None of these use cases, as far as I can tell,
> require inspection of any personal data at the Gateway; none of these
> use cases require the Gateway to become a controller of non-public
> registrant data. That was a deliberate consideration on my part. VII
> is a caveat for completeness. Perhaps this would be more clear if the
> order of VII and VIII were reversed, or if VII were simply deleted./*
>
> 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).
>
> */[Mark Svancarek] As is usual for us, the term “automation” is being
> overloaded. I was tempted to add a section to the document to clarify
> this, so perhaps it was a miss that I did not do so. The very act of
> generating a recommendation at the Gateway is automation and that’s
> one of the things being discussed here. Specific types of automation
> will occur at a CP, but “Automation” as a concept is not limited to
> the CP./*
>
> 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).
>
> */[Mark Svancarek] I don’t think the controller needs to inform the
> Gateway what it can automate in advance, but it should provide
> feedback if a recommendation for automation can’t be supported. Note
> that the Gateway could have all sorts of data potentially valuable to
> a disclosure decision, just not the non-public data of the record
> being requested. The assignment of flags is a way of codifying those
> data to enable automation./*
>
> 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.
>
> */[Mark Svancarek] I don’t think I disagree with this./*
>
> 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.
>
> */[Mark Svancarek] We require requestors to make many assertions, upon
> risk of disaccreditation/*. */This just adds another. I think you are
> perhaps missing the point of it – a requestor can only use it if they
> are literally planning not to use the data in a way that has legal or
> similarly significant effects; it’s not meant to be affixed to every
> request regardless of type or purpose. Based on feedback I have
> received, I think this is will be quite useful when automating certain
> types of requests. That’s true even though it’s non-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.
>
> */[Mark Svancarek] I do not disagree. I only hope that these examples
> will be seen as low-hanging opportunities for streamlining process, as
> described in Assumption V./*
>
> 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.
>
> */[Mark Svancarek] Yes, this is very late./*
>
> Warm regards,
>
> Alan
>
> Donuts Inc.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359608232&sdata=MiuPTUD%2FrWVSYd8Hzeew4cBOgRBSUXVCCEbE7oBDLQA%3D&reserved=0>
>
>
>
> *Alan Woods***
>
> Senior Compliance & Policy Manager, Donuts Inc.
>
> ------------------------------------------------------------------------
>
> Suite 1-31,
>
> Block D, Iveagh Court
>
> Harcourt Road
>
> Dublin 2, County Dublin
> Ireland
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Fdonutstlds&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359608232&sdata=SbaWPm0qz0ezSb7inrARc6NbQMM1z6AgQczJfFV%2Fzh8%3D&reserved=0>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDonutsInc&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359608232&sdata=6mlIkSbzD7z1B0PclwOVNe0WZ1G6ymmkYGU9Lr7UCGs%3D&reserved=0>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fdonuts-inc&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359618188&sdata=LOG3Sr3P0BWoyDEkBKRPcSVKyW3DvLIizAFjHk3R0Cw%3D&reserved=0>
>
> 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
> <mailto: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 <mailto:Gnso-epdp-team at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359618188&sdata=Bb005FEdZ1804K%2B3RNFJQXOdi3FSkaR1QQSzZKvRk58%3D&reserved=0>
> _______________________________________________
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359628146&sdata=RYh7lwkYWrl8k4gzQKwhT8kDPDJqMhGW602Nruoin0s%3D&reserved=0>)
> and the website Terms of Service
> (https://www.icann.org/privacy/tos
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C1708b061c87642b5639808d7a963527d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164116359628146&sdata=oLGY654V%2B9lUNsNWDpSXf5lMZGE4Sm4WdCeaq%2FbwgnU%3D&reserved=0>).
> 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.
>
>
> _______________________________________________
> 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.
--
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in
England and Wales with company number 8576358.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200205/33e27f20/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list