<div>I think it would also be great if we had private sector GDPR experts participating in this WG as well.  This perspective is really being lost here so far.  </div><div><br></div><div>For instance, I just downloaded an extensive document from Trust-e on business compliance with GDPR; also many law firms are beginning to issue public papers on private sector compliance with GDPR (and are presumably offering significantly more information to their paying clients).  I could read all of this and more and I would still not likely be a GDPR expert (nor am I admitted in the EU...).  I&#39;m sure that inside counsel are also providing advice to their companies.  </div><div><br></div><div>It would be really helpful (for balance, for ideas, for solutions, etc.) to hear from this side of the process and not just the government side.  (By the way, I&#39;ve put out some feelers for people to participate from this perspective but no response yet.). Ultimately we are talking about a private sector implementation, so this is a critical perspective.  I&#39;m sure that the public sector folks would love to simply dictate how the private sector should implement their responses to legislation but thankfully that&#39;s not the system most of us live under and certainly not consistent with the ICANN multistakeholder approach.</div><div><br></div><div>Greg</div><div><br></div><div><br></div><div><div class="gmail_quote"><div>On Fri, May 19, 2017 at 9:36 AM Gomes, Chuck via gnso-rds-pdp-wg &lt;<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_6056580136789696143WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">We may want to do this several times when we get to good points in our work and have substantial tentative recommendations to seek feedback on.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">Chuck<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_6056580136789696143__MailEndCompose"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"><u></u> <u></u></span></a></p>
<span></span>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"> Farell Folly [mailto:<a href="mailto:farellfolly@gmail.com" target="_blank">farellfolly@gmail.com</a>]
<br>
<b>Sent:</b> Friday, May 19, 2017 9:14 AM<br>
<b>To:</b> Paul Keating &lt;<a href="mailto:paul@law.es" target="_blank">paul@law.es</a>&gt;; Gomes, Chuck &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt;<br>
<b>Cc:</b> <a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_6056580136789696143WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity<u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_6056580136789696143WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I also suggest that we plan for an outreach events (later on) to requests comment from countries on the possible conflicts and confusions the requirements we are proposing can contain. i.e, as a WG member, one can find a way (liaise with
 local authorities via ICANN representative if necessary) to check with the local/national/regional authorities how the requirements are in line with their data privacy laws. This should not be for the purpose to increase the duration of the current phase,
 nor to endorse all comments, but to seek for external opinions which can help to better formulate the requirements.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Le jeu. 18 mai 2017 à 22:52, Paul Keating &lt;<a href="mailto:paul@law.es" target="_blank">paul@law.es</a>&gt; a écrit :<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Excellent.  As usual, better minds are ahead of me.  All good.  Thank you.<br>
