<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body dir="auto">
<br>
<div>On Apr 13, 2018, at 3:28 PM, Rubens Kuhl <<a href="mailto:rubensk@nic.br">rubensk@nic.br</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">Em 13 de abr de 2018, à(s) 16:15:000, Hollenbeck, Scott <<a href="mailto:shollenbeck@verisign.com" class="">shollenbeck@verisign.com</a>> escreveu:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="" class="">
<blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
-----Original Message-----<br class="">
From: Accred-Model [<a href="mailto:accred-model-bounces@icann.org" class="">mailto:accred-model-bounces@icann.org</a>] On Behalf Of<br class="">
Rubens Kuhl<br class="">
Sent: Friday, April 13, 2018 2:57 PM<br class="">
To:<span class="Apple-converted-space"> </span><a href="mailto:accred-model@icann.org" class="">accred-model@icann.org</a><br class="">
Subject: [EXTERNAL] [Accred-Model] Token-based approach to WHOIS access<br class="">
<br class="">
<br class="">
Hi all.<br class="">
<br class="">
After reading the Article 29 WP letter to ICANN<br class="">
(<a href="awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-" class="">awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-</a><br class="">
11apr18-en.pdf), I started envisioning what process and system could<br class="">
achieve GDPR compliance. What I came to is a token-based system, which<br class="">
would work like this:<br class="">
- Every request is analyzed by a human at an "RDS Clearinghouse". Each<br class="">
request can be for a single data element (like "owner of domain X") or to<br class="">
multiple data elements (like "domains owned by the same owner of domain<br class="">
X"), but requests for multiple data elements are only foreseen to be<br class="">
processed by contracted parties with "Search WHOIS" contract requirements.<br class="">
- Clearinghouse issues a token with query parameters, data elements<br class="">
authorized for response, identity of authorized party, reason for<br class="">
authorization, validity (probably in the order of days), also informing<br class="">
which endpoint to go to.<br class="">
- Authorized party uses that token to access that endpoint, managed by the<br class="">
party with most data about that element (usually a registrar).<br class="">
<br class="">
Note that is not a replacement for credentialing; credentials would still<br class="">
be necessary to get tokens. This is also orthogonal to discussions like<br class="">
which use cases are legitimate or not, GDPR-compliant or not etc.; it's<br class="">
just a more granular approach to authorization that looks more inline with<br class="">
privacy-oriented guidelines including but not limited to GDPR.<br class="">
</blockquote>
<br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Rubens,
at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
</div>
Scott,
<div class=""><br class="">
</div>
<div class="">I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably
could be made to work like this. </div>
<div class="">And some level of asynchronous communications could even make way for a quick look human analysis. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Rubens</div>
</div>
</blockquote>
<br>
<div>I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search
for “draft Hollenbeck RDAP OpenID” using your favorite search engine.</div>
<div><br>
</div>
<div>Scott </div>
</body>
</html>