<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Same here. That time is just not workable for me.<br>
</p>
<br>
<div class="moz-cite-prefix">Am 16.05.2017 um 02:13 schrieb Greg
Aaron:<br>
</div>
<blockquote
cite="mid:BN6PR13MB18437AE96C3CCD5B8D255C7FD9E60@BN6PR13MB1843.namprd13.prod.outlook.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-compose;
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"><a moz-do-not-send="true"
name="_MailEndCompose">Thanks you, Lisa.<o:p></o:p></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">I
will be unable to make the next meeting because the 05:00
UTC meeting time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Based
on last week’s meeting, I I think we are aiming for
something like:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">"Thin
data elements must be accessible to anonymous requestors,
without authentication.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">If
we say:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">"Thin
data elements must be accessible without requestor
authentication"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">then
that means consumers of registration data might or might not
be anonymous.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">So
I also suggest it be made explicit that access to
registration data remain free, without charge.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">All
best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">--Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="font-size:10.0pt"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></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> Lisa Phifer
[<a class="moz-txt-link-freetext" 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 class="moz-txt-link-rfc2396E" href="mailto:gca@icginc.com"><gca@icginc.com></a>; Gomes, Chuck
<a class="moz-txt-link-rfc2396E" href="mailto:cgomes@verisign.com"><cgomes@verisign.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> Definitions: Authentication and Anonymity<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<pre> $ anonymity<o:p></o:p></pre>
<pre> (I) The condition of an identity being<o:p></o:p></pre>
<pre>unknown or concealed. (See:<o:p></o:p></pre>
<pre> alias, anonymizer, anonymous credential,<o:p></o:p></pre>
<pre>anonymous login,<o:p></o:p></pre>
<pre> identity, onion routing, persona<o:p></o:p></pre>
<pre>certificate. Compare: privacy.)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Tutorial: An application may require<o:p></o:p></pre>
<pre>security services that<o:p></o:p></pre>
<pre> maintain anonymity of users or other<o:p></o:p></pre>
<pre>system entities, perhaps to<o:p></o:p></pre>
<pre> preserve their privacy or hide them from<o:p></o:p></pre>
<pre>attack. To hide an<o:p></o:p></pre>
<pre> entity's real name, an alias may be used;<o:p></o:p></pre>
<pre>for example, a financial<o:p></o:p></pre>
<pre> institution may assign account numbers.<o:p></o:p></pre>
<pre>Parties to transactions<o:p></o:p></pre>
<pre> can thus remain relatively anonymous, but<o:p></o:p></pre>
<pre>can also accept the<o:p></o:p></pre>
<pre> transactions as legitimate. Real names of<o:p></o:p></pre>
<pre>the parties cannot be<o:p></o:p></pre>
<pre> easily determined by observers of the<o:p></o:p></pre>
<pre>transactions, but an<o:p></o:p></pre>
<pre> authorized third party may be able to map<o:p></o:p></pre>
<pre>an alias to a real name,<o:p></o:p></pre>
<pre> such as by presenting the institution with<o:p></o:p></pre>
<pre>a court order. In other<o:p></o:p></pre>
<pre> applications, anonymous entities may be<o:p></o:p></pre>
<pre>completely untraceable.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal">From RFC 4949:<o:p></o:p></p>
<pre>$ anonymous login<o:p></o:p></pre>
<pre> (I) An access control feature (actually,<o:p></o:p></pre>
<pre>an access control<o:p></o:p></pre>
<pre> vulnerability) in many Internet hosts that<o:p></o:p></pre>
<pre>enables users to gain<o:p></o:p></pre>
<pre> access to general-purpose or public<o:p></o:p></pre>
<pre>services and resources of a<o:p></o:p></pre>
<pre> host (such as allowing any user to<o:p></o:p></pre>
<pre>transfer data using FTP)<o:p></o:p></pre>
<pre> without having a pre-established,<o:p></o:p></pre>
<pre>identity-specific account (i.e.,<o:p></o:p></pre>
<pre> user name and password). (See:<o:p></o:p></pre>
<pre>anonymity.)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Tutorial: This feature exposes a system to<o:p></o:p></pre>
<pre>more threats than when<o:p></o:p></pre>
<pre> all the users are known, pre-registered<o:p></o:p></pre>
<pre>entities that are<o:p></o:p></pre>
<pre> individually accountable for their<o:p></o:p></pre>
<pre>actions. A user logs in using a<o:p></o:p></pre>
<pre> special, publicly known user name (e.g.,<o:p></o:p></pre>
<pre>"anonymous", "guest", or<o:p></o:p></pre>
<pre> "ftp"). To use the public login<o:p></o:p></pre>
<pre>name, the user is not required to<o:p></o:p></pre>
<pre> know a secret password and may not be<o:p></o:p></pre>
<pre>required to input anything<o:p></o:p></pre>
<pre> at all except the name. In other cases, to<o:p></o:p></pre>
<pre>complete the normal<o:p></o:p></pre>
<pre> sequence of steps in a login protocol, the<o:p></o:p></pre>
<pre>system may require the<o:p></o:p></pre>
<pre> user to input a matching, publicly known<o:p></o:p></pre>
<pre>password (such as<o:p></o:p></pre>
<pre> "anonymous") or may ask the user<o:p></o:p></pre>
<pre>for an e-mail address or some<o:p></o:p></pre>
<pre> other arbitrary character string.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal">From RFC 4949:<o:p></o:p></p>
<pre>$ authenticate<o:p></o:p></pre>
<pre> (I) Verify (i.e., establish the truth of)<o:p></o:p></pre>
<pre>an attribute value<o:p></o:p></pre>
<pre> claimed by or for a system entity or<o:p></o:p></pre>
<pre>system resource. (See:<o:p></o:p></pre>
<pre> authentication, validate vs. verify,<o:p></o:p></pre>
<pre>"relationship between data<o:p></o:p></pre>
<pre> integrity service and authentication<o:p></o:p></pre>
<pre>services" under "data<o:p></o:p></pre>
<pre> integrity service".)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Deprecated Usage: In general English<o:p></o:p></pre>
<pre>usage, this term is used with<o:p></o:p></pre>
<pre> the meaning "to prove genuine"<o:p></o:p></pre>
<pre>(e.g., an art expert authenticates<o:p></o:p></pre>
<pre> a Michelangelo painting); but IDOCs should<o:p></o:p></pre>
<pre>restrict usage as<o:p></o:p></pre>
<pre> follows:<o:p></o:p></pre>
<pre> - IDOCs SHOULD NOT use this term to<o:p></o:p></pre>
<pre>refer to proving or checking<o:p></o:p></pre>
<pre> that data has not been<o:p></o:p></pre>
<pre>changed, destroyed, or lost in an<o:p></o:p></pre>
<pre> unauthorized or<o:p></o:p></pre>
<pre>accidental manner. Instead, use "verify".<o:p></o:p></pre>
<pre> - IDOCs SHOULD NOT use this term to<o:p></o:p></pre>
<pre>refer to proving the truth or<o:p></o:p></pre>
<pre> accuracy of a fact or<o:p></o:p></pre>
<pre>value such as a digital signature.<o:p></o:p></pre>
<pre> Instead, use<o:p></o:p></pre>
<pre>"verify".<o:p></o:p></pre>
<pre> - IDOCs SHOULD NOT use this term to<o:p></o:p></pre>
<pre>refer to establishing the<o:p></o:p></pre>
<pre> soundness or correctness<o:p></o:p></pre>
<pre>of a construct, such as a digital<o:p></o:p></pre>
<pre> certificate. Instead,<o:p></o:p></pre>
<pre>use "validate".<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal">From RFC 4949:<o:p></o:p></p>
<pre> $ authentication<o:p></o:p></pre>
<pre> (I) The process of verifying a claim that<o:p></o:p></pre>
<pre>a system entity or<o:p></o:p></pre>
<pre> system resource has a certain attribute<o:p></o:p></pre>
<pre>value. (See: attribute,<o:p></o:p></pre>
<pre> authenticate, authentication exchange,<o:p></o:p></pre>
<pre>authentication information,<o:p></o:p></pre>
<pre> credential, data origin authentication,<o:p></o:p></pre>
<pre>peer entity<o:p></o:p></pre>
<pre> authentication, "relationship between<o:p></o:p></pre>
<pre>data integrity service and<o:p></o:p></pre>
<pre> authentication services" under<o:p></o:p></pre>
<pre>"data integrity service", simple<o:p></o:p></pre>
<pre> authentication, strong authentication,<o:p></o:p></pre>
<pre>verification, X.509.)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Tutorial: Security services frequently<o:p></o:p></pre>
<pre>depend on authentication of<o:p></o:p></pre>
<pre> the identity of users, but authentication<o:p></o:p></pre>
<pre>may involve any type of<o:p></o:p></pre>
<pre> attribute that is recognized by a system.<o:p></o:p></pre>
<pre>A claim may be made by a<o:p></o:p></pre>
<pre> subject about itself (e.g., at login, a<o:p></o:p></pre>
<pre>user typically asserts its<o:p></o:p></pre>
<pre> identity) or a claim may be made on behalf<o:p></o:p></pre>
<pre>of a subject or object<o:p></o:p></pre>
<pre> by some other system entity (e.g., a user<o:p></o:p></pre>
<pre>may claim that a data<o:p></o:p></pre>
<pre> object originates from a specific source,<o:p></o:p></pre>
<pre>or that a data object is<o:p></o:p></pre>
<pre> classified at a specific security level).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> An authentication process consists of two<o:p></o:p></pre>
<pre>basic steps:<o:p></o:p></pre>
<pre> - Identification step: Presenting<o:p></o:p></pre>
<pre>the claimed attribute value<o:p></o:p></pre>
<pre> (e.g., a user<o:p></o:p></pre>
<pre>identifier) to the authentication subsystem.<o:p></o:p></pre>
<pre> - Verification step: Presenting or<o:p></o:p></pre>
<pre>generating authentication<o:p></o:p></pre>
<pre> information (e.g., a<o:p></o:p></pre>
<pre>value signed with a private key) that acts<o:p></o:p></pre>
<pre> as evidence to prove the<o:p></o:p></pre>
<pre>binding between the attribute and that<o:p></o:p></pre>
<pre> for which it is claimed.<o:p></o:p></pre>
<pre>(See: verification.)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal">---------<o:p></o:p></p>
</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>
<pre class="moz-signature" cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
</body>
</html>