[TSG-Access-RD] Proposed Assumption Additions

[Hollenbeck, Scott]

> -----Original Message-----
> From: Andrew Newton <andy at hxr.us>
> Sent: Tuesday, December 18, 2018 3:12 PM
> To: Hollenbeck, Scott <shollenbeck at verisign.com>
> Cc: Francisco Arias <francisco.arias at icann.org>; tsg-access-rd at icann.org
> Subject: [EXTERNAL] Re: [TSG-Access-RD] Proposed Assumption Additions
>
> On Tue, Dec 18, 2018 at 2:02 PM Hollenbeck, Scott via TSG-Access-RD <tsg-
> access-rd at icann.org> wrote:
> >
> > The problem with the core RFCs is that they don’t include the functionality
> we need for the kind of authorization that we’re talking about. That’s why I
> wrote my federated authentication draft. It includes features that address a
> number of questions proposed in the charter.
>
> I agree that we cannot reach a conclusion relying on only what is defined in
> the core RFCs. Perhaps we should put in the following scoping text:
>
> 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.

This works.

> That beginning qualifier is in there because I don't think specifying audit log
> formats, etc... is an RDAP thing.
>
> >
> > I would agree with that amendment to #7. I’m not comfortable with
> assuming that practices implemented to deal with the limitations of WHOIS
> should be continued.
>
> Because I'm still not clear on this, can you provide an example?

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.

Scott