Skip to main content

Technical Study Group Advances Draft Model

Tsg advances draft model 1349x769 21feb19 en

The Technical Study Group on Access to Non-Public Registration Data recently spent three days in Washington, D.C. engaged in intense and collegial discussions to develop a detailed draft of the Technical Model for Non-Public Registration Data. Nine of our ten members worked together with representatives from the ICANN organization to refine the requirements necessary for a model. We also discussed how to simplify the user experience for such a system and added new assumptions to our charter. We are working hard to share the draft Technical Model with the ICANN community before ICANN64 in Kobe, Japan.

We started our discussions by agreeing upon the requirements necessary for the draft Technical Model, which will be built on the Registration Data Access Protocol (RDAP). We then discussed whether all the requirements would apply to the two authentication/authorization protocols we identified: one based on Open ID Connect/OAuth and the other based on mutual Transport Layer Security (TLS) authentication. This exercise helped us to determine that a solution based on Open ID Connect/OAuth complies with all the identified requirements. The group also determined that mutual TLS authentication could be used for communication between the ICANN org and contracted parties. Open ID Connect/OAuth allows users to employ various technologies; we are considering username/password and digital certificates. We noted in the requirements that an identity provider – the entity that authenticates a user's identity – must support at least one of these technologies in their implementation of Open ID Connect/OAuth and may choose to support both. The identity provider plays a key role in ensuring the integrity and fidelity in a unified access model. To that end, we invited two representatives from Europol to engage in a brief discussion on some of these approaches.

We also had an important discussion regarding user experience. The consensus was to design a system that is as simple as it is practicable. We agreed that in order of complexity, ICANN bears the most complexity, followed by contracted parties, identity providers, RDAP client implementers, and finally users. Based on the simplicity principle, we separated the authorization/authentication components from the RDAP flow components.

This work has led us to what we believe is a viable draft schematic of an operating model. Because future policy challenges and interpretation of the law may impact how the draft Technical Model may be operationalized, we added new assumptions to our charter.

In the coming weeks, the team members, working together with ICANN org representatives, will further develop the draft Technical Model in order to share it with the community before heading to Kobe. During our face-to-face meeting, we also discussed how to present our work outside of the ICANN community, including to the European Commission. When we finish our work on the Technical Model after Kobe, we will send our report to ICANN President and CEO Göran Marby.

We look forward to sharing these discussions with you in more detail at ICANN64 and invite you to a community engagement session we are planning. Many of our team members will travel to Kobe and welcome the opportunity to meet with your groups. If you are interested in hearing from us, please reach out to gdpr@icann.org. For more information on our work, please visit our page on https://www.icann.org.

Comments

    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""icann.org"" is not an IDN."