<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1003169569;
mso-list-template-ids:-2010500034;}
@list l1
{mso-list-id:1365205826;
mso-list-template-ids:1876586466;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:1436973050;
mso-list-type:hybrid;
mso-list-template-ids:567162038 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3
{mso-list-id:2051369163;
mso-list-template-ids:-36273268;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Dear Janis, </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Thank you for the questions you sent to ICANN org
</span><a href="https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002702.html"><span style="font-family:"Arial",sans-serif;color:#1155CC">on 23 October
</span></a><span style="font-family:"Arial",sans-serif;color:black">regarding the responsibility that ICANN org would be willing to take on in connection with any System for Standardized Access/Disclosure (SSAD) recommended by the EPDP Team. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">We appreciate the opportunity to forward this response from Göran Marby. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Please let us know if you have further questions or would like to discuss this response in greater detail.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Thank you,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Eleeza and Dan </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">ICANN org liaisons</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Dear Janis,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">I write in response to the questions you sent to ICANN org
</span><a href="https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002702.html"><span style="font-family:"Arial",sans-serif;color:#1155CC">on 23 October
</span></a><span style="font-family:"Arial",sans-serif;color:black">regarding the responsibility that ICANN org would be willing to take on in connection with any System for Standardized Access/Disclosure (SSAD) recommended by the EPDP Team. These questions
were forwarded by the ICANN org EPDP Phase 2 Team liaisons and I am pleased to provide this response. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">As you are aware, since receiving your questions, ICANN org
</span><a href="https://www.icann.org/news/blog/icann-org-seeks-european-data-protection-board-input"><span style="font-family:"Arial",sans-serif;color:#1155CC">published</span></a><span style="font-family:"Arial",sans-serif;color:black"> the paper, “</span><a href="https://www.icann.org/en/system/files/files/unified-access-model-gtld-registration-data-25oct19-en.pdf"><span style="font-family:"Arial",sans-serif;color:#1155CC">Exploring
a Unified Access Model for gTLD Registration Data</span></a><span style="font-family:"Arial",sans-serif;color:black">,” which it has forwarded to the European Data Protection Board (EDPB) for feedback. We will share any feedback as an input to the EPDP Phase
2 team’s consideration of a SSAD. I believe that the paper provides insights into ICANN org’s views on many of the questions posed by the EPDP Team to ICANN org. We have also prepared the answers below to further inform your discussions. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The ICANN org paper outlined a hypothetical model for purposes of soliciting feedback from the EDPB about how the European Union’s General Data Protection Regulation
(GDPR) would apply to such an access model. The model proposed in the paper has two goals, as further explained below: to centralize the decision-making power over an access request, with the goal of minimizing the exposure of the contracted parties, and ensuring
consistent data security standards, and promoting consistent, predictable user experience to the extent possible.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">In order to seek actionable guidance from EU data protection authorities, it was necessary to make certain assumptions about how a centralized UAM might operate.
This is inevitably sensitive. ICANN org is well aware that policy-making authority and responsibility lies with the bottom-up multi-stakeholder consensus policy development process and the paper notes that assumptions made therein are for discussion purposes
only. We understand and note that the EPDP Team will make its own policy recommendations, and that those may differ from the model outlined. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">I also want to acknowledge the concerns raised by various members of the EPDP Team that the paper was not shared with the team prior to ICANN org’s submission
to the EDPB. Our consultations with the European Commission on the paper took longer than anticipated. In order to allow for a discussion at the EPDP’s face-to-face meeting in Montreal and maximize the opportunity for EDPB members to review the document in
advance of its December plenary, we elected to submit the paper and release it to the EPDP on 25 October. We regret that the timing didn’t allow for further opportunities to interact with you in advance of submission. I welcome your input on how ICANN org
can support your efforts in the future.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">I hope the answers to your specific questions below are useful. I am grateful for the hard work the EPDP Team has undertaken and ICANN org remains ready to
answer any further questions you may have. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Göran Marby</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Questions to ICANN org:</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Does ICANN have a clear preference on whether or not it will:</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:.25in;margin-bottom:.0001pt;text-indent:-.25in;mso-list:l0 level1 lfo4;vertical-align:baseline">
<![if !supportLists]><b><span style="font-family:"Arial",sans-serif;color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span></b><![endif]><b><span style="font-family:"Arial",sans-serif;color:black">Field these requests for non-public data?<o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Should the EPDP recommend such a model and it is permissible under the GDPR, ICANN org is open to performing the central gateway role described in the “Exploring
a Unified Access Model” paper or taking responsibility for delegating this function to another party. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">In the model we proposed, the contracted parties would not know who the requestor is, or for what purpose the requestor is requesting data, when responding
to the central gateway’s request for data. We hope that the EDPB will confirm our understanding that the contracted parties would be responsible as controllers for this transfer to the central gateway, but not responsible for the central gateway’s subsequent
transfer to the requestor. ICANN org hopes that the EDPB will confirm that this separation of processing activities and related responsibilities would significantly reduce the legal exposure of the contracted parties for the decision to disclose registration
data to a UAM user, particularly relative to the central gateway and also compared to a decentralized model. The contracted parties’ processing within a UAM could be compared to third parties (such as banks) transferring information about debtors to credit
bureaus. In this example, the banks, as data controllers, are only responsible for this initial transfer. They are not responsible for any subsequent transfers of the data of debtors to requestors. The decision about such transfers to requestors is made by
the credit bureau as (sole and independent) controller.</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#17375E"> </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">We believe that a UAM would also enhance data security and could reduce what the contracted parties would need to do to meet their obligations to implement
appropriate technical and organizational measures to ensure a level of security appropriate to the risk (see Art. 32 (1) a) GDPR).</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The steps and roles described here are also described in greater detail in Sections 3-5 of the paper. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><b><span style="font-family:"Arial",sans-serif;color:black">2.
<span class="apple-tab-span"> </span>Maintain its own RDS replica database?</span></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">As described in the paper, ICANN org does not propose maintaining a replica of the RDS database. The transfer of data is described in Section 5 and in Section
7, which details where the data is collected and stored, including Condition 2, which notes: “Central Gateway does not store Registration Data. Requests for non-public registration data processed via the proposed UAM would reach Contracted Parties, who would
pass the data through the centralized system to the requestor. No registration data would be stored in the centralized system.”</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">ICANN org has not proposed the idea that it might maintain its own RDS replica database. We do not believe this is necessary to achieve our goal of reducing
the exposure of contracted parties, and replicating the data in a central database would create additional processing risks. This is not in the Technical Study Group’s
</span><a href="https://www.icann.org/en/system/files/files/technical-model-access-non-public-registration-data-30apr19-en.pdf"><span style="font-family:"Arial",sans-serif;color:#1155CC">technical model</span></a><span style="font-family:"Arial",sans-serif;color:black">
and was not proposed in discussions leading up to the adoption of the Temporary Specification. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><b><span style="font-family:"Arial",sans-serif;color:black">3.
<span class="apple-tab-span"> </span>Make a/the determination of the validity of the request? </span></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Answering this question requires considering what is meant by “validity.” The “Exploring a Unified Access Model” paper identifies multiple steps and roles that
are played in the processing of a request for registration data, and in the determination of whether or not to disclose data to a requestor. This UAM is based on the TSG’s
</span><a href="https://www.icann.org/en/system/files/files/technical-model-access-non-public-registration-data-30apr19-en.pdf"><span style="font-family:"Arial",sans-serif;color:#1155CC">technical model</span></a><span style="font-family:"Arial",sans-serif;color:black">
and would consolidate operational burdens and also, in ICANN org’s view, the responsibility for making these decisions. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">In the proposed UAM, an entity that wishes to request access to non-public registration data must first become accredited to use the UAM by verifying its identity
using an approved identity provider. There could be one or more identity providers in the model. Once a requestor is accredited and the requestor’s identity is verified, the requestor may submit a query to the gateway operator. When the gateway operator receives
a query from a verified requestor, it would route the request to the authorization provider.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Section 4 of the paper describes the role of the authorization provider. This entity would be responsible for evaluating a given query and the identity of the
requestor against the community-developed policy governing access to non-public registration data, and determining whether or not the request should be approved based on the application of that policy. Subject to Board approval, ICANN org is willing and able
to play this role and/or identify a third-party entity to perform this function to the extent it reduces the exposure of contracted parties under the GDPR and is consistent with EPDP-developed policy. The “Exploring a Unified Access Model” paper seeks EDPB
confirmation that this approach would effectively reduce the exposure of contracted parties under the GDPR. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><b><span style="font-family:"Arial",sans-serif;color:black">4.
<span class="apple-tab-span"> </span>Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination)?</span></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Answering this question requires consideration of what is meant by both “responsibility” and “this decision.” Responsibility could refer to who makes a decision,
or alternatively, to who is liable under the law for the consequences of making that decision. It seems logical that the liability for making a decision should sit with the entity that makes that decision and the paper seeks EDPB confirmation that this is
the case.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The question also asks about “this decision.” There are multiple decisions to be made in an access model, including:</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l1 level1 lfo5;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif">The identity provider’s decision regarding whether or not the requestor has adequately verified its identity;<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l1 level1 lfo5;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif">The authorization provider’s decision as to whether the requestor has satisfied policy standards for access, which would take into account the balancing of the interests of the data subject with the interests of
the requestor in receiving the requested data;<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l1 level1 lfo5;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif">The gateway operator’s decision as to whether or not the criteria for the requestor’s access to data have been met (has identity been verified and has the request been authorized?); and<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l1 level1 lfo5;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif">The contracted party’s decision about whether or not to release data to the gateway operator (as the contracted party would be contractually required to do) upon request from the gateway operator, in furtherance
of the interest in maintaining the security, stability, and resiliency of the Domain Name System.<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l1 level1 lfo5;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif">The role of the gateway operator is not to evaluate the merit of a request for non-public data. This role ensures that a request is authorized and authenticated. The gateway operator acts as a conduit between the
requestor, the identity provider, the authorizer, and the contracted parties. <o:p></o:p></span></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The TSG report contemplates that a model could be created in which the contracted parties would not be aware of a requestor’s identity (even at a macro level,
such as whether a request is submitted from a security researcher, intellectual property holder, law enforcement, etc.) or what data is requested, and would simply supply the the registration data set via RDAP to the central gateway whenever such data is requested
by the gateway. In that scenario, ICANN org would not need to “hold the data” to respond to the requestor and it would seem that the contracted party should not be tasked with or liable for the decision to authorize a request, balancing the interests of the
requestor and the data subject, because it is not involved in making that decision. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">In a UAM based on the TSG, the last part of your question would not apply (“even if the Contracted Party disputes ICANN’s determination.”) A contracted party
would not have visibility into a request and, as a result, would have no basis to challenge the authorization of a request. The authorization provider, not the gateway operator, would determine whether or not to approve the request by applying policy criteria
for access to data, which would take into account the balancing of the interests of the data subject with the interests of the requestor in receiving the requested data. The only decision the contracted party would make would be whether to comply with its
contractual requirement to disclose the data to the gateway in response to an authenticated and authorized request.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><b><span style="font-family:"Arial",sans-serif;color:#333333">5. Consider an approach whereby ICANN acts as a more or less “gateway” for authorized data to pass through, data provided by the Contracted Party at the
request of ICANN (per contractual requirement), with the responsibility for such disclosure to be assumed by ICANN.</span></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:#333333">In the paper, ICANN org proposed that it could operate a gateway for authorized data to pass through. As noted above, the gateway operator does not make the
decision to authorize disclosure. In the proposed model, the authorization provider would decide whether or not the criteria for disclosure are met. If a request is authorized and authenticated, the gateway operator would request the data from the contracted
party and disclose the relevant data set to the requestor. Please see the answers above and the paper for additional detail regarding responsibility for each of the actors in such a model. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span style="color:black">Marika Konings <marika.konings@icann.org><br>
<b>Date: </b>Wednesday, October 23, 2019 at 6:05 AM<br>
<b>To: </b>Eleeza Agopian <eleeza.agopian@icann.org>, Daniel Halloran <daniel.halloran@icann.org><br>
<b>Cc: </b>"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org><br>
<b>Subject: </b>Questions for ICANN Org from EPDP Team Chair<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Dear ICANN org liaisons,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">On behalf of Janis Karklins, in his capacity as EPDP Team Chair, please find hereby a number of questions for ICANN org he would appreciate a response to as soon as possible:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:black">Does ICANN have a clear preference on whether or not it will:</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3"><span style="font-size:11.0pt">Field these requests for non-public data<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3"><span style="font-size:11.0pt">Maintain its own RDS replica database<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3"><span style="font-size:11.0pt">Make a/the determination of the validity of the request<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3"><span style="font-size:11.0pt">Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor
(even if the Contracted Party disputes ICANN’s determination)<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3"><span style="font-size:11.0pt">Consider an approach whereby ICANN acts as a more or less “gateway” for authorized data to pass through, data provided by the Contracted Party at the request of
ICANN (per contractual requirement), with the responsibility for such disclosure to be assumed by ICANN.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Caitlin, Berry and Marika</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><b><i><span style="font-size:10.0pt;color:black">Marika Konings</span></i></b><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:10.0pt;color:black">Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) </span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:10.0pt;color:black">Email: <a href="mailto:marika.konings@icann.org">marika.konings@icann.org</a> </span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:10.0pt;color:black"> </span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:10.0pt;color:black">Follow the GNSO via Twitter @ICANN_GNSO</span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:10.0pt;color:black">Find out more about the GNSO by taking our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses_gnso&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=Cg5uQf0yAfw-qlFZ0WNBfsLmmtBNUiH0SuI6Vg-gXBQ&e=">interactive
courses</a> and visiting the <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gnso.icann.org_files_gnso_presentations_policy-2Defforts.htm-23newcomers&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=tT-E2RoAucUb3pfL9zmlbRdq1sytaEf765KOEkBVCjk&e=">GNSO
Newcomer pages</a>. </span></i><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>