Skip to main content

Technical Study Group Makes Progress at First Face-to-Face Meeting

Tsg progress face to face meeting 750x425 04feb19 en

In the cold of January, the 10-member Technical Study Group on Access to Non-Public Registration Data (TSG-RD) met for two days at ICANN's Washington, DC office. Our focus was to get to productive outcomes that would propel our work in the coming weeks and months. I am happy to report substantial progress was made. We agreed on five use cases, and perhaps even more importantly, agreed on what we should not be working on.

As previously described, ICANN President and CEO Göran Marby, asked me to form this group to explore a technical solution that would have the ICANN organization serve as the sole entity receiving authorized queries for non-public registration data, obtaining such data from generic top-level domain (gTLD) registries and registrars, and then passing that data to the third-party requestor. The TSG's aim is to develop a technical design and specification that could be used by implementors to determine whether a unified access model would be possible under the European Union's General Data Protection Regulation. Assuming the unified access model would work also assumes diminished legal liability for the contracted parties who collect and store domain name registration data.

During our two days of discussions, the TSG-RD discussed five use cases to guide development of a technical model for access to non-public registration data. We also discussed the user journey in some detail. Specifically, we determined that our model should allow for both synchronous and asynchronous authorization to responses to queries for non-public registration data. We also, defined some of the features of the user experience. The group agreed a user should be able to discover the base URL for the centralized access system; and discussed whether there should be a mechanism to redirect users who are not authenticated or are wrongly authenticated from this system to the appropriate resource for gaining access to the registration data they seek.

The group also agreed on several assumptions, detailed in our updated charter. We confirmed that the group's work will be built upon the Registration Data Access Protocol (RDAP) and will utilize the gTLD RDAP profile currently under discussion; that gaining access to non-public registration data would be centralized within the ICANN org; and that a standard model will apply equally to all parties requesting access to non-public registration data. We will explain all these in detail when we produce our final technical model. We left the meeting with a feeling of enthusiasm and renewed energy towards building a technical model that will hopefully lay the foundation for the future.

Readers should note that TSG-RD is not tasked with developing policy or determining which third parties may be authorized to gain access to non-public registration, nor how they may be authenticated. Our work does not replace the multistakeholder policy development process, including the ongoing work of Expedited Policy Development Process, which plans to work on a standardized access model after certain gating questions are resolved. We expect to conclude our work in April and hand off our work products to others engaged on the policy aspects of this issue.

Looking ahead, the TSG-RD plans to continue our weekly calls and hold a three-day face-to-face meeting in February. We are all coming to the ICANN64 meeting in Kobe, where we plan to hold a community workshop to present our work and solicit your feedback. This feedback will shape our final work product. I have met with the contracted parties, at their invitation, to share what we have done so far. If you would like us to share our observations and our work with you in Kobe, in addition to the public workshop, please write us at and we will add you to our meeting agenda.

To read more about the group's work and listen to recordings of our meetings, please visit the TSG-RD page on


    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."