<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">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.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Stephanie Perrin</font></font><br>
</p>
<br>
<div class="moz-cite-prefix">On 2017-05-18 14:53, Gomes, Chuck via
gnso-rds-pdp-wg wrote:<br>
</div>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E74B86F17@BRN1WNEXMBX02.vcorp.ad.vrsn.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
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.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
--></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]-->
<div class="WordSection1">
<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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Chuck<o:p></o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><o:p> </o:p></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<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 class="moz-txt-link-freetext" href="mailto:paul@law.es">mailto:paul@law.es</a>] <br>
<b>Sent:</b> Thursday, May 18, 2017 12:32 PM<br>
<b>To:</b> Gomes, Chuck <a class="moz-txt-link-rfc2396E" href="mailto:cgomes@verisign.com"><cgomes@verisign.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:gca@icginc.com">gca@icginc.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:lisa@corecom.com">lisa@corecom.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg]
Definitions: Authentication and Anonymity<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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<span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On 18 May 2017, at 14:44, Gomes, Chuck <<a
moz-do-not-send="true" href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Paul,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Chuck<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></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
moz-do-not-send="true" href="mailto:Paul@law.es">mailto:Paul@law.es</a>]
<br>
<b>Sent:</b> Thursday, May 18, 2017 6:25 AM<br>
<b>To:</b> Gomes, Chuck <<a moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>;
<a moz-do-not-send="true" href="mailto:gca@icginc.com">gca@icginc.com</a>;
<a moz-do-not-send="true"
href="mailto:lisa@corecom.com">
lisa@corecom.com</a>; <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg]
Definitions: Authentication and Anonymity<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">Chuck,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">There are many
opinions floating around in the emails and I see a
continuing pattern of confusion.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">Paul</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></p>
</div>
<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"><<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>>
on behalf of "Gomes, Chuck via gnso-rds-pdp-wg" <<a
moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>><br>
<b>Reply-To: </b>"Gomes, Chuck" <<a
moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>><br>
<b>Date: </b>Tuesday, May 16, 2017 at 3:14 AM<br>
<b>To: </b>"<a moz-do-not-send="true"
href="mailto:gca@icginc.com">gca@icginc.com</a>"
<<a moz-do-not-send="true"
href="mailto:gca@icginc.com">gca@icginc.com</a>>,
"<a moz-do-not-send="true"
href="mailto:lisa@corecom.com">lisa@corecom.com</a>"
<<a moz-do-not-send="true"
href="mailto:lisa@corecom.com">lisa@corecom.com</a>>,
"<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>"
<<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>><br>
<b>Subject: </b>Re: [gnso-rds-pdp-wg] Definitions:
Authentication and Anonymity</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black"> </span><o:p></o:p></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="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Greg,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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’?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Chuck</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span
style="color:black"> Greg Aaron [<a
moz-do-not-send="true"
href="mailto:gca@icginc.com">mailto:gca@icginc.com</a>]
<br>
<b>Sent:</b> Monday, May 15, 2017 8:14 PM<br>
<b>To:</b> Lisa Phifer <<a
moz-do-not-send="true"
href="mailto:lisa@corecom.com">lisa@corecom.com</a>>;
Gomes, Chuck <<a moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>;
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] RE: Definitions:
Authentication and Anonymity</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Thanks
you, Lisa.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">I will
be unable to make the next meeting because the
05:00 UTC meeting time.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Based
on last week’s meeting, I I think we are aiming
for something like:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">"Thin
data elements must be accessible to anonymous
requestors, without authentication.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">If we
say:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">"Thin
data elements must be accessible without requestor
authentication"</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">then
that means consumers of registration data might or
might not be anonymous.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.
</span>
<o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">So I
also suggest it be made explicit that access to
registration data remain free, without charge.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">All
best,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">--Greg</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span
style="color:black"> Lisa Phifer [<a
moz-do-not-send="true"
href="mailto:lisa@corecom.com">mailto:lisa@corecom.com</a>]
<br>
<b>Sent:</b> Wednesday, May 10, 2017 12:04 PM<br>
<b>To:</b> Greg Aaron <<a
moz-do-not-send="true"
href="mailto:gca@icginc.com">gca@icginc.com</a>>;
Gomes, Chuck <<a moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>;
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> Definitions: Authentication
and Anonymity</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">All,<br>
<br>
Starting a new thread to pursue Greg's suggestion
to agree upon definitions for "authentication" and
"anonymity" to help the WG address the charter
question now under deliberation.<br>
<br>
Below are a few definitions copied verbatim from
RFC 4949 (<a moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc4949">
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:</span><o:p></o:p></p>
<pre><span style="color:black"> $ anonymity</span><o:p></o:p></pre>
<pre><span style="color:black"> (I) The condition of an identity being</span><o:p></o:p></pre>
<pre><span style="color:black">unknown or concealed. (See:</span><o:p></o:p></pre>
<pre><span style="color:black"> alias, anonymizer, anonymous credential,</span><o:p></o:p></pre>
<pre><span style="color:black">anonymous login,</span><o:p></o:p></pre>
<pre><span style="color:black"> identity, onion routing, persona</span><o:p></o:p></pre>
<pre><span style="color:black">certificate. Compare: privacy.)</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<pre><span style="color:black"> Tutorial: An application may require</span><o:p></o:p></pre>
<pre><span style="color:black">security services that</span><o:p></o:p></pre>
<pre><span style="color:black"> maintain anonymity of users or other</span><o:p></o:p></pre>
<pre><span style="color:black">system entities, perhaps to</span><o:p></o:p></pre>
<pre><span style="color:black"> preserve their privacy or hide them from</span><o:p></o:p></pre>
<pre><span style="color:black">attack. To hide an</span><o:p></o:p></pre>
<pre><span style="color:black"> entity's real name, an alias may be used;</span><o:p></o:p></pre>
<pre><span style="color:black">for example, a financial</span><o:p></o:p></pre>
<pre><span style="color:black"> institution may assign account numbers.</span><o:p></o:p></pre>
<pre><span style="color:black">Parties to transactions</span><o:p></o:p></pre>
<pre><span style="color:black"> can thus remain relatively anonymous, but</span><o:p></o:p></pre>
<pre><span style="color:black">can also accept the</span><o:p></o:p></pre>
<pre><span style="color:black"> transactions as legitimate. Real names of</span><o:p></o:p></pre>
<pre><span style="color:black">the parties cannot be</span><o:p></o:p></pre>
<pre><span style="color:black"> easily determined by observers of the</span><o:p></o:p></pre>
<pre><span style="color:black">transactions, but an</span><o:p></o:p></pre>
<pre><span style="color:black"> authorized third party may be able to map</span><o:p></o:p></pre>
<pre><span style="color:black">an alias to a real name,</span><o:p></o:p></pre>
<pre><span style="color:black"> such as by presenting the institution with</span><o:p></o:p></pre>
<pre><span style="color:black">a court order. In other</span><o:p></o:p></pre>
<pre><span style="color:black"> applications, anonymous entities may be</span><o:p></o:p></pre>
<pre><span style="color:black">completely untraceable.</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<p class="MsoNormal"><span style="color:black">From
RFC 4949:</span><o:p></o:p></p>
<pre><span style="color:black">$ anonymous login</span><o:p></o:p></pre>
<pre><span style="color:black"> (I) An access control feature (actually,</span><o:p></o:p></pre>
<pre><span style="color:black">an access control</span><o:p></o:p></pre>
<pre><span style="color:black"> vulnerability) in many Internet hosts that</span><o:p></o:p></pre>
<pre><span style="color:black">enables users to gain</span><o:p></o:p></pre>
<pre><span style="color:black"> access to general-purpose or public</span><o:p></o:p></pre>
<pre><span style="color:black">services and resources of a</span><o:p></o:p></pre>
<pre><span style="color:black"> host (such as allowing any user to</span><o:p></o:p></pre>
<pre><span style="color:black">transfer data using FTP)</span><o:p></o:p></pre>
<pre><span style="color:black"> without having a pre-established,</span><o:p></o:p></pre>
<pre><span style="color:black">identity-specific account (i.e.,</span><o:p></o:p></pre>
<pre><span style="color:black"> user name and password). (See:</span><o:p></o:p></pre>
<pre><span style="color:black">anonymity.)</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<pre><span style="color:black"> Tutorial: This feature exposes a system to</span><o:p></o:p></pre>
<pre><span style="color:black">more threats than when</span><o:p></o:p></pre>
<pre><span style="color:black"> all the users are known, pre-registered</span><o:p></o:p></pre>
<pre><span style="color:black">entities that are</span><o:p></o:p></pre>
<pre><span style="color:black"> individually accountable for their</span><o:p></o:p></pre>
<pre><span style="color:black">actions. A user logs in using a</span><o:p></o:p></pre>
<pre><span style="color:black"> special, publicly known user name (e.g.,</span><o:p></o:p></pre>
<pre><span style="color:black">"anonymous", "guest", or</span><o:p></o:p></pre>
<pre><span style="color:black"> "ftp"). To use the public login</span><o:p></o:p></pre>
<pre><span style="color:black">name, the user is not required to</span><o:p></o:p></pre>
<pre><span style="color:black"> know a secret password and may not be</span><o:p></o:p></pre>
<pre><span style="color:black">required to input anything</span><o:p></o:p></pre>
<pre><span style="color:black"> at all except the name. In other cases, to</span><o:p></o:p></pre>
<pre><span style="color:black">complete the normal</span><o:p></o:p></pre>
<pre><span style="color:black"> sequence of steps in a login protocol, the</span><o:p></o:p></pre>
<pre><span style="color:black">system may require the</span><o:p></o:p></pre>
<pre><span style="color:black"> user to input a matching, publicly known</span><o:p></o:p></pre>
<pre><span style="color:black">password (such as</span><o:p></o:p></pre>
<pre><span style="color:black"> "anonymous") or may ask the user</span><o:p></o:p></pre>
<pre><span style="color:black">for an e-mail address or some</span><o:p></o:p></pre>
<pre><span style="color:black"> other arbitrary character string.</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<p class="MsoNormal"><span style="color:black">From
RFC 4949:</span><o:p></o:p></p>
<pre><span style="color:black">$ authenticate</span><o:p></o:p></pre>
<pre><span style="color:black"> (I) Verify (i.e., establish the truth of)</span><o:p></o:p></pre>
<pre><span style="color:black">an attribute value</span><o:p></o:p></pre>
<pre><span style="color:black"> claimed by or for a system entity or</span><o:p></o:p></pre>
<pre><span style="color:black">system resource. (See:</span><o:p></o:p></pre>
<pre><span style="color:black"> authentication, validate vs. verify,</span><o:p></o:p></pre>
<pre><span style="color:black">"relationship between data</span><o:p></o:p></pre>
<pre><span style="color:black"> integrity service and authentication</span><o:p></o:p></pre>
<pre><span style="color:black">services" under "data</span><o:p></o:p></pre>
<pre><span style="color:black"> integrity service".)</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<pre><span style="color:black"> Deprecated Usage: In general English</span><o:p></o:p></pre>
<pre><span style="color:black">usage, this term is used with</span><o:p></o:p></pre>
<pre><span style="color:black"> the meaning "to prove genuine"</span><o:p></o:p></pre>
<pre><span style="color:black">(e.g., an art expert authenticates</span><o:p></o:p></pre>
<pre><span style="color:black"> a Michelangelo painting); but IDOCs should</span><o:p></o:p></pre>
<pre><span style="color:black">restrict usage as</span><o:p></o:p></pre>
<pre><span style="color:black"> follows:</span><o:p></o:p></pre>
<pre><span style="color:black"> - IDOCs SHOULD NOT use this term to</span><o:p></o:p></pre>
<pre><span style="color:black">refer to proving or checking</span><o:p></o:p></pre>
<pre><span style="color:black"> that data has not been</span><o:p></o:p></pre>
<pre><span style="color:black">changed, destroyed, or lost in an</span><o:p></o:p></pre>
<pre><span style="color:black"> unauthorized or</span><o:p></o:p></pre>
<pre><span style="color:black">accidental manner. Instead, use "verify".</span><o:p></o:p></pre>
<pre><span style="color:black"> - IDOCs SHOULD NOT use this term to</span><o:p></o:p></pre>
<pre><span style="color:black">refer to proving the truth or</span><o:p></o:p></pre>
<pre><span style="color:black"> accuracy of a fact or</span><o:p></o:p></pre>
<pre><span style="color:black">value such as a digital signature.</span><o:p></o:p></pre>
<pre><span style="color:black"> Instead, use</span><o:p></o:p></pre>
<pre><span style="color:black">"verify".</span><o:p></o:p></pre>
<pre><span style="color:black"> - IDOCs SHOULD NOT use this term to</span><o:p></o:p></pre>
<pre><span style="color:black">refer to establishing the</span><o:p></o:p></pre>
<pre><span style="color:black"> soundness or correctness</span><o:p></o:p></pre>
<pre><span style="color:black">of a construct, such as a digital</span><o:p></o:p></pre>
<pre><span style="color:black"> certificate. Instead,</span><o:p></o:p></pre>
<pre><span style="color:black">use "validate".</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<p class="MsoNormal"><span style="color:black">From
RFC 4949:</span><o:p></o:p></p>
<pre><span style="color:black"> $ authentication</span><o:p></o:p></pre>
<pre><span style="color:black"> (I) The process of verifying a claim that</span><o:p></o:p></pre>
<pre><span style="color:black">a system entity or</span><o:p></o:p></pre>
<pre><span style="color:black"> system resource has a certain attribute</span><o:p></o:p></pre>
<pre><span style="color:black">value. (See: attribute,</span><o:p></o:p></pre>
<pre><span style="color:black"> authenticate, authentication exchange,</span><o:p></o:p></pre>
<pre><span style="color:black">authentication information,</span><o:p></o:p></pre>
<pre><span style="color:black"> credential, data origin authentication,</span><o:p></o:p></pre>
<pre><span style="color:black">peer entity</span><o:p></o:p></pre>
<pre><span style="color:black"> authentication, "relationship between</span><o:p></o:p></pre>
<pre><span style="color:black">data integrity service and</span><o:p></o:p></pre>
<pre><span style="color:black"> authentication services" under</span><o:p></o:p></pre>
<pre><span style="color:black">"data integrity service", simple</span><o:p></o:p></pre>
<pre><span style="color:black"> authentication, strong authentication,</span><o:p></o:p></pre>
<pre><span style="color:black">verification, X.509.)</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<pre><span style="color:black"> Tutorial: Security services frequently</span><o:p></o:p></pre>
<pre><span style="color:black">depend on authentication of</span><o:p></o:p></pre>
<pre><span style="color:black"> the identity of users, but authentication</span><o:p></o:p></pre>
<pre><span style="color:black">may involve any type of</span><o:p></o:p></pre>
<pre><span style="color:black"> attribute that is recognized by a system.</span><o:p></o:p></pre>
<pre><span style="color:black">A claim may be made by a</span><o:p></o:p></pre>
<pre><span style="color:black"> subject about itself (e.g., at login, a</span><o:p></o:p></pre>
<pre><span style="color:black">user typically asserts its</span><o:p></o:p></pre>
<pre><span style="color:black"> identity) or a claim may be made on behalf</span><o:p></o:p></pre>
<pre><span style="color:black">of a subject or object</span><o:p></o:p></pre>
<pre><span style="color:black"> by some other system entity (e.g., a user</span><o:p></o:p></pre>
<pre><span style="color:black">may claim that a data</span><o:p></o:p></pre>
<pre><span style="color:black"> object originates from a specific source,</span><o:p></o:p></pre>
<pre><span style="color:black">or that a data object is</span><o:p></o:p></pre>
<pre><span style="color:black"> classified at a specific security level).</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<pre><span style="color:black"> An authentication process consists of two</span><o:p></o:p></pre>
<pre><span style="color:black">basic steps:</span><o:p></o:p></pre>
<pre><span style="color:black"> - Identification step: Presenting</span><o:p></o:p></pre>
<pre><span style="color:black">the claimed attribute value</span><o:p></o:p></pre>
<pre><span style="color:black"> (e.g., a user</span><o:p></o:p></pre>
<pre><span style="color:black">identifier) to the authentication subsystem.</span><o:p></o:p></pre>
<pre><span style="color:black"> - Verification step: Presenting or</span><o:p></o:p></pre>
<pre><span style="color:black">generating authentication</span><o:p></o:p></pre>
<pre><span style="color:black"> information (e.g., a</span><o:p></o:p></pre>
<pre><span style="color:black">value signed with a private key) that acts</span><o:p></o:p></pre>
<pre><span style="color:black"> as evidence to prove the</span><o:p></o:p></pre>
<pre><span style="color:black">binding between the attribute and that</span><o:p></o:p></pre>
<pre><span style="color:black"> for which it is claimed.</span><o:p></o:p></pre>
<pre><span style="color:black">(See: verification.)</span><o:p></o:p></pre>
<pre><span style="color:black"> </span><o:p></o:p></pre>
<p class="MsoNormal"><span style="color:black">---------</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:10.5pt;color:black">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></span><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>