[TSG-Access-RD] Proposed Assumption Additions

[Hollenbeck, Scott]

> -----Original Message-----
> From: Andrew Newton <andy at hxr.us>
> Sent: Wednesday, December 19, 2018 10:38 AM
> To: Hollenbeck, Scott <shollenbeck at verisign.com>
> Cc: Francisco Arias <francisco.arias at icann.org>; tsg-access-rd at icann.org
> Subject: [EXTERNAL] Re: Re: [TSG-Access-RD] Proposed Assumption
> Additions
>
> 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.

I suppose. I'm trying to capture what I think is an ICANN assumption, so if someone who is familiar with what ICANN is assuming with respect to the temp spec and its application to RDAP could weigh in it might be the fastest way to come to closure.

Scott