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

[Andrew Sullivan]

On Sat, Jul 16, 2016 at 01:12:30AM -0400, Stephanie Perrin wrote:
> images of video tapes that have not been used in 15 years).  To be clear, we
> need to talk about control of data elements.

I agree (these are the same as "datum" in the questions I asked -- the
individual elements of a set of data).

> If I understand RDAP correctly, it would permit duly authorized data access
> from anywhere, to elements that could be scattered.

In principle, it could.

> current data mining techniques.  The problem, as I see it, and I beg to be
> corrected if I am wrong, is how do we manage a remote authorization scheme
> to individual data elements, if indeed some data is held by the registrar,
> some by the registry, and some (outside ICANN's remit, but an answer to LEA
> demands) by the ISP?

This is a great question.

RDAP itself does not actually answer this, because RDAP just uses
http(s).  The idea in the design was exactly that we could then re-use
any authentication and authorization mechanisms that http(s) offers,
and so if a new one was invented we'd get that benefit too.  (All good
designs proceed from a basic laziness: don't re-invent something if
you can just re-use something others have already got working.)

The initial answer is just basic http authentication, and that would
require each to-be-authenticated individual to get such authentication
logins with everyone providing RDS, which would be awful.  So that's
not actually the plan.

Scott Hollenbeck, who is participating in this WG, has a nice draft
that'll probably see some discussion at the IETF meeting in Berlin
next week
(https://tools.ietf.org/html/draft-hollenbeck-regext-rdap-openid-00#ref-OIDCC).
It's a way of using RDAP with OpenID Connect, which is a federated
authentication and authorization mechanism.  (It's really intended to
provide an identity layer on top of OAuth.)  I'm waving away some
details and distinctions, but this is the sort of thing that you use
when you "sign in using Facebook" or "sign in using Google" or
whatever.

Using this sort of thing, you could have one credential that various
RDS operators would accept.  Once you're authenticated, the credential
would continue to work across referrals from one RDS to another (using
RDAP), so that the _user_ experience is of a single monolithic system
while the _technical_ operation is of a distributed system.  Moreover,
individual RDS operators could use different policies based on local
law to provide the kinds of responses appropriate to the legal
conditions under which they operate.  This would of course mean that
registrations in some jurisdictions might release more information
than others, but that's consistent with the legal obligations and
norms that arise from having multiple jurisdictions in the first place.

Now, there are important details in the operation of any such
federated identity system, and questions we'd have to ask about how
the vetting process for identification would work and whether we'd
need multiple additional tokens (for instance, an identity presented
with an id of a subpoena might have different qualifications than an
identity without such a subpoena).  That's all policy that would need
to be developed, but it would all be policy that could avoid
specifying details of technical implementations, which would be an
improvement over historic whois policy :)

If any of that is not clear, or if we need to develop some more
detailed tutorial-like info for participants here to read offline or
something, I hope people will let me know.  We really do now have the
technlogy to enable quite fine policy distinctions, and I think that
basic fact is useful for our future deliberations.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com