[gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )

Gomes, Chuck cgomes at verisign.com
Wed Jul 20 12:51:57 UTC 2016


Let me start off by assuring Volker (and all) that we will get to ask these questions down the road if we decide that a next gen RDS is needed.  And let me also add that, as I recall, the EWG made specific recommendations for cases when authorized users of restricted RDS data use that data for unauthorized purposes; the purposes issue is a very critical one in the RDS Report and one we will need to deal with, probably in all three phases.

Chuck

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Wednesday, July 20, 2016 6:09 AM
To: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )

On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:
> my concern with re-using the mechaisms offered by http(s) is that to 
> my knowledge it does not support differentiated or tiered access.

I'm not sure this attends to how the layers work in this protocol.

Https in the case of RDAP is just the protocol by which you carry the bits.  RDAP is an application protocol.  So https provides the TLS-based authentication mechanism of the accessing application.  Once you have the TLS credential, your RDAP server is in a position to examine the presented credentials and make a decision about what data to return.  This is part of the RDAP server application.  But RDAP has the capability to do that _built in_ by virtue of having access to authentication credentials that are not available as part of the whois protocol.

> Say I am a Turkish "law enforcement official" (whatever that means in 
> these
> days) and have access to certain data fields because we decided that 
> this is the level of access given to law enforcement. I can now access 
> this level of information for anything. So we need not only 
> authentication, but also protection from abuse of such authenticated 
> users.  We need granulatity to be able to not only to say that user A 
> has access to information level B, but also ensure that this 
> information can only be requested for purpose C and prevent any access to the same information for abusive use D.

I think this conflates policies that are amenable to technical imposition, and policies that are not.

For a given authenticated user, that authenticated user has access to certain data.  The data fields in question are available to the user, and other data fields are not.  That's something that can be imposed
technically: for any login that meets the same profile, the restrictions in question yield the same access controls.

There is literally nothing technically possible to do about someone using data they obtain this way for purposes for which the data were not intended.  It may be that ICANN ought to have additional policies about what happens if someone uses data outside the scope that the data was supposed to be used -- the classic example is people using privileged information access to dig up info on former romantic partners.  Normally, the way we solve that is that we fire people who abuse their credentials when we catch them.  So, ICANN could have a policy about suspending credentials, similarly.

> If for example law enforcement has the ability to access certain 
> information based on a court order, we would have to ensure that this 
> access level can only be used if such a court order is present, 
> otherwise how to shoield users from abuse of the access we grant by policy?

It _might_ be possible to do something technical about one off cases like this.  For instance, it might be possible to create special-use permissions for data related to a specific kind of request -- say, for instance, some mechanism that allows communication of the terms of a subpoena so that the request can get access to data related to that subpoena, but can't re-use the credential for access to data that are unrelated to the case in question.  This sort of thing would probably require some development of the federated authentication systems we've talked about, and might be too complicated to be bothered implementing.  But it is not technically impossible, just expensive.

> I hope we will get to ask these questions further down the road and 
> find a workable solution to them. In the meantime, I just wanted to 
> note that authentication is not the solution, but only a step on the 
> way towards the solution. The solution must be broader.

Obviously, authentication isn't magic: you need to decide what to do on the basis of the credential that's presented.  But the general point is that, in the presence of authentication, you have a whole bunch of policy options that were simply not available with whois, because whois is too primitive a protocol.

Best regards,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg



More information about the gnso-rds-pdp-wg mailing list