Identity Proofing Clarity - Follow Up Homework
Hello All, I was reviewing my notes from yesterday's meeting as well as reviewing some of the previous email list exchanges between and I was hoping that my Registrar colleagues could provide a little clarity, especially Volker given his participation in the 2013 RAA negotiations. I believe what I have heard and read from my Registrar colleagues is that there is no "identity proofing" requirements in their contracts - accuracy is merely syntactical and operational. I apologizes in advance if I am mischaracterizing this and welcome any corrections. However, in Assignment #1, the follow excerpt from ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR states: [I]f the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint. So it appears based on this excerpt that ICANN Contractual Compliance does reserve some right to inquiry about the "identity" of the Registrant. Therefore, I believe potential clarifying questions to ICANN Org could might include: does ICANN Compliance believe that it has the ability to inquiry about the "identity" of a registrant? If so, what is the contractual basis of this authority. Finally, what are the numbers associated with these types of inquiries, e.g. percentage of overall accuracy complaints and raw numbers. Thoughts? Comments? Best regards, Michael
Hi Michael, all such investigations are based on a substantiated whois inaccuracy complaint where the complainant states that the registrant has provided false details. As this regards a potential violation of our registration agreement with the registrant we will investigate the identity of the registrant in this specific case only. The usual complaint is from the party listed in the registration record that they did not register the domain name in the first place or sold it a while ago and now found that the record was never updated by the old registrant. That said, aside from the investigation following a substantiated inaccuracy complaint, identity of the registrant is not required under current policies. These cases are rather rare and are usually detected when the listed registrant contact receives their annual WDRP mail. In these cases we contact our customer and ask that they reach out to the registrant with the request to update the registration details. Sincerely, -- 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 Fri, Oct 22, 2021 at 12:39 PM Michael Palage <michael@palage.com> wrote:
Hello All,
I was reviewing my notes from yesterday’s meeting as well as reviewing some of the previous email list exchanges between and I was hoping that my Registrar colleagues could provide a little clarity, especially Volker given his participation in the 2013 RAA negotiations.
I believe what I have heard and read from my Registrar colleagues is that there is no “identity proofing” requirements in their contracts – accuracy is merely syntactical and operational. I apologizes in advance if I am mischaracterizing this and welcome any corrections. However, in Assignment #1, the follow excerpt from ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR states:
[I]f the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint.
So it appears based on this excerpt that ICANN Contractual Compliance does reserve some right to inquiry about the “identity” of the Registrant. Therefore, I believe potential clarifying questions to ICANN Org could might include: does ICANN Compliance believe that it has the ability to inquiry about the “identity” of a registrant? If so, what is the contractual basis of this authority. Finally, what are the numbers associated with these types of inquiries, e.g. percentage of overall accuracy complaints and raw numbers.
Thoughts? Comments?
Best regards,
Michael
_______________________________________________ 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.
Many thanks Michael for raising this point and Volker for your explanation. Even if these are rare cases, I can indeed see the link between ‘inaccuracy’ and ‘false identity details’ as explained in Volker’s message, so I believe it would be a useful element to keep in mind in our discussions on the accuracy definition. I would find it both useful and interesting to know more about this so I am open to raising any questions to ICANN that our accuracy team believes could shed some further light. Best, Melina From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> On Behalf Of Volker Greimann Sent: Friday, October 22, 2021 1:19 PM To: michael@palage.com Cc: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] Identity Proofing Clarity - Follow Up Homework Hi Michael, all such investigations are based on a substantiated whois inaccuracy complaint where the complainant states that the registrant has provided false details. As this regards a potential violation of our registration agreement with the registrant we will investigate the identity of the registrant in this specific case only. The usual complaint is from the party listed in the registration record that they did not register the domain name in the first place or sold it a while ago and now found that the record was never updated by the old registrant. That said, aside from the investigation following a substantiated inaccuracy complaint, identity of the registrant is not required under current policies. These cases are rather rare and are usually detected when the listed registrant contact receives their annual WDRP mail. In these cases we contact our customer and ask that they reach out to the registrant with the request to update the registration details. Sincerely, -- 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<https://urldefense.com/v3/__http:/www.key-systems.net/__;!!DOxrgLBm!VheXGAoQ...> 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 Fri, Oct 22, 2021 at 12:39 PM Michael Palage <michael@palage.com<mailto:michael@palage.com>> wrote: Hello All, I was reviewing my notes from yesterday’s meeting as well as reviewing some of the previous email list exchanges between and I was hoping that my Registrar colleagues could provide a little clarity, especially Volker given his participation in the 2013 RAA negotiations. I believe what I have heard and read from my Registrar colleagues is that there is no “identity proofing” requirements in their contracts – accuracy is merely syntactical and operational. I apologizes in advance if I am mischaracterizing this and welcome any corrections. However, in Assignment #1, the follow excerpt from ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR states: [I]f the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint. So it appears based on this excerpt that ICANN Contractual Compliance does reserve some right to inquiry about the “identity” of the Registrant. Therefore, I believe potential clarifying questions to ICANN Org could might include: does ICANN Compliance believe that it has the ability to inquiry about the “identity” of a registrant? If so, what is the contractual basis of this authority. Finally, what are the numbers associated with these types of inquiries, e.g. percentage of overall accuracy complaints and raw numbers. Thoughts? Comments? Best regards, Michael _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@icann.org<mailto:GNSO-Accuracy-ST@icann.org> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st<https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-accuracy-st__;!!DOxrgLBm!VheXGAoQHLhbOx658g2ewOmpnoe4Fbv1zRxGhkZCMqylXW4KUskaQkkueUk4gTCYfVAR0dR3$> _______________________________________________ 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<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DOxrgLBm!VheXGAoQHLhbOx658g2ewOmpnoe4Fbv1zRxGhkZCMqylXW4KUskaQkkueUk4gTCYfXzCMFcH$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DOxrgLBm!VheXGAoQHLhbOx658g2ewOmpnoe4Fbv1zRxGhkZCMqylXW4KUskaQkkueUk4gTCYfYhz0F7x$>). 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.
Others on this list more familiar than I am with the fine grain details of both the contracts and the operational aspects of the registration process may be able to comment on my perspective of the registration process. Registration is initiated by the account holder. The account holder is also sometimes referred to as the customer. This is the person who has an account with the registrar and thus has the capability of initiating a registration process. During the registration process the account holder provides the name and other contact details of the registrant. At that point, the registrant acquires the rights and responsibilities associated with the registration, although the account holder continues to be the person who has operational control of the registration. This distinction becomes important when there is a dispute about control of the registration. The account holder has the capability of making changes within a few seconds. If the registrant does not have electronic access to the account, they can appeal to the registrar. This process will generally take some number of days, but, I am told, the registrant will generally prevail. I would imagine that during such a dispute process, the registrant may have to provide evidence they are, in fact, the registrant. Returning to the registration process, what procedures are in place to inform the registrant they are in charge of and responsible for the registration, and what response, if any, is required from the registrant? If an affirmative response is required, I would say the level of validation is more than merely operational. That said, I would also agree this level of validation is somewhat less than full identity validation. By "merely operational" I mean that email or phone numbers are checked to see if mail is delivered or the phone is answered. Similarly, a street address is "merely operational" if it's an actual street address and presumably capable of receiving snail mail. The inclusion of affirmative feedback significantly changes the situation, in my view. Moving to a slightly different but closely related aspect of the registration process, the roles of Admin contact, Tech contact and perhaps other roles deserve a brief mention. I know our general direction is toward deprecating or eliminating these roles. That's fine with me, but I am under the impression some registrars continue to assign specific responsibility and authority to these roles. For example, I believe some registrars give Admin contact the authority to approve transfer of the registration. In my view, whenever a person is assigned a role that includes any degree of responsibility or authority, it's essential the person knows and has agreed. To be fully clear, by "responsibility" I mean an obligation to respond or act in certain circumstances, and by "authority" I mean the authorization to take certain actions. Going a step further, it's not only essential for a person assigned to a role to know their responsibility and authority, it's also essential for anyone who contacts that person to know what that person is obligated and capable to do. Thanks, Steve
HI Steve, Steve said: Returning to the registration process, what procedures are in place to inform the registrant they are in charge of and responsible for the registration, and what response, if any, is required from the registrant? If an affirmative response is required, I would say the level of validation is more than merely operational. That said, I would also agree this level of validation is somewhat less than full identity validation. Sarah says: Yes–the process that you are asking about, something to inform the registrant that their data is used on the domain and require an affirmative response, is the Whois verification process described in the Whois Accuracy Program Specification 1 (f) (i) or (ii). This is what we are referring to as operational validation, and the contractual obligation is to ensure either the email or phone number are operational. I think we should leave out any consideration of Admin contact, as that is definitely being deprecated by the EPDP Phase 1 work currently in IRT, and although I may agree regarding the obligation of a person with responsibility, I don’t think that’s relevant to this accuracy scoping work. 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 22, 2021 8:38 AM To: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] Identity Proofing Clarity - Follow UpHomework Others on this list more familiar than I am with the fine grain details of both the contracts and the operational aspects of the registration process may be able to comment on my perspective of the registration process. Registration is initiated by the account holder. The account holder is also sometimes referred to as the customer. This is the person who has an account with the registrar and thus has the capability of initiating a registration process. During the registration process the account holder provides the name and other contact details of the registrant. At that point, the registrant acquires the rights and responsibilities associated with the registration, although the account holder continues to be the person who has operational control of the registration. This distinction becomes important when there is a dispute about control of the registration. The account holder has the capability of making changes within a few seconds. If the registrant does not have electronic access to the account, they can appeal to the registrar. This process will generally take some number of days, but, I am told, the registrant will generally prevail. I would imagine that during such a dispute process, the registrant may have to provide evidence they are, in fact, the registrant. Returning to the registration process, what procedures are in place to inform the registrant they are in charge of and responsible for the registration, and what response, if any, is required from the registrant? If an affirmative response is required, I would say the level of validation is more than merely operational. That said, I would also agree this level of validation is somewhat less than full identity validation. By "merely operational" I mean that email or phone numbers are checked to see if mail is delivered or the phone is answered. Similarly, a street address is "merely operational" if it's an actual street address and presumably capable of receiving snail mail. The inclusion of affirmative feedback significantly changes the situation, in my view. Moving to a slightly different but closely related aspect of the registration process, the roles of Admin contact, Tech contact and perhaps other roles deserve a brief mention. I know our general direction is toward deprecating or eliminating these roles. That's fine with me, but I am under the impression some registrars continue to assign specific responsibility and authority to these roles. For example, I believe some registrars give Admin contact the authority to approve transfer of the registration. In my view, whenever a person is assigned a role that includes any degree of responsibility or authority, it's essential the person knows and has agreed. To be fully clear, by "responsibility" I mean an obligation to respond or act in certain circumstances, and by "authority" I mean the authorization to take certain actions. Going a step further, it's not only essential for a person assigned to a role to know their responsibility and authority, it's also essential for anyone who contacts that person to know what that person is obligated and capable to do. Thanks, Steve
HI Steve, Steve said: Returning to the registration process, what procedures are in place to inform the registrant they are in charge of and responsible for the registration, and what response, if any, is required from the registrant? If an affirmative response is required, I would say the level of validation is more than merely operational. That said, I would also agree this level of validation is somewhat less than full identity validation. Sarah says: Yes–the process that you are asking about, something to inform the registrant that their data is used on the domain and require an affirmative response, is the Whois verification process described in the Whois Accuracy Program Specification 1 (f) (i) or (ii). This is what we are referring to as operational validation, and the contractual obligation is to ensure either the email or phone number are operational. I think we should leave out any consideration of Admin contact, as that is definitely being deprecated by the EPDP Phase 1 work currently in IRT, and although I may agree regarding the obligation of a person with responsibility, I don’t think that’s relevant to this accuracy scoping work. 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 22, 2021 8:38 AM To: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] Identity Proofing Clarity - Follow UpHomework Others on this list more familiar than I am with the fine grain details of both the contracts and the operational aspects of the registration process may be able to comment on my perspective of the registration process. Registration is initiated by the account holder. The account holder is also sometimes referred to as the customer. This is the person who has an account with the registrar and thus has the capability of initiating a registration process. During the registration process the account holder provides the name and other contact details of the registrant. At that point, the registrant acquires the rights and responsibilities associated with the registration, although the account holder continues to be the person who has operational control of the registration. This distinction becomes important when there is a dispute about control of the registration. The account holder has the capability of making changes within a few seconds. If the registrant does not have electronic access to the account, they can appeal to the registrar. This process will generally take some number of days, but, I am told, the registrant will generally prevail. I would imagine that during such a dispute process, the registrant may have to provide evidence they are, in fact, the registrant. Returning to the registration process, what procedures are in place to inform the registrant they are in charge of and responsible for the registration, and what response, if any, is required from the registrant? If an affirmative response is required, I would say the level of validation is more than merely operational. That said, I would also agree this level of validation is somewhat less than full identity validation. By "merely operational" I mean that email or phone numbers are checked to see if mail is delivered or the phone is answered. Similarly, a street address is "merely operational" if it's an actual street address and presumably capable of receiving snail mail. The inclusion of affirmative feedback significantly changes the situation, in my view. Moving to a slightly different but closely related aspect of the registration process, the roles of Admin contact, Tech contact and perhaps other roles deserve a brief mention. I know our general direction is toward deprecating or eliminating these roles. That's fine with me, but I am under the impression some registrars continue to assign specific responsibility and authority to these roles. For example, I believe some registrars give Admin contact the authority to approve transfer of the registration. In my view, whenever a person is assigned a role that includes any degree of responsibility or authority, it's essential the person knows and has agreed. To be fully clear, by "responsibility" I mean an obligation to respond or act in certain circumstances, and by "authority" I mean the authorization to take certain actions. Going a step further, it's not only essential for a person assigned to a role to know their responsibility and authority, it's also essential for anyone who contacts that person to know what that person is obligated and capable to do. Thanks, Steve
Good Afternoon, This ICANN compliance enforcement process does not assign identity verification responsibility to the Registrar, it only stipulates that ICANN (when considering an identity complaint) may request the Registrar to "...provide further information concerning their findings and the results of their investigation...". This is not asking for more work to be done, just more data on what has already been done by the registrar. If a Registrar does do identity verification like Volker suggests, that is above and beyond what is required and is not part of accuracy as it is defined today. Thanks Roger ________________________________ From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> on behalf of Volker Greimann <volker.greimann@centralnic.com> Sent: Friday, October 22, 2021 6:18 AM To: michael@palage.com <michael@palage.com> Cc: gnso-accuracy-st@icann.org <gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Identity Proofing Clarity - Follow Up Homework Hi Michael, all such investigations are based on a substantiated whois inaccuracy complaint where the complainant states that the registrant has provided false details. As this regards a potential violation of our registration agreement with the registrant we will investigate the identity of the registrant in this specific case only. The usual complaint is from the party listed in the registration record that they did not register the domain name in the first place or sold it a while ago and now found that the record was never updated by the old registrant. That said, aside from the investigation following a substantiated inaccuracy complaint, identity of the registrant is not required under current policies. These cases are rather rare and are usually detected when the listed registrant contact receives their annual WDRP mail. In these cases we contact our customer and ask that they reach out to the registrant with the request to update the registration details. Sincerely, -- 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<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> 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 Fri, Oct 22, 2021 at 12:39 PM Michael Palage <michael@palage.com<mailto:michael@palage.com>> wrote: Hello All, I was reviewing my notes from yesterday’s meeting as well as reviewing some of the previous email list exchanges between and I was hoping that my Registrar colleagues could provide a little clarity, especially Volker given his participation in the 2013 RAA negotiations. I believe what I have heard and read from my Registrar colleagues is that there is no “identity proofing” requirements in their contracts – accuracy is merely syntactical and operational. I apologizes in advance if I am mischaracterizing this and welcome any corrections. However, in Assignment #1, the follow excerpt from ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR states: [I]f the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint. So it appears based on this excerpt that ICANN Contractual Compliance does reserve some right to inquiry about the “identity” of the Registrant. Therefore, I believe potential clarifying questions to ICANN Org could might include: does ICANN Compliance believe that it has the ability to inquiry about the “identity” of a registrant? If so, what is the contractual basis of this authority. Finally, what are the numbers associated with these types of inquiries, e.g. percentage of overall accuracy complaints and raw numbers. Thoughts? Comments? Best regards, Michael _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@icann.org<mailto:GNSO-Accuracy-ST@icann.org> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-accuracy-st&data=04%7C01%7Crcarney%40godaddy.com%7C39658ab1f5b7471cf59108d9954dcea5%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637704984430885348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YUaSIpJqu3TKV9jmT9rMREIxAOWIpMp4OB%2FVyfo2e6M%3D&reserved=0> _______________________________________________ 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<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=04%7C01%7Crcarney%40godaddy.com%7C39658ab1f5b7471cf59108d9954dcea5%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637704984430895335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1D6PJTyexx1jqrIf3TWyUSRI0wAlPcvYJTjYXegL4ds%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=04%7C01%7Crcarney%40godaddy.com%7C39658ab1f5b7471cf59108d9954dcea5%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637704984430895335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q0ahadxRLFsTcttb%2F6oFUwM%2Fszxll%2FTeEcJyXiDbXtU%3D&reserved=0>). 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.
Sarah, Volker, et al, My apologies again for not staying for the entire call yesterday. I have a standing commitment to chair a call on Thursdays at 1400 UTC. (In fact, those calls were originally scheduled at 1300 UTC, and I was able to move them in deference to this group's schedule. At the time, I believe I was told our calls going forward would be only an hour, not 90 minutes. If our calls in the future will regularly run 90 minutes, I'll have to figure out how to deal with the conflict.) I have read the transcript for the period immediately after I departed. (I believe it was the period from 1:00 to 1:04, copied below for convenience.) After reading the transcript and reflecting on our conversation, I'm not sure we're all that far apart. Perhaps it's mainly a question of precision of terminology. I have been using the SAC 058 definitions of operational and identity validation: *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. The SAC 058 definition of Operational Validation does appear to require affirmative feedback, so perhaps that's weaker than the level of validation required by the contracts. I was not involved in the preparation of SAC 058. I will go back to my SSAC colleagues for some clarification and background. A separate matter, I believe we're in agreement that registrars are permitted to do more validation, i.e., the ICANN policy and the ICANN contracts do not prohibit them from doing so. I don't think either the ICANN policy or the ICANN contracts are clear on this point. Thanks, Steve Sarah Wyld (RrSG) 01:00:14Yes, thank you i'm super disappointed that Steve is not able to remain in this meeting, because, of course, I wanted to respond to what he said so My hope is that he'll be able to listen to the recording. 01:00:24So that we can all get on the same page, because we have a very different understanding of how this specification. 01:00:30works or what the requirements are in real life, but so firstly going back to what Alan said Alan said that the current requirements are not suitable and to that I would really say why what problem is there. 01:00:42So that's what I think the job of the scoping team would be is to determine if there is an issue, and I have to say very clearly accuracy is not the same thing as access to the data. 01:00:54The relevant controller has the responsibility of determining accuracy and, as you can see right here on screen, there are processes that are mandatory for doing so. 01:01:03But the ability for some person on the Internet to look up the WHO is data and look at the email address is not the same as making sure that accuracy is. 01:01:14avail is the case right, those are very, very different things. 01:01:17So that's part one, part two, to Steve and the higher level of validation I think it's really important here, that we need to not conflate the account holder and the registry right, so I just want to point out. 01:01:29That, if the registered name holder does not respond in the appropriate time period the domain gets suspended, but if the account holder does not respond, there is no need to suspend the domain that's a difference in that paragraph so it's important to keep that in mind. 01:01:44and going back to what he said about manual here manual verification could mean a higher level, in my experience that has been taken to me that, instead of using an automated system to send the verification email to the domain owner. 01:01:56There might be, for example, somebody from the customer service team sends an email directly that they then get a reply to so or they actually call the person on their phone instead of using an automated system. 01:02:07I have never seen this interpreted to mean that the identity is validated, such as like checking an ID card against the registration data so that that's just not operationally what's going on here and I don't think it's the requirement, thank you. Michael Palage (Chair) 01:02:20Okay i'm Volker you're on the clock go, please. Volker Greimann (RRSG) 01:02:25Yes, thank you and have disappointed Steve had to leave because I think this would have been helpful for him as well. 01:02:33I was part of the negotiation team of the 2013 ra, and the reason why we have that language is because we wanted to in there. 01:02:44I can have the opinion that. 01:02:48Failure to verify should lead to the automated the activation of the domain name after 15 days, so if you forget to click on. 01:02:58That link that we send you then your hospital websites your. 01:03:04E commerce websites your blog might go down, and you might lose whatever you had. 01:03:12operational for that time that it takes you to get it back online, whereas. 01:03:17With this option we now can have. 01:03:21For. 01:03:23Important customers for customers that we know and trust for corporate registrar's that may want to have additional levels of securities. 01:03:32A way to avoid that automation automatism of the activation and basically the ability for certain registrar's they want to do that to flag certain registrations as essential or critical domain names and thereby. 01:03:49Avoiding automated deactivation if they so choose, but it still does not require a registered do anything it's just an option to protect high value domain is or. 01:04:00Critical resources that you managed for a customer Thank you
participants (6)
-
Michael Palage -
Roger D Carney -
Sarah Wyld -
Steve Crocker -
STROUNGI Melina -
Volker Greimann