[gnso-rds-pdp-wg] authoritative

[Andrew Sullivan]

Hi,

On Sun, May 07, 2017 at 01:31:14PM -0400, Sam Lanfranco wrote:
> solutions. The key is that it is sourced in such a way that it is
> recognized as Data of Record.

I think that we mostly agree, but may be quibbling about "source".
What I think is that the DoR is just what it says it is: the data that
is recorded as having come from the original source of that data.
This tells us nothing about whether the original source lied.

That any given datum is in fact part of the DoR could be demontrated
in different ways, according to the technology in question.[1]

> Once there is agreement on what should be the Data of Record (the DoR
> fields) for (say) Thin Data, with (say) unconstrained access, there is
> then the question of which access window(s) [locations (SoR) or
> processes (blockchain)] provide DoR.

We agree about this, yes.

> As for "can be sure the data is
> correct", that is the validity issue and separate from the Data of
> Record and Sources of Record issues.

What _I_ at least meant in any locution like that was not "accurate
data" but "canonically correct".  That is, when you get the data out
of the system, how can you be sure that you have the DoR?  In whois,
the answer is, "You can't".  In RDAP, the answer is, "Did you use
HTTPS and follow the referrals in the answers you got?"  In some other
possible future system, the answer might be, "Did you check the
cryptographic signatures over the data elements you received, and do
those signatures validate?"  We completely agree that the question of
whether the data in the system is an accurate portrayal of the world
is a different question, and probably outside the scope of our task.

Best regards,

A

[1] Historically, we made the demonstration by source repository: we
asked the registry for data for which the registry had to be the
source, owing to the registry's position in the system.  So, whether a
name was registered, the identity of the entity whence came the
registration (the registrar), the name servers if any associated,
certain dates, and the status of the domain came from the registry.
All other data came from the registrar, which was the source for other
such data.  This was the "thin whois" model.  Unfortunately,
NICNAME/WHOIS predated the registry/registrar model, and the graft
onto whois was not too successful, so people decided to use a "thick
registry" model.  In this model, the DoR is nominally moved to the
registry, even though registrars may maintain a private copy of
registrant data that is not necessarily linked to the DoR.  Any
database geek will tell you that this is a good way to ensure data
synchronization problems, but it's what we have now.

RDAP as initially designed allows either of these models to be
followed, and it also allows authentication of the data source through
the use of https.  With a little ingenuity, RDAP could be extended to
provide cryptographic signatures over the data elements, thereby
permitting widespread caching without the threat of data corruption
(intentional or otherwise).  It's a live question whether the
engineering effort necessary would be worth it, though I confess I'm
pretty sceptical.


-- 
Andrew Sullivan
ajs at anvilwalrusden.com