<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Interesting, but I am not sure this is ultimately what we should
be looking for for one simple reason. This proposed implementation
apparently does not provide for any differentiation between access
levels except for the three authentification levels. <br>
</p>
<p>So once one obtains and advanced authentification, one can access
all data in the database, which I would consider insufficient
differentiation. Access should be further scecialized on a "need
to know" and "right to know" basis. For example, should a
certified and authentificated law enforcement agency have access
to all registrant data or only to registrant data that applies to
their jurisdiction (plus maybe an identifier that details which
jurisdiction applies to a data set that agency cannot access).</p>
<p>Similarly, would a IP rights holder have access to all data or
only to just enough data needed to achieve their goal, which would
likely be to contact the registrant?</p>
<p>In other words, the access level scheme should differentiate
between levels of access much more and restrict that access to
those with a right to access or a legitimate need to access
without overstepping legal or jurisdictional boundaries. <br>
</p>
<p>This proposed implementation it too simplistic.<br>
</p>
<p>Best,</p>
<p>volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 10.12.2016 um 06:35 schrieb Carlton
Samuels:<br>
</div>
<blockquote
cite="mid:CAOZQb9SDbxnhR7U_OZPBSHBo0WYLaUcjss2PAKQRaWMsxB46RQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small">Way to go Scott!</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><br>
</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small">-Carlton</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><br>
==============================<br>
<i><font face="comic sans ms, sans-serif">Carlton A
Samuels</font></i><br>
<font face="comic sans ms, sans-serif"><i>Mobile:
876-818-1799<br>
<font color="#33CC00">Strategy, Planning,
Governance, Assessment & Turnaround</font></i></font><br>
=============================</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Fri, Dec 9, 2016 at 7:25 AM,
Hollenbeck, Scott <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:shollenbeck@verisign.com" target="_blank">shollenbeck@verisign.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I like to
explore how systems might work by putting thoughts into
action with running code. I have a working implementation of
RDAP with client authentication that might be useful in
helping people see how some of our data element and data
access ideas might actually work in practice. The
implementation currently includes three levels of client/end
user access:<br>
<br>
1. Unauthenticated: a client that does not provide any
authentication information to the server will receive
responses that include very little information beyond what
is currently available from the DNS.<br>
<br>
2. Authenticated Basic: a client that authenticates using an
easily acquired, open credential (like a Gmail or Hotmail
email account) will receive additional information (like
registration dates and domain status values), but no
personally identifiable contact information.<br>
<br>
3. Authenticated Advanced: a client who authenticates using
a specialized identity provider (we currently support
providers implemented by Verisign Labs, CZNIC and an
interoperability test provider) will receive full access to
all available data. The purpose of the query can be
identified and shared with the server operator, who can use
the client-supplied identity information to make
fine-grained access control decisions.<br>
<br>
A web-based front-end to the service can be found here:<br>
<br>
<a moz-do-not-send="true"
href="https://rdap.verisignlabs.com/" rel="noreferrer"
target="_blank">https://rdap.verisignlabs.com/</a><br>
<br>
We currently support entity (contact), name server, and
domain lookup and search queries for the .cc and .tv ccTLDs.
You can use the <a moz-do-not-send="true"
href="http://nic.tv" rel="noreferrer" target="_blank">nic.tv</a>
domain for basic exploration. Try it out with your Gmail
address using the "Authenticate" button to see the
difference between authenticated and unauthenticated
behaviors.<br>
<br>
A word of warning: RDAP responses are JSON-encoded and
*very* character-dense. It may help to have a JSON pretty
printer plugin installed in your browser.<br>
<br>
Anyone who wants a test account from Verisign Labs for
advanced authenticated access can have one for the asking.
Please reply directly to me and I'll make sure you get set
up.<br>
<br>
A logical conclusion should we decide to pursue this line of
thinking is that there will be a need for identity providers
who are able to issue user credentials to people who belong
to specific communities of interest. Policies will need to
be developed to determine which communities of interest get
access to which data elements.<br>
<br>
Scott<br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
</div>
<br>
</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>