Re: [GNSO-Accuracy-ST] RrSG-Proposed Definition of Accuracy
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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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.
Hi Steve, Happy to discuss further on Thursday, but I do not agree that the verification requirements in section F (thanks for copying it into your email) are the same as identity validation. The requirement is to make sure that the email or phone works properly, to verify that it is operational. We don’t check IDs, and we should not start. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com +1.416 535 0123 Ext. 1392 From: Steve Crocker Sent: October 19, 2021 12:54 PM To: Sarah Wyld Cc: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] RrSG-Proposed Definition of Accuracy 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@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 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 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@tucows.com +1.416 535 0123 Ext. 1392 _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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.
Hi Steve, Happy to discuss further on Thursday, but I do not agree that the verification requirements in section F (thanks for copying it into your email) are the same as identity validation. The requirement is to make sure that the email or phone works properly, to verify that it is operational. We don’t check IDs, and we should not start. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com +1.416 535 0123 Ext. 1392 From: Steve Crocker Sent: October 19, 2021 12:54 PM To: Sarah Wyld Cc: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] RrSG-Proposed Definition of Accuracy 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@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 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 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@tucows.com +1.416 535 0123 Ext. 1392 _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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.
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@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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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@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.
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@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@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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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@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.
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@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@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@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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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@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.
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@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@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@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@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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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@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.
participants (3)
-
Sarah Wyld -
Steve Crocker -
Volker Greimann