[TSG-Access-RD] Proposed Assumption Additions

[Andrew Newton]

On Tue, Dec 18, 2018 at 5:37 PM Hollenbeck, Scott
<shollenbeck at verisign.com> wrote:
>

> Referring to the temp spec:
>
> https://www.icann.org/resources/pages/gtld-registration-data-specs-en/#temp-spec
>
> Section 2 of Appendix A talks about requirements for data redaction, or obfuscation, by registries and registrars. They're currently implemented for WHOIS in a manner that has registries and registrars obfuscating data elements to ensure that output is GDPR compliant. Section 4 talks about requests for access to non-public data, with those requests currently being serviced by registries and registrars. The current implementation is what it is because (among other reasons) WHOIS has no facilities for client identification, authentication, or authorization, and something needed to be done right away due to dates for GDPR enforcement. We're doing this whole redaction
>
> As I understand what was said on the call today today, we're being asked to assume that the way things are being done today with WHOIS is desired to continue, modulo ICANN fielding requests for access to non-public data using RDAP and the contracted parties responding to requests for public data using RDAP with continued redaction of non-public data.
>
> The point I'm trying to make is that I don't want to do things a certain way because *WHOIS* has limitations. I would rather we start with whatever the underlying requirement is (as Francisco said via email, perhaps that means "assume that redaction of non-public data will be required for unauthorized users"), and have our task be to see how that requirement can be met with RDAP. I don't like the idea of requirements that boil down to "make RDAP work like WHOIS", or "continue WHOIS work-arounds".
>
> So, is this reasonable for 6 and 7?
>
> 6. For the purposes of access to non-public data, scope is limited to RDAP, extension mechanisms to RDAP as defined by RFC 7480, 7481, 7482, and 7483, and other mechanisms an RDAP client implementer would find "natural" to implement.
>
> 7. Redaction of certain fields will continue beyond the temporary specification.

I agree with the spirit of what you saying, but perhaps item 7 is not
specific enough. Do you mean the redaction of fields with regards to
unauthenticated queries? If so, what about:

7. It is expected that RDAP services will answer queries from
unathenticated sources, and when doing so will follow policies whereby
data is redacted such as those listed in the temporary specification.

-andy