[GNSO-Accuracy-ST] RrSG-Proposed Definition of Accuracy

Steve Crocker steve at shinkuro.com
Tue Oct 19 18:10:45 UTC 2021


Volker,

Thanks.  This is very helpful and also a bit different.  I think the policy
you are saying currently exists and that you want to continue is:

A registrar *must* perform operational validation and *may* choose to
perform identity validation.

In our notation, this is precisely expressed as V2..V3. i.e.  V2 or V3.
Further, if the ICANN policy is V2..V3, an individual registrar is free to
set its own policy to be V2, V3, or V2..V3.  Expressing this in words, an
individual registrar may choose to always do operational validation, may
choose to always do identity validation, or may choose to do operational
validation on some registrations and identity validation on other
registrations.

As I said previously, I'm not arguing in favor of any particular policy;
I'm just trying for precision and consistency across the documents.

Steve




On Tue, Oct 19, 2021 at 1:34 PM Volker Greimann <
volker.greimann at centralnic.com> wrote:

> Hi Steve,
>
> being one of the negotiators of the RrSG team for the 2013 RAA, I can shed
> a bit of light on that section:
> IIRC, originally ICANN wanted an automatic suspension in case the
> verification failed (no response trigger was received). We pushed back on
> that, citing how this may lead to problems for important domain names due
> to clerical oversights within the registrant organizations, for example
> after transfers. The compromise we ended up with that instead of automatic
> suspension, the registrar may first try to clear up the issue with their
> customer, if deemed necessary. Most registrars suspend right away, but
> some, like corporate service registrars will usually verify the details
> with their customers. This was intended only as an "out" of the automated
> suspension, not as an obligation to verify.
>
> Best,
>
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> *KEY-SYSTEMS GMBH*
>
> T: +49 6894 9396901
> M: +49 6894 9396851
> F: +49 6894 9396851
> W: www.key-systems.net
>
> Key-Systems GmbH is a company registered at the local court of
> Saarbruecken, Germany with the registration no. HR B 18835
> CEO: Oliver Fries and Robert Birkner
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
> England and Wales with company number 8576358.
>
> This email and any files transmitted are confidential and intended only
> for the person(s) directly addressed. If you are not the intended
> recipient, any use, copying, transmission, distribution, or other forms of
> dissemination is strictly prohibited. If you have received this email in
> error, please notify the sender immediately and permanently delete this
> email with any files that may be attached.
>
>
> On Tue, Oct 19, 2021 at 7:21 PM Steve Crocker <steve at shinkuro.com> wrote:
>
>> Volker and Sarah,
>>
>> I think you are in agreement that you do check whether email or phone
>> number is operational and you do *not* check whether either actually
>> reaches the person.  And I agree the terms operational/operable
>> validation/verification correctly specifies this.  The only piece of this
>> puzzle that seems inconsistent is section f, particularly the last
>> paragraph:
>>
>> In either case, if Registrar does not receive an affirmative response
>> from the Registered Name Holder, Registrar shall either verify the
>> applicable contact information manually or suspend the registration, until
>> such time as Registrar has verified the applicable contact information. If
>> Registrar does not receive an affirmative response from the Account Holder,
>> Registrar shall verify the applicable contact information manually, but is
>> not required to suspend any registration.
>>
>>  I'm not taking a position as to whether the registrar should or should
>> not use a higher level of verification.  I'm only focused here on
>> consistency of the relevant documents.
>>
>>
>> Steve
>>
>>
>>
>> On Tue, Oct 19, 2021 at 1:15 PM Volker Greimann <
>> volker.greimann at centralnic.com> wrote:
>>
>>> Hi Steve,
>>>
>>> no, the Spec does not require identity verification. The requirement is
>>> that the email address or phone number is functional and the recipient
>>> provides a trigger-response, but it does not require any verification of
>>> identity who is providing this response. So one could argue that the
>>> operational definition is broader than that in SAC 058, but on the other
>>> hand we did not look at SAC 058 when we drafted the language of the RAA.
>>> Note that the RAA speaks of "verification" here, not "validation" as the
>>> SAC does..
>>>
>>> Ultimately, all that is checked is the operationality (can the email
>>> address receive messages that are being read?), but that is a far way off
>>> from actual identity validation.
>>>
>>> Best,
>>>
>>> --
>>> Volker A. Greimann
>>> General Counsel and Policy Manager
>>> *KEY-SYSTEMS GMBH*
>>>
>>> T: +49 6894 9396901
>>> M: +49 6894 9396851
>>> F: +49 6894 9396851
>>> W: www.key-systems.net
>>>
>>> Key-Systems GmbH is a company registered at the local court of
>>> Saarbruecken, Germany with the registration no. HR B 18835
>>> CEO: Oliver Fries and Robert Birkner
>>>
>>> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
>>> England and Wales with company number 8576358.
>>>
>>> This email and any files transmitted are confidential and intended only
>>> for the person(s) directly addressed. If you are not the intended
>>> recipient, any use, copying, transmission, distribution, or other forms of
>>> dissemination is strictly prohibited. If you have received this email in
>>> error, please notify the sender immediately and permanently delete this
>>> email with any files that may be attached.
>>>
>>>
>>> On Tue, Oct 19, 2021 at 6:55 PM Steve Crocker <steve at shinkuro.com>
>>> wrote:
>>>
>>>> Sarah,
>>>>
>>>> Doesn't section f of the Whois Accuracy Specification require *identity
>>>> validation*, not just *operational (operable) validation*?
>>>>
>>>> If the RrSG is proposing *operational validation*, this seems to me a
>>>> weakening of the current validation requirement and would not be consistent
>>>> with section f.  On the other hand, if the RrSG is proposing validation
>>>> consistent with section f, the terminology *identity validation* would
>>>> be consistent.
>>>>
>>>> Here's the text of section f:
>>>>
>>>> f. Verify:
>>>>
>>>>
>>>>    1. the email address of the Registered Name Holder (and, if
>>>>    different, the Account Holder) by sending an email requiring an affirmative
>>>>    response through a tool-based authentication method such as providing a
>>>>    unique code that must be returned in a manner designated by the Registrar,
>>>>    or
>>>>
>>>>    2. the telephone number of the Registered Name Holder (and, if
>>>>    different, the Account Holder) by either (A) calling or sending an SMS to
>>>>    the Registered Name Holder's telephone number providing a unique code that
>>>>    must be returned in a manner designated by the Registrar, or (B) calling
>>>>    the Registered Name Holder's telephone number and requiring the Registered
>>>>    Name Holder to provide a unique code that was sent to the Registered Name
>>>>    Holder via web, email or postal mail.
>>>>
>>>> In either case, if Registrar does not receive an affirmative response
>>>> from the Registered Name Holder, Registrar shall either verify the
>>>> applicable contact information manually or suspend the registration, until
>>>> such time as Registrar has verified the applicable contact information. If
>>>> Registrar does not receive an affirmative response from the Account Holder,
>>>> Registrar shall verify the applicable contact information manually, but is
>>>> not required to suspend any registration.
>>>>
>>>>
>>>> In SAC 058, the following definitions are provided:
>>>>
>>>> *Operational Validation* refers to the assessment of data for their
>>>> intended use in their routine functions. Examples of operational validation
>>>> include 1) checking that an email address or phone number can receive email
>>>> or phone calls; 2) checking that a postal address can receive postal mail;
>>>> 3) checking that the data entered are self-consistent, i.e. that all data
>>>> are logically consistent with all other data. It is expected that many
>>>> operational validation checks would be automated and some could be executed
>>>> inline with a registration process.
>>>>
>>>> *Identity validation* refers to the assessment that the data
>>>> corresponds to the real world identity of the entity. It involves checking
>>>> that a data item correctly represents the real world identity for the
>>>> registrant. In general, identity validation checks are expected to require
>>>> some manual intervention.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>>>> On Tue, Oct 19, 2021 at 8:50 AM Sarah Wyld <swyld at tucows.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> The RrSG members of the Accuracy Scoping team propose the following
>>>>> definition of “accuracy” for domain name registration data, as per our
>>>>> homework assignment:
>>>>>
>>>>> *"Accuracy shall be strictly defined as syntactical accuracy of the
>>>>> registration data elements provided by the Registered Name Holder as well
>>>>> as the operational accuracy of either the telephone number or the email
>>>>> address."*
>>>>>
>>>>> To be determined to be *syntactically accurate*, the contact must
>>>>> satisfy all requirements for validity (see Whois Accuracy Program
>>>>> Specification
>>>>> <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy>
>>>>> Sections 1b-d). E.g. for email addresses, all characters must be
>>>>> permissible, the “@” symbol is required, there must be characters before
>>>>> the “@” symbol (the “local” component), there must be a valid top-level
>>>>> domain at the end, and there must be a valid domain after the “@” symbol,
>>>>> but before a “.” and the valid top-level domain.
>>>>>
>>>>> To be determined to be *operably accurate*, the contact must be
>>>>> operable as defined in the Whois Accuracy Program Specification
>>>>> <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy>
>>>>> Section f; in other words, the email must be deliverable, the telephone
>>>>> number has to connect without an error message such as that the number is
>>>>> invalid or disconnected, and the postal address must be mailable.
>>>>>
>>>>> The RAA currently requires validation of syntactical accuracy and
>>>>> verification of operational accuracy for either email or phone.
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Sarah Wyld*, CIPP/E
>>>>>
>>>>>
>>>>>
>>>>> Policy & Privacy Manager
>>>>>
>>>>> Pronouns: she/they
>>>>>
>>>>>
>>>>>
>>>>> swyld at tucows.com
>>>>>
>>>>> +1.416 535 0123 Ext. 1392
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> GNSO-Accuracy-ST mailing list
>>>>> GNSO-Accuracy-ST at icann.org
>>>>> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>>>>>
>>>>> _______________________________________________
>>>>> By submitting your personal data, you consent to the processing of
>>>>> your personal data for purposes of subscribing to this mailing list
>>>>> accordance with the ICANN Privacy Policy (
>>>>> https://www.icann.org/privacy/policy) and the website Terms of
>>>>> Service (https://www.icann.org/privacy/tos). You can visit the
>>>>> Mailman link above to change your membership status or configuration,
>>>>> including unsubscribing, setting digest-style delivery or disabling
>>>>> delivery altogether (e.g., for a vacation), and so on.
>>>>
>>>> _______________________________________________
>>>> GNSO-Accuracy-ST mailing list
>>>> GNSO-Accuracy-ST at icann.org
>>>> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>>>>
>>>> _______________________________________________
>>>> By submitting your personal data, you consent to the processing of your
>>>> personal data for purposes of subscribing to this mailing list accordance
>>>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy)
>>>> and the website Terms of Service (https://www.icann.org/privacy/tos).
>>>> You can visit the Mailman link above to change your membership status or
>>>> configuration, including unsubscribing, setting digest-style delivery or
>>>> disabling delivery altogether (e.g., for a vacation), and so on.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211019/ef975fc5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 66DD891F1CD140B8B082E775A55F2328[15001114917].png
Type: image/png
Size: 3031 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211019/ef975fc5/66DD891F1CD140B8B082E775A55F232815001114917-0001.png>


More information about the GNSO-Accuracy-ST mailing list