[IRT.RegDataPolicy] Tech contact consent
betty fausta
bf at ipeos.fr
Mon Jul 29 02:28:34 UTC 2019
I support Sarah with her purpose about privacy, personal data
-------
Betty FAUSTA CEO - Gérante
IPEOS I-Solutions [Guadeloupe- Martinique- Guyane]
Société de Services en Ingénierie Informatique et Internet
GSM : +590 690 49 73 09 | Fixe : + 590 590 22 80 20 | Fax: 0972337124
Skype : betfau/0970 446 047 - - Network : Viber/Tango/Whats'app / Twitter
---------------------------------------------------------------
-----------------------------------------
Offres Internet www.ipeos.net - Informatique www.ipeos.com
Le ven. 26 juil. 2019 à 14:02, Sarah Wyld <swyld at tucows.com> a écrit :
> Hi Mark,
>
> I disagree with this view of how consent works.
>
> Under data privacy laws such as PIPEDA (Canada) and GDPR (EU), consent
> must be an explicit opt-in. Simply informing a person that their data will
> be used, without giving them the option to accept or deny before the data
> is processed, is not properly considered to be consent.
>
> Focusing specifically on the question of consenting to publication, what
> this tells me is that we need an approval from the person whose data is
> being published, and that needs to happen before the publication takes
> place. Then we're back to the question of whether the Tech contact can
> consent to publication of their own data, on which I will refrain from
> repeating my initial email in this thread :)
>
>
> *Links for reference:*
>
> PIPEDA Guidelines for Meaningful Consent:
> https://www.priv.gc.ca/en/privacy-topics/collecting-personal-information/consent/gl_omc_201805/
>
> ICO guide on Consent:
> https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent/
>
>
> --
> Sarah Wyld
> Domains Product Team
> Tucows
> +1.416 535 0123 Ext. 1392
>
>
>
> On 7/26/2019 12:01 PM, Mark Svancarek (CELA) wrote:
>
> inline
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org>
> <irt.regdatapolicy-bounces at icann.org> *On Behalf Of *Sarah Wyld
> *Sent:* Friday, July 26, 2019 06:16
> *To:* irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] Tech contact consent
>
>
>
> Hello all,
>
> > 1. One would not collect “consent” from the RNH. There is a concept
> that if the RNH attests that they’ve gotten agreement from the Tech contact
> that the Rr is safe to proceed, particularly if the sign-up UI is
> well-defined and the Tech contact is informed during the initial accuracy
> check. We should get some legal advice on that.
>
> Well, the Policy section to which I was responding did originally have the
> RNH contact consenting to publish the Tech contact data; it was then
> updated to show the Tech contact consenting for their own data. We do
> already have legal advice on exactly this topic. Please visit
> https://community.icann.org/pages/viewpage.action?pageId=105386422
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fpages%2Fviewpage.action%3FpageId%3D105386422&data=02%7C01%7Cmarksv%40microsoft.com%7Cc6192db609dc47acecd808d711cb5495%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636997437316049924&sdata=y5X4Lg97B6uqrYu4vYLfgf9gqvMCFuBbqNmA%2BwI0Hxo%3D&reserved=0>
> and look to #3, "Technical Contact Memo.docx". The conclusion in points 11
> & 12 is that the Registrar cannot rely on the RNH to provide notice to the
> Tech contact on the Registrar's behalf, nor can the RNH be relied on to get
> the Tech contact's consent for data processing.
>
> *[Mark Svancarek] Sorry for mis-reading the thread. I thought you were
> discussing collecting consent *of* the RNH to publish the Tech contact
> info, rather than collecting the consent of the Tech contact *by way of*
> the RNH. Mea culpa. The legal advice does indeed confirm that such a
> system is unreliable, but what I am suggesting is different from the
> primary focus of that the legal advice.*
>
> *Regarding collecting the Registrar collecting Tech contact consent
> directly from the Tech contact, you’d do that when the Tech contact is
> “informed” – you would send an email to the Tech contact at the same time
> as your obligatory accuracy check. The controller has taken active steps,
> Tech contact is been informed, and the data subject can access their data
> and change it or delete it. This would meet the requirements of Article
> 14, and is the mechanism I described above. Advice bullet 11 implies this
> is possible (though it isn’t the topic of the memo per se), which is why I
> have confidence in this approach. I don’t see how Article 14 possibly
> works if the controller is not allowed to use the personal information they
> received to inform the data subject. And *that* is what I suggested we
> could get legal advice on.*
>
> *I understand that some registrars will not want to send this notice or
> offer this functionality, and they are not obliged in policy to do so, but
> I disagree with the assertion that it cannot lawfully be done.*
>
> *Does that make sense?*
>
> > 2. I get a sense that we are creating new policy here, namely going down
> a path to prevent the collection of the Tech contact, in violation of the
> intent of the recommendation. For clarity, please let me know if you can
> support either of these scenarios:
>
> Nothing in my email below regarding the Tech contact consent to
> publication of their data was intended to relate to *collecting *a Tech
> contact in the first place.
>
> *Yep, oops, sorry about that.*
>
> That requirement is separate and I know we've had other conversations
> about it, which we can continue as needed, but I'd suggest we keep it a
> separate thread so as to avoid confusion of these issues. My point is
> simply that there is no avenue in the Recommendations or under applicable
> law for the RNH to consent to data publication on the Tech contact's
> behalf, nor even for the Tech contact themselves to grant this consent for
> publication.
>
> Thanks and happy Friday!
>
> *[Mark Svancarek] Right back at you!*
>
>
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
> On 7/25/2019 4:39 PM, Mark Svancarek (CELA) via IRT.RegDataPolicy wrote:
>
> 1. One would not collect “consent” from the RNH. There is a concept
> that if the RNH attests that they’ve gotten agreement from the Tech contact
> that the Rr is safe to proceed, particularly if the sign-up UI is
> well-defined and the Tech contact is informed during the initial accuracy
> check. We should get some legal advice on that.
>
> 2. I get a sense that we are creating new policy here, namely going
> down a path to prevent the collection of the Tech contact, in violation of
> the intent of the recommendation. For clarity, please let me know if you
> can support either of these scenarios:
>
> a. Microsoft wants to use “Domain Administrator” / domains at microsoft.com
> as registrant and “MSN Hostmaster” / msnhst at microsoft.com as Tech
> contact.
>
> b. A church wants to register a domain name as themselves (an org) and
> wants to have the geekiest member of the congregation be the Tech contact.
>
>
>
> (Thanks to Stephanie P for scenario b.)
>
>
>
> /marksv
>
>
>
>
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org>
> <irt.regdatapolicy-bounces at icann.org> *On Behalf Of *Elizabeth Bacon
> *Sent:* Tuesday, July 23, 2019 9:08 AM
> *To:* Roger D Carney <rcarney at godaddy.com> <rcarney at godaddy.com>;
> IRT.RegDataPolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] Tech contact consent
>
>
>
> Agreed all around. Including a requirement, or even option, to collect
> consent from a RNH is not consistent with the work or recommendations of
> Phase I.
>
> Thanks,
>
> Beth
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> *On
> Behalf Of *Roger D Carney
> *Sent:* Tuesday, July 23, 2019 11:00 AM
> *To:* IRT.RegDataPolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] Tech contact consent
>
>
>
> Good Morning,
>
>
>
> +1 to Sarah’s comments, thanks Amr for the extra insight as well.
>
>
>
>
>
> Thanks
>
> Roger
>
>
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> *On
> Behalf Of *Amr Elsadr
> *Sent:* Sunday, July 21, 2019 7:04 AM
> *To:* Sarah Wyld <swyld at tucows.com>
> *Cc:* irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] Tech contact consent
>
>
>
> Notice: This email is from an external sender.
>
>
>
> Hi,
>
>
>
> Lending my support to everything in Sarah's email below. The draft
> Consensus Policy language (sections 8.3 and 8.3.2) should only allow for
> publication of Tech Contact personal information upon gaining consent when
> the Registered Name Holder and the Tech Contact are the same (assuming this
> is implementable).
>
>
>
> However, the EPDP Team did not review privacy/data protection law
> requirements when processing of personal information is performed when this
> personal information was not obtained from the data subject (such as a Tech
> Contact who is not the same natural person as the Registered Name Holder).
> The EPDP Team, therefore, did not make a recommendation on how to gain
> consent to publish this data.
>
>
>
> Thanks.
>
>
>
> Amr
>
>
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Thursday, July 18, 2019 2:42 PM, Sarah Wyld <swyld at tucows.com> wrote:
>
>
>
> Hello team,
>
> There is some great discussion in the Google Doc (
> https://docs.google.com/document/d/1OuZT7xL5wuV1ynVmpVNxFycU93gvPlvbzx_g9lXCYCw/edit?ts=5d2f60ce#
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1OuZT7xL5wuV1ynVmpVNxFycU93gvPlvbzx_g9lXCYCw%2Fedit%3Fts%3D5d2f60ce&data=02%7C01%7Cmarksv%40microsoft.com%7Cc6192db609dc47acecd808d711cb5495%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636997437316049924&sdata=8uuBoWHgF%2B2pF84G3L6cacLxlDSd4P1wE2npKhabBC8%3D&reserved=0>)
> about the possibility for the Tech contact to consent to publication of
> their data (name, phone and email), but I think it's a bit easier to
> consider it by email, so I will start this discussion and look forward to
> hearing what everyone else thinks.
>
> I see it as two separate questions, one of which is already resolved and
> the other remaining open.
>
> *1 - can the RNH grant consent for publication of Tech contact data? *
>
> Based on comments in the doc (including mine) and Dennis's subsequent
> changes, there is agreement that it is not possible for one person to
> consent to publication of another person's data. So, if the RNH is also the
> Tech contact, then maybe they could grant consent (if it's possible in an
> automated manner for the registrar to know that these contacts are the
> same, which may not be possible) but certainly if it's a different person
> then this is not an option.
>
> *2 - can the Tech contact grant consent for publication of its own data? *
>
> Although on the surface this sounds straightforward, I think it's actually
> a problem.
>
> There is no Recommendation in the Phase 1 final report relating to the
> Tech contact granting consent. Rec 5 explains what the tech contact may be
> ("For the purpose of the Technical contact, which is optional for the
> Registered Name Holder to complete (and if the Registrar provides this
> option), Registrars are to advise the Registered Name Holder at the time of
> registration that the Registered Name Holder is free to (1) designate the
> same person as the registrant (or its representative) as the technical
> contact; or (2) provide contact information which does not directly
> identify the technical contact person concerned.") Rec 6 requires that the
> RNH can consent to publication ("The EPDP Team recommends that, as soon as
> commercially reasonable, Registrar must provide the opportunity for the
> Registered Name Holder to provide its Consent to publish redacted contact
> information, as well as the email address, in the RDS for the sponsoring
> registrar.") Rec 10 requires that the tech contact is redacted. Rec 13
> refers again to the RNH consenting to publication of their data ("1) The
> EPDP Team recommends that the Registrar MUST provide an email address or a
> web form to facilitate email communication with the relevant contact, but
> MUST NOT identify the contact email address or the contact itself, unless
> as per Recommendation #6, the Registered Name Holder has provided consent
> for the publication of its email address.")
>
>
> Additionally, the Registrar may not have a legal basis on which to publish
> the Tech contact data (again, assuming it is not known to be the same as
> the RNH data). There is no contractual relationship between the registrar
> and the tech contact, so 'performance of a contract' cannot be the basis
> for publication, and because there is no contractual relationship it would
> be improper for the registrar to communicate with the tech contact (the
> registrar does not have any legal basis on which to process the tech
> contact's data) even just to send them an email about this consent request.
>
> As such, for question 2 the answer should be no, *the Tech contact cannot
> grant consent to publish their data*.
>
> Thanks,
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Firt.regdatapolicy&data=02%7C01%7Cmarksv%40microsoft.com%7Cc6192db609dc47acecd808d711cb5495%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636997437316059933&sdata=2YfghxXjuW1A3wuw4ctY%2Fxce%2FsiP8gIA0qo4PQPDmE4%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%7Cc6192db609dc47acecd808d711cb5495%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636997437316069938&sdata=HWQSuuXgrtO39%2FYPLminyRDpEsTL0RyaeeFlzyoiSc0%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%7Cc6192db609dc47acecd808d711cb5495%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636997437316069938&sdata=8c90ABJ9DXAyyicNuCkdLl9o9H5hIK8BouS8Pchg8N0%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.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> 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/irt.regdatapolicy/attachments/20190728/febc0065/attachment.html>
More information about the IRT.RegDataPolicy
mailing list