Caitlin, Thank you so much for this background information. During the Expedited Policy Development Process (EPDP) Phase 1, registrars emphasized that the term "registration data" should not be interpreted too broadly. The Non-Commercial Stakeholders Group (NCSG) advocates for minimizing data collection, particularly in policies that may involve data disclosure. The Registration Data Policy includes such disclosure requirements. I have found two examples that express registries and registrars' opinions about this matter during the EPDP. 1. In 2019, the Registries Stakeholder Group (RySG) noted that the definition of "Registration Data" in the Temporary Specification was overly broad, potentially encompassing data not traditionally considered registration data, such as billing information. They proposed refining the definition to specify the exact data elements collected during domain name registration. 2. Additionally, in the EPDP's triage report, registrars highlighted the importance of data minimization, referencing Article 5(1)(c) of the GDPR, which mandates that personal data collection be limited to what is necessary. They argued that collecting administrative, technical, and billing contacts exceeds what is required for domain registration purposes. When the law or a policy is silent or vague, then usually we should interpret it narrowly. It seems to me there is no indication that the EPDP intended for billing contact information to be included as registration data, even on an optional basis and several times in the comments registries and registrars mentioned that it should not be.But since the issue was flagged to be discussed in 2019 I am going to do some more research and see if EPDP addressed it somewhere. Best regards, ### 1. "d*efinition of Registration Data **Comment (RySG)* The Temp Spec contains this definition: “Registration Data” means data collected from a natural and legal person in connection with a domain name registration.” *The “in connection with” language is so broad and vague that it could be interpreted to data that registrars and registries would not consider to be registration data such as billing data, account creation data, and the like. * RySG proposes to revise the definition to reference the relevant data elements: “Registration Data” means the data *elements identified in Annex [X]*, collected from a natural and legal person in connection with a domain name registration.” (Annex [X] would then identify the relevant data elements, as carried over from the whatever becomes the final version of Recommendation 4). Additional text is in *bold and italics*. 2. Triage Report Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data) and here is what the registrars say: "The following should also be struck in its entirety: “the collection of Personal Data […] is specifically mandated by the Bylaws.”. While collection may be mandated by the Bylaws, the data minimization principle (Art 5(1)(c) of GDPR) requires that Personal Data shall be ‘adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed’. The collection of admin, technical and billing contacts go beyond what is necessary in relation to the purposes. The starting point ought to be data minimization and so any personal data collected ought to be minimized (noting specifically that there is no reason to collect up to three contacts and that there is no viable way to obtain consent from parties not related to the registration contract). " (page 19) Farzaneh On Mon, Jan 6, 2025 at 12:56 PM Caitlin Tubergen via council < council@icann.org> wrote:
Dear Councilors,
During the December Council meeting, the Council requested ICANN org to provide additional background on the question from the EPDP Phase 1 Implementation Review Team (IRT) concerning the billing contact.
In addition to the background provided in the email of 27 November <https://lists.icann.org/hyperkitty/list/council@icann.org/thread/3Z4MLHGICUC...>, it might be helpful to highlight how billing contact is distinct from some of the other contact elements - namely the contact elements in RDDS (formerly referred to as Whois).
*In what way(s) is the billing contact treated differently than other contacts including administrative, technical, etc.?*
- Billing contact is referenced in the RAA only with respect to the *retention* of data, not the *display* (or publication) of data via RDDS or RDAP. This is distinct from other data elements referenced in the RAA, e.g., administrative contact and technical contact, both of which were required to be displayed as part of the RDDS specification of the RAA. (See Section 3.3 and 3.4 of the RAA.) - Additionally, the Temporary Specification for gTLD Registration Data <https://www.icann.org/resources/pages/gtld-registration-data-specs-en>, which the EPDP Team was chartered to review, includes no mention of billing contact, but it does include references to registrant contact, administrative contact, and technical contact details. (“Consistent with ICANN's stated objective to comply with the GDPR, while maintaining the existing WHOIS system to the greatest extent possible, the Temporary Specification maintains robust collection of Registration Data (including Registrant, Administrative, and Technical contact information), but restricts most Personal Data to layered/tiered access.”)
*Was billing contact in scope for the EPDP Phase 1 (Temp Spec) to provide policy recs on?*
Some have noted that *YES*, this was in scope because the EPDP Phase 1 (Temp Spec) Charter <https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec-...> included the following charter question, “b1) What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?”
Some have noted that *NO*, this data element was not in scope as billing contact was neither part of the Temporary Specification, nor was it part of RDDS data as defined in the RAA.
*Was the omission of a reference to billing contact data a drafting error of the EPDP (Temp Spec) Team? In other words, did the EPDP Team intend to change the current required retention of billing contact data and make it optional?*
During a dedicated meeting on this topic, some IRT members expressed an opinion that *YES*, it was the intention of the EPDP Team to remove this current requirement (of collecting and retaining billing contact data) and make it optional.
However, it is unclear to ICANN org whether this is a broadly supported view of the IRT and/or if this is a position supported by the GNSO Council.
*What is the Council being asked to do now?*
The Council is being asked to provide guidance to ICANN org on two questions:
1. Does the Council confirm billing contact was in scope for the EPDP on the Temp Spec - Phase 1 Team? 2. Does the Council confirm:
a. the collection of billing contacts by registrars should continue to be required as per current RAA requirements because EPDP Phase 1, by being silent on this, did not mean to change this requirement, OR
b. the collection of billing contacts by registrars should become optional because EPDP Phase 1, by being silent on this, meant to change the RAA requirement?
*What happens next? *
If the Council answers *YES* to Questions 1 and 2(b), the Council is advised to acknowledge its guidance and conclusion in writing to ICANN org. If ICANN org receives this confirmation from the Council that it concludes that billing contact data is no longer required to be collected, retained, or transferred to the data escrow agent, ICANN org will begin the process of updating (removing) current requirements related to billing contact.
If the Council answers *NO* to either Question 1 or 2(b), the current RAA requirement for registrars to collect, retain, and transfer billing contact data to the data escrow agent will remain in place.
Please let us know if we can be of further assistance by addressing any additional questions or concerns.
Best regards,
Caitlin
_______________________________________________ council mailing list -- council@icann.org To unsubscribe send an email to council-leave@icann.org
_______________________________________________ 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.