RrSG initial comment on SSAD Registrant user group
Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains. To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Sarah Wyld Sent: Thursday, June 6, 2019 9:36 AM To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Thank you Sarah. Greg just for completeness, an EU data subject will of course still be entitled to exercise their rights against the 'SSAD' also. If their data is processed within the SSAD then whoever is the guardian of that system, shall have to have a) a viable and robust process for dealing with such requests directly themselves (assuming they are a controller), and/or b) provide the necessary information and aid to other controllers dealing with such requests in this data processing ecosphere (especially Art 17). But I do agree, expecting them to have to be a "subscribed" or "credentialed" user in order to exercise such rights is a *very* bad idea. Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Jun 7, 2019 at 3:33 PM Greg Aaron <greg@illumintel.com> wrote:
Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains.
To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data.
All best,
--Greg
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Sarah Wyld *Sent:* Thursday, June 6, 2019 9:36 AM *To:* gnso-epdp-team@icann.org *Subject:* [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group
Hello all,
The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose.
Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date.
The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide.
We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team.
--
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
This may be an advance warning that credentialing in general is a bad idea. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alan Woods Greg just for completeness, an EU data subject will of course still be entitled to exercise their rights against the 'SSAD' also. If their data is processed within the SSAD then whoever is the guardian of that system, shall have to have a) a viable and robust process for dealing with such requests directly themselves (assuming they are a controller), and/or b) provide the necessary information and aid to other controllers dealing with such requests in this data processing ecosphere (especially Art 17). But I do agree, expecting them to have to be a "subscribed" or "credentialed" user in order to exercise such rights is a very bad idea. Alan [Image removed by sender. Donuts Inc.]<http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.]<https://www.facebook.com/donutstlds> [Image removed by sender.] <https://twitter.com/DonutsInc> [Image removed by sender.] <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Jun 7, 2019 at 3:33 PM Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> wrote: Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains. To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Thursday, June 6, 2019 9:36 AM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
Yes. Stephanie Perrin On 2019-06-09 14:11, Mueller, Milton L wrote: This may be an advance warning that credentialing in general is a bad idea. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Alan Woods Greg just for completeness, an EU data subject will of course still be entitled to exercise their rights against the 'SSAD' also. If their data is processed within the SSAD then whoever is the guardian of that system, shall have to have a) a viable and robust process for dealing with such requests directly themselves (assuming they are a controller), and/or b) provide the necessary information and aid to other controllers dealing with such requests in this data processing ecosphere (especially Art 17). But I do agree, expecting them to have to be a "subscribed" or "credentialed" user in order to exercise such rights is a very bad idea. Alan [Image removed by sender. Donuts Inc.]<http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.]<https://www.facebook.com/donutstlds> [Image removed by sender.] <https://twitter.com/DonutsInc> [Image removed by sender.] <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Jun 7, 2019 at 3:33 PM Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> wrote: Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains. To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Thursday, June 6, 2019 9:36 AM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
Yes, data subjects can request their data from a party that holds it; those kinds of GDPR requests are sometimes made through out-of-band methods and don’t require the data subjects to be system users with system accounts. The operator must be able to respond to requests from data subjects… but for completeness, it must do so AFAIK ONLY IF the operator holds the data. Most models discussed so far don’t have the SSAD operator storing all the data – it could merely shuttle data back and forth. The group will no doubt discuss that design aspect more later. All best, --Greg From: Alan Woods <alan@donuts.email> Sent: Friday, June 7, 2019 11:06 AM To: Greg Aaron <greg@illumintel.com> Cc: Sarah Wyld <swyld@tucows.com>; GNSO EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Thank you Sarah. Greg just for completeness, an EU data subject will of course still be entitled to exercise their rights against the 'SSAD' also. If their data is processed within the SSAD then whoever is the guardian of that system, shall have to have a) a viable and robust process for dealing with such requests directly themselves (assuming they are a controller), and/or b) provide the necessary information and aid to other controllers dealing with such requests in this data processing ecosphere (especially Art 17). But I do agree, expecting them to have to be a "subscribed" or "credentialed" user in order to exercise such rights is a very bad idea. Alan <http://donuts.domains/> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. _____ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Jun 7, 2019 at 3:33 PM Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> > wrote: Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains. To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > On Behalf Of Sarah Wyld Sent: Thursday, June 6, 2019 9:36 AM To: gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
Registrants have the right to request their data from any controller or processor, so they are a "natural" potential user of the SSAD. Access from their own registrar (or reseller?) is presumably already covered through their contractual arrangements. So that primarily leaves the registry or their sub-contractors (to the extent that the registry possesses any such non-public data). If registries are happy to treat such requests as edge cases and handle them on an ad hoc basis, then I think we can safely leave them off as potential users of the SSAD. And save ourselves a lot of work in the process! :-) Alan At 07/06/2019 10:33 AM, Greg Aaron wrote: Agree. Registrants already have the appropriate means to view their own sensitive data fields and update their domain data: the registrar’s system. And that provides controlled, permissioned access for the registrants to see their data and theirs only. And registrants will have public access to RDS to see non-sensitive data about their domains. To offer registrants access to the SSAD System on top of that would be a nightmare from an access management view. (How would registrants get credentials into a SSAD, and how would that system know what records the registrant is allowed to see?) SSAD is for third parties who need to access non-public data. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Sarah Wyld Sent: Thursday, June 6, 2019 9:36 AM To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] RrSG initial comment on SSAD Registrant user group Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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 (6)
-
Alan Greenberg -
Alan Woods -
Greg Aaron -
Mueller, Milton L -
Sarah Wyld -
Stephanie Perrin