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

[Andrew Sullivan]

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