[gnso-rds-pdp-wg] On "authoritative"

Fri Apr 28 10:07:25 UTC 2017

Indeed, this term needs a definition to allow us to continue the discussion:

Do we mean atuhritative as:

"Can legally be relied upon by third parties even if incorrect." This is 
the case for example with the German trade register. The data listed 
within can be accepted as correct and relied upon, meaning that an 
authorized signatory listed there for a company can still bind the 
company even though he has already been stripped of his authority 
internally.

or do we mean it to say:

"When in doubt, this is the source most probably to give the right 
result, but you cannot always rely upon that data".

V.

Am 27.04.2017 um 19:56 schrieb David Cake:
> I think the problem is actually a bit more complex than Andrew suggests.
> Some lawyers may indeed use the term authoritative to mean ‘true and correct’, but it can also be used in the sense of ‘having authority’ which is a more complex issue, and makes it more problematic.
> The Ministry of Transportation of Ontario is not just the best source for information on Andrew’s drivers licence status, it also has authority to decide that status. This is a different meaning again - it is certainly possible for there to be a source of information that has authority, but that has not made that data available (perhaps because it has not made a decision itself as to what the data should be, or because it has authority to determie the data but is not always the original source). And it is this additional meaning that adds legal confusion.
> Which only confuses the issue further, and convinces me we should avoid the term outside a strict technical context.
>
> David
>
>> On 26 Apr 2017, at 11:22 am, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
>>
>> 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
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.