<br>
Sent from my iPad<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On 18 May 2017, at 22:35, Gomes, Chuck via gnso-rds-pdp-wg &lt;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>&gt; wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Thank you very much Stephanie.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Chuck<u></u><u></u></p>
<p class="MsoNormal"><a name="m_6056580136789696143_m_-2404684693340241075__MailEndCompose"> </a><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounces@icann.org</a> [<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Stephanie Perrin<br>
<b>Sent:</b> Thursday, May 18, 2017 3:14 PM<br>
<b>To:</b> <a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p><span style="font-size:13.5pt">I recently attended the International Working Group on Data Protection in Telecommunications and reiterated that the DPAs would be most welcome both on the working group and in Johannesburg.</span><u></u><u></u></p>
<p><span style="font-size:13.5pt">Stephanie Perrin</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On 2017-05-18 14:53, Gomes, Chuck via gnso-rds-pdp-wg wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">We are definitely not intending to do our work in a vacuum.  That is why we cooperated in scheduling the sessions in Copenhagen with Data Protection experts and send those experts
 a long list of questions.  All of them assured us that they would continue to work with us as needed. 
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Peter – If you have not already done so, please feel free to make sure that the Data Protection Commissioners and experts you know are aware that they would be welcome to join our
 WG.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Chuck<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Paul Keating [<a href="mailto:paul@law.es" target="_blank">mailto:paul@law.es</a>]
<br>
<b>Sent:</b> Thursday, May 18, 2017 12:32 PM<br>
<b>To:</b> Gomes, Chuck <a href="mailto:cgomes@verisign.com" target="_blank">&lt;cgomes@verisign.com&gt;</a><br>
<b>Cc:</b> <a href="mailto:gca@icginc.com" target="_blank">gca@icginc.com</a>; <a href="mailto:lisa@corecom.com" target="_blank">
lisa@corecom.com</a>; <a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">
gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Thanks,  my proposal is to do an outreach program. It does us little good to design systems and policy in a vacuum. <br>
<br>
Sent from my iPad<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On 18 May 2017, at 14:44, Gomes, Chuck &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt; wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Paul,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">They would of course be welcome.  I would like to point out that Peter Kimpian is one of them and is a WG member.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Chuck<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Paul Keating [<a href="mailto:Paul@law.es" target="_blank">mailto:Paul@law.es</a>]
<br>
<b>Sent:</b> Thursday, May 18, 2017 6:25 AM<br>
<b>To:</b> Gomes, Chuck &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt;;
<a href="mailto:gca@icginc.com" target="_blank">gca@icginc.com</a>; <a href="mailto:lisa@corecom.com" target="_blank">
lisa@corecom.com</a>; <a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">
gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt">Chuck,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt">I may be going out on a limb here but wouldn’t it be appropriate to have the privacy authorities actually participating in this WG?  </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt">There are many opinions floating around in the emails and I see a continuing pattern of confusion.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt">Given the importance of the governmental authorities here is it not rationale to have their direct participation so we can reach a workable solution?</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt">Paul</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:
</b>&lt;<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounces@icann.org</a>&gt; on behalf of &quot;Gomes, Chuck via gnso-rds-pdp-wg&quot; &lt;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>&gt;<br>
<b>Reply-To: </b>&quot;Gomes, Chuck&quot; &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt;<br>
<b>Date: </b>Tuesday, May 16, 2017 at 3:14 AM<br>
<b>To: </b>&quot;<a href="mailto:gca@icginc.com" target="_blank">gca@icginc.com</a>&quot; &lt;<a href="mailto:gca@icginc.com" target="_blank">gca@icginc.com</a>&gt;, &quot;<a href="mailto:lisa@corecom.com" target="_blank">lisa@corecom.com</a>&quot; &lt;<a href="mailto:lisa@corecom.com" target="_blank">lisa@corecom.com</a>&gt;,
 &quot;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>&quot; &lt;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>&gt;<br>
<b>Subject: </b>Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt"> </span><u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #b5c4df 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="m_6056580136789696143m_-2404684693340241075MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal">Greg,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Considering that we already have rough consensus that requestor does not have to be identified, what would need to be authenticated?  In other words, why would we need to add ‘without
 authentication’?<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">It would be helpful if you could respond to these questions on Tuesday  before our WG meeting on Wednesday considering you will not be able to attend the WG call.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Chuck<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Greg Aaron [<a href="mailto:gca@icginc.com" target="_blank">mailto:gca@icginc.com</a>]
<br>
<b>Sent:</b> Monday, May 15, 2017 8:14 PM<br>
<b>To:</b> Lisa Phifer &lt;<a href="mailto:lisa@corecom.com" target="_blank">lisa@corecom.com</a>&gt;; Gomes, Chuck &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt;;
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] RE: Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Thanks you, Lisa.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I will be unable to make the next meeting because the 05:00 UTC meeting time.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Based on last week’s meeting, I I think we are aiming for something like:<u></u><u></u></p>
<p class="MsoNormal">&quot;Thin data elements must be accessible to anonymous requestors, without authentication.”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">If we say:<u></u><u></u></p>
<p class="MsoNormal">&quot;Thin data elements must be accessible without requestor authentication&quot;<u></u><u></u></p>
<p class="MsoNormal">then that means consumers of registration data might or might not be anonymous. 
<u></u><u></u></p>
<p class="MsoNormal">For example, a registry operator could make me register my IP address, from which I can query registration data.  Those queries could be made without  authentication (a username/password),
 and so the registry’s registration program could be allowed.  But arguably I would not be anonymous. 
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Whatever policy  language is proposed must be examined for how it can be interpreted and possibly bypassed.   Both the intent of the WG and the specific language will eventually
 need to be laid out.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">So I also suggest it be made explicit that access to registration data remain free, without charge. 
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">All best,<u></u><u></u></p>
<p class="MsoNormal">--Greg<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.0pt"> </span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Lisa Phifer [<a href="mailto:lisa@corecom.com" target="_blank">mailto:lisa@corecom.com</a>]
<br>
<b>Sent:</b> Wednesday, May 10, 2017 12:04 PM<br>
<b>To:</b> Greg Aaron &lt;<a href="mailto:gca@icginc.com" target="_blank">gca@icginc.com</a>&gt;; Gomes, Chuck &lt;<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>&gt;;
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> Definitions: Authentication and Anonymity<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">All,<br>
<br>
Starting a new thread to pursue Greg&#39;s suggestion to agree upon definitions for &quot;authentication&quot; and &quot;anonymity&quot; to help the WG address the charter question now under deliberation.<br>
<br>
Below are a few definitions copied verbatim from RFC 4949 (<a href="https://tools.ietf.org/html/rfc4949" target="_blank"> https://tools.ietf.org/html/rfc4949</a>) as a starting point for WG discussion of these and other possible sources/definitions.<br>
<br>
Lisa<br>
<br>
>From RFC 4949:<u></u><u></u></p>
<pre> $ anonymity<u></u><u></u></pre>
<pre>      (I) The condition of an identity being<u></u><u></u></pre>
<pre>unknown or concealed. (See:<u></u><u></u></pre>
<pre>      alias, anonymizer, anonymous credential,<u></u><u></u></pre>
<pre>anonymous login,<u></u><u></u></pre>
<pre>      identity, onion routing, persona<u></u><u></u></pre>
<pre>certificate. Compare: privacy.)<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>      Tutorial: An application may require<u></u><u></u></pre>
<pre>security services that<u></u><u></u></pre>
<pre>      maintain anonymity of users or other<u></u><u></u></pre>
<pre>system entities, perhaps to<u></u><u></u></pre>
<pre>      preserve their privacy or hide them from<u></u><u></u></pre>
<pre>attack. To hide an<u></u><u></u></pre>
<pre>      entity&#39;s real name, an alias may be used;<u></u><u></u></pre>
<pre>for example, a financial<u></u><u></u></pre>
<pre>      institution may assign account numbers.<u></u><u></u></pre>
<pre>Parties to transactions<u></u><u></u></pre>
<pre>      can thus remain relatively anonymous, but<u></u><u></u></pre>
<pre>can also accept the<u></u><u></u></pre>
<pre>      transactions as legitimate. Real names of<u></u><u></u></pre>
<pre>the parties cannot be<u></u><u></u></pre>
<pre>      easily determined by observers of the<u></u><u></u></pre>
<pre>transactions, but an<u></u><u></u></pre>
<pre>      authorized third party may be able to map<u></u><u></u></pre>
<pre>an alias to a real name,<u></u><u></u></pre>
<pre>      such as by presenting the institution with<u></u><u></u></pre>
<pre>a court order. In other<u></u><u></u></pre>
<pre>      applications, anonymous entities may be<u></u><u></u></pre>
<pre>completely untraceable.<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<p class="MsoNormal">From RFC 4949:<u></u><u></u></p>
<pre>$ anonymous login<u></u><u></u></pre>
<pre>      (I) An access control feature (actually,<u></u><u></u></pre>
<pre>an access control<u></u><u></u></pre>
<pre>      vulnerability) in many Internet hosts that<u></u><u></u></pre>
<pre>enables users to gain<u></u><u></u></pre>
<pre>      access to general-purpose or public<u></u><u></u></pre>
<pre>services and resources of a<u></u><u></u></pre>
<pre>      host (such as allowing any user to<u></u><u></u></pre>
<pre>transfer data using FTP)<u></u><u></u></pre>
<pre>      without having a pre-established,<u></u><u></u></pre>
<pre>identity-specific account (i.e.,<u></u><u></u></pre>
<pre>      user name and password). (See:<u></u><u></u></pre>
<pre>anonymity.)<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>      Tutorial: This feature exposes a system to<u></u><u></u></pre>
<pre>more threats than when<u></u><u></u></pre>
<pre>      all the users are known, pre-registered<u></u><u></u></pre>
<pre>entities that are<u></u><u></u></pre>
<pre>      individually accountable for their<u></u><u></u></pre>
<pre>actions. A user logs in using a<u></u><u></u></pre>
<pre>      special, publicly known user name (e.g.,<u></u><u></u></pre>
<pre>&quot;anonymous&quot;, &quot;guest&quot;, or<u></u><u></u></pre>
<pre>      &quot;ftp&quot;). To use the public login<u></u><u></u></pre>
<pre>name, the user is not required to<u></u><u></u></pre>
<pre>      know a secret password and may not be<u></u><u></u></pre>
<pre>required to input anything<u></u><u></u></pre>
<pre>      at all except the name. In other cases, to<u></u><u></u></pre>
<pre>complete the normal<u></u><u></u></pre>
<pre>      sequence of steps in a login protocol, the<u></u><u></u></pre>
<pre>system may require the<u></u><u></u></pre>
<pre>      user to input a matching, publicly known<u></u><u></u></pre>
<pre>password (such as<u></u><u></u></pre>
<pre>      &quot;anonymous&quot;) or may ask the user<u></u><u></u></pre>
<pre>for an e-mail address or some<u></u><u></u></pre>
<pre>      other arbitrary character string.<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<p class="MsoNormal">From RFC 4949:<u></u><u></u></p>
<pre>$ authenticate<u></u><u></u></pre>
<pre>      (I) Verify (i.e., establish the truth of)<u></u><u></u></pre>
<pre>an attribute value<u></u><u></u></pre>
<pre>      claimed by or for a system entity or<u></u><u></u></pre>
<pre>system resource. (See:<u></u><u></u></pre>
<pre>      authentication, validate vs. verify,<u></u><u></u></pre>
<pre>&quot;relationship between data<u></u><u></u></pre>
<pre>      integrity service and authentication<u></u><u></u></pre>
<pre>services&quot; under &quot;data<u></u><u></u></pre>
<pre>      integrity service&quot;.)<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>      Deprecated Usage: In general English<u></u><u></u></pre>
<pre>usage, this term is used with<u></u><u></u></pre>
<pre>      the meaning &quot;to prove genuine&quot;<u></u><u></u></pre>
<pre>(e.g., an art expert authenticates<u></u><u></u></pre>
<pre>      a Michelangelo painting); but IDOCs should<u></u><u></u></pre>
<pre>restrict usage as<u></u><u></u></pre>
<pre>      follows:<u></u><u></u></pre>
<pre>      -  IDOCs SHOULD NOT use this term to<u></u><u></u></pre>
<pre>refer to proving or checking<u></u><u></u></pre>
<pre>         that data has not been<u></u><u></u></pre>
<pre>changed, destroyed, or lost in an<u></u><u></u></pre>
<pre>         unauthorized or<u></u><u></u></pre>
<pre>accidental manner. Instead, use &quot;verify&quot;.<u></u><u></u></pre>
<pre>      -  IDOCs SHOULD NOT use this term to<u></u><u></u></pre>
<pre>refer to proving the truth or<u></u><u></u></pre>
<pre>         accuracy of a fact or<u></u><u></u></pre>
<pre>value such as a digital signature.<u></u><u></u></pre>
<pre>         Instead, use<u></u><u></u></pre>
<pre>&quot;verify&quot;.<u></u><u></u></pre>
<pre>      -  IDOCs SHOULD NOT use this term to<u></u><u></u></pre>
<pre>refer to establishing the<u></u><u></u></pre>
<pre>         soundness or correctness<u></u><u></u></pre>
<pre>of a construct, such as a digital<u></u><u></u></pre>
<pre>         certificate. Instead,<u></u><u></u></pre>
<pre>use &quot;validate&quot;.<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<p class="MsoNormal">From RFC 4949:<u></u><u></u></p>
<pre>   $ authentication<u></u><u></u></pre>
<pre>      (I) The process of verifying a claim that<u></u><u></u></pre>
<pre>a system entity or<u></u><u></u></pre>
<pre>      system resource has a certain attribute<u></u><u></u></pre>
<pre>value. (See: attribute,<u></u><u></u></pre>
<pre>      authenticate, authentication exchange,<u></u><u></u></pre>
<pre>authentication information,<u></u><u></u></pre>
<pre>      credential, data origin authentication,<u></u><u></u></pre>
<pre>peer entity<u></u><u></u></pre>
<pre>      authentication, &quot;relationship between<u></u><u></u></pre>
<pre>data integrity service and<u></u><u></u></pre>
<pre>      authentication services&quot; under<u></u><u></u></pre>
<pre>&quot;data integrity service&quot;, simple<u></u><u></u></pre>
<pre>      authentication, strong authentication,<u></u><u></u></pre>
<pre>verification, X.509.)<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>      Tutorial: Security services frequently<u></u><u></u></pre>
<pre>depend on authentication of<u></u><u></u></pre>
<pre>      the identity of users, but authentication<u></u><u></u></pre>
<pre>may involve any type of<u></u><u></u></pre>
<pre>      attribute that is recognized by a system.<u></u><u></u></pre>
<pre>A claim may be made by a<u></u><u></u></pre>
<pre>      subject about itself (e.g., at login, a<u></u><u></u></pre>
<pre>user typically asserts its<u></u><u></u></pre>
<pre>      identity) or a claim may be made on behalf<u></u><u></u></pre>
<pre>of a subject or object<u></u><u></u></pre>
<pre>      by some other system entity (e.g., a user<u></u><u></u></pre>
<pre>may claim that a data<u></u><u></u></pre>
<pre>      object originates from a specific source,<u></u><u></u></pre>
<pre>or that a data object is<u></u><u></u></pre>
<pre>      classified at a specific security level).<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>      An authentication process consists of two<u></u><u></u></pre>
<pre>basic steps:<u></u><u></u></pre>
<pre>      -  Identification step: Presenting<u></u><u></u></pre>
<pre>the claimed attribute value<u></u><u></u></pre>
<pre>         (e.g., a user<u></u><u></u></pre>
<pre>identifier) to the authentication subsystem.<u></u><u></u></pre>
<pre>      -  Verification step: Presenting or<u></u><u></u></pre>
<pre>generating authentication<u></u><u></u></pre>
<pre>         information (e.g., a<u></u><u></u></pre>
<pre>value signed with a private key) that acts<u></u><u></u></pre>
<pre>         as evidence to prove the<u></u><u></u></pre>
<pre>binding between the attribute and that<u></u><u></u></pre>
<pre>         for which it is claimed.<u></u><u></u></pre>
<pre>(See: verification.)<u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<p class="MsoNormal">---------<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt">_______________________________________________ gnso-rds-pdp-wg mailing list
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></span><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>gnso-rds-pdp-wg mailing list<u></u><u></u></pre>
<pre><a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><u></u><u></u></pre>
<pre><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal">-- <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Regards<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">@__f_f__<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">PhD Candidate, Universität der Bundeswehr München<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Computer Security | Internet of Things<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="http://about.me/farell" target="_blank">about.me/farell</a><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div></div>

_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"></p><div><p style="text-indent:0in"><span style="font-size:12.8px"><a></a></span><b style="font-size:12.8px"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#002e62">Greg
Shatan<br>
</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:black">C: 917-816-6428<br>
S: gsshatan</span><font color="#000000" face="Arial, sans-serif"><span style="font-size:13.3333px"><br></span></font><a href="mailto:gregshatanipc@gmail.com" style="font-family:Arial,sans-serif;font-size:10pt;text-indent:0in" target="_blank"><span style="color:#1155cc">gregshatanipc@gmail.com</span></a></p><p style="font-size:12.8px;text-indent:0in"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;"></span></p></div></div></div></div></div></div></div></div></div></div></div></div></div>