[gnso-rds-pdp-wg] On "authoritative" (was: Off the Simplicity Wall or Simply Off the Wall)

[Andrew Sullivan]

Hi,

If I've done this right, this will be a new thread in the mailing
list; but I'm still responding to something below and trying to pull
out one new topic.

TL;DR: we need some other term than "authoritative data".  (There are
some ideas for what they should be, but I'm waiting for David Cake's
message to post mine.)  The basic idea is that we need to capture the
sense of "data from the source repository" somehow.  Reasons below.

On Tue, Apr 25, 2017 at 04:36:43PM -0400, Sam Lanfranco wrote:

> Might there be some merit in defining “authoritative data” simply as:
> verified (as best the registrar can); at a designated repository; and with
> defined terms of access (Open, Gated, Closed).

No, or at least that's not what we were trying to do with the previous
discussion.  But your list is quite helpful.

The little sub-group that was working on "authoritative" foundered on
the basic problem that the data-theoretic sense of "authoritative
data" is quite clear, but unfortunately overloaded in the legal sense
of the same term.  In data-theoretic terms, "authoritative data" means
approximately "the data from a source that is an official repository
for that data".  The Ministry of Transportation of Ontario is the
authoritative source for my driver's license status.  There are
specific DNS servers that can tell you the correct IP address for
mx4.yitter.info.  And the registry operated by CIRA is authoritative
for the data associated with crankycanuck.ca.  (Yes, those are both
domains that I control.  Geeks!)

The problem, I am informed, is that for lawyers "authoritative" also
means something close to "true fact".  The idea here is that
authoritative data is not only the data from some official repository,
but _also_ that it is somehow the correct data with respect to the
world.

In the data-theoretic sense, we can distinguish among three things.
One is the _authoritative_ data -- that is, that data that comes from
the data authority (the relevant database or whatever).  When you get
the thin data from the Verisign whois servers today, you are getting
this kind of data, and when you get the results of

    dig @ns4.p13.dynect.net -t NS internetcarrot.org

you are also getting this kind of data.

The second thing is _provably authentic_ data.  This is data that you
can be sure you may use even if you can't ask the authoritative
source.  For instance, if you issue

    dig @ns4.p13.dynect.net -t NS internetcarrot.org +dnssec

you get that kind of data.  In the whois today we do not have this,
and RDAP does not have by default mechanisms for this (but I suppose
-- not "think", please note! -- it'd be fairly easy to add it).

The third thing is _verified_ data.  This is data that has undergone
some sort of additional check to make sure not only that the data is
correct in the source repository, but that the data actually
represents some state of affairs somewhere.  The MTO's information
about my driver's license is not only about whether it is valid: it
also ensures that I actually am the person pictured.  Note that it is
not impossible to fake this sort of thing, but it is harder than
simply entering bad data into the authoritative repository.  On the
Internet, we often see efforts along these lines in the so-called
"Extended Validation" X.509 certificate that is used on certain TLS
("SSL") websites.  In theory, it provides additional evidence that the
X.509 certificate is in fact controlled by the legal entity that
controls the domain name.  As a matter of practice, EV certificates
have a somewhat inglorious history, but they are still an example of
"verified data" even in the cases where the verification has failed.

I think what we were looking for in the Copenhagen meeting is the
above sense(s) of "authoritative" and maybe "provably authentic".
Separate from that is the question of verified data, which I think
everyone agrees is important but that I, at least, think should not be
balled up with the other two issues.

I hope this helps make that issue a little clearer.

Best regards,

A
-- 
Andrew Sullivan
ajs at anvilwalrusden.com