Skip to main content

Belgian Data Protection Authority Response to Proposed Unified Access Model

LOS ANGELES – 17 December 2019 – On 12 December 2019, ICANN President and CEO Göran Marby received a non-binding letter from the Belgian Data Protection Authority (DPA) in response to ICANN org's paper, "Exploring a Unified Access Model for gTLD Registration Data," which was submitted to the European Data Protection Board (EDPB) on 25 October 2019. ICANN org was made aware of the draft letter addressed to Marby on 4 December; however, it was not officially received until 12 December.

ICANN org's paper outlined a proposed Unified Access Model (UAM) for generic top-level domain (gTLD) registration data that would consolidate responsibility for the processing activity of disclosure of nonpublic data within a centralized system for access to non-public registration data.

As stated in the paper, this work was undertaken by ICANN org to help clarify the legal foundation upon which a model could be built and was intended to inform the community's work on a Standardized System for Access/Disclosure that is underway in Phase 2 of the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP Phase 2). In addition, ICANN org sought to address the numerous communications received from stakeholders such as the European Commission, the G7, as well as the Governmental Advisory Committee and other parts of the community calling for a unified solution for access to non-public registration data.

In its response, the Belgian DPA encouraged ICANN to continue its efforts to design a comprehensive system for access control that takes into account the requirements of security, data minimization, and accountability. The response did not provide any definitive opinions regarding the questions that ICANN org included in the paper.

The letter states that the policy and relevant safeguards that the community will develop to be applied in a UAM will be extremely important to assess whether a centralized model increases or decreases the level of protection enjoyed by natural persons. Ultimately, the application and administration of the community-developed policy and safeguards will determine the level of protection for data that is processed in a UAM. With respect to the roles and responsibilities, the letter states that parties to a processing activity cannot simply designate which party should be deemed to act as a controller or joint controller; a factual case-by-case is needed to that end. A previous communication by the Article 29 Working Party is further referenced, which contained the statement that, "At first glance it would seem that…ICANN and the registries are joint controllers". The letter was not written as guidance from the full EDPB.

The Belgian DPA has indicated their willingness to further discuss this effort and have invited ICANN org staff to meet with them. We look forward to continuing the discussion and will share any updates from this meeting.

ICANN org extends its appreciation to the European Commission for its advice throughout the development of the paper submitted to the EDPB, and its ongoing support for the community's continued efforts in EPDP Phase 2.

ICANN org is proud of the significant and ongoing efforts contributed by thousands of community members in working to develop a policy to facilitate lawful access to nonpublic registration data.


ICANN's mission is to help ensure a stable, secure, and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world.

More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."