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

[David Cake]

IN general, a great big +1 to everything Andrew says here. I would add that, while some of this is interesting to keep in mind, these details are mostly not very relevant to phase 1 work IMO, though they may become quite important in phase 2 or phase 3. 

Http(s) as a transport protocol for RDAP serves, and there are quite a few technical options that can be used via https that give us greatly increased flexibility in the policy options we can offer (though we could also choose not to use those options, and advise the use of the new RDAP protocol with the old RDS system is sufficient, which ICANN is pursuing in the mean time, which provides several advantages such as the improved of data confidentiality). 
The tiered access available is probably the biggest issue relevant to phase 1 of this working group, but in later phases RDAPs ability for seamless referral to other registries may well become significant, for example. 

I think there is some conflation going on here of the authentication provided by https, the uses of that authentication within RDAP, and the policy consequences of that authentication. The RDAP protocol itself can only authenticate that a user is probably who they say they are, and return results based on that. But the decisions about what an RDAP server should return in response to a particular authenticated request are an issue for policy development. Its worth noting that RDAP does have some features that are relevant to our policy work generally, and may well come up in phase 2 or 3 work, such as the ability to indicate within the protocol that particular data elements have been made private, redacted, obscured, or registered by a proxy. 

Its also worth noting that if simple https authentication is found not to be useful for some reason, Andrew has already discussed some of the potential authentication mechanisms that are not required, but are fully permitted, for RDAP. Mentioned in the RFC are OAuth, OpenID, Security Assertion Markup Language(SAML), and mechanisms based on Certification Authority (CA), but that is not an exhaustive list. When it comes to authentication options for RDAP, potentially the options are wide open (as Andrew says, technically possible, but possibly expensive if it requires software development). And knowing that the options are wide open is probably all we need to do for now. 

	David


> On 20 Jul 2016, at 6:08 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
> 
> 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