Skip to main content

EPDP Team Makes Key Progress in Phase 2 Work

Epdp team key progress phase 2 1910x1082 19sep19 en

As the Chair of the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data Team (EPDP Team), I am pleased to report that the EPDP Team has made crucial progress towards our development of a System for Standardized Access/Disclosure (SSAD) to non-public gTLD registration data, the centerpiece of our Phase 2 work.

We held a productive, three-day meeting last week at ICANN's Los Angeles headquarters. Before we met, the EPDP Team discussed a wide array of real-world use cases to understand needs and requirements when non-public registration data is requested. By synthesizing the commonalities among these use cases, our support staff developed the "Zero Draft [DOCX, 5.45 MB]." This document outlined the building blocks and proposed policy principles to stimulate our discussion on SSAD development.

SSAD "Hamburger" Model

To explain it in simple terms by using an analogy, the EPDP Team has proposed a "hamburger model". The SSAD "hamburger" is made of three essential parts of equal importance.

  • Top "bun": consists of building blocks related to requestors on the demand side, which are individuals or entities that request access to non-public gTLD registration data.
  • Bottom "bun": consists of building blocks related to suppliers on the supply side, which are registries and registrars that hold gTLD registration data.
  • Middle "burger patty": an interface that determines the interaction modalities between requestors and suppliers in line with the policy requirements developed by the EPDP Team. Further deliberations will determine what shape the interface will take and how requests will be processed.

All three parts of the SSAD hamburger are constructed with important building blocks, with several policy principles that underpin their implementation.

  • Demand side: the building blocks are necessary to determine who can request the registration data, how a request is formulated, whether the requestor is legitimate amongst other considerations.
  • Supply side: registries and registrars need to perform certain actions and respond to the requests in line with the requirements set out in the building blocks.
  • System's interface: it may involve several options. For example, requests for data may come through only one gateway or multiple gateways; to confirm the validity of the request, there may be a simple check of credentials, accreditation, or other determinations.

While the EPDP Team has accepted the hamburger model as the starting point for our deliberations, we still have a lot of work to do to reach agreement on the policy and operational details of the SSAD. At this Los Angeles meeting, we aimed to reach some fundamental decisions on the system from an architectural point of view.

Los Angeles Meeting

On the first day, we met with the ICANN President and CEO Göran Marby and the representatives from the ICANN org team that have been engaging with the European Data Protection Board (EDPB). This session helped us gain insight into the team's expected next steps to obtain input from the EDPB on policy assumptions in relation to the Unified Access Model (UAM). Our discussion also centered on some of our most pressing questions, including the sharing of liability among actors involved in the processing of data requests, the possibility of outsourcing all liability to external organizations, and the role ICANN org would play, if any.

After the conversation with Göran and the ICANN org team, we took stock of where we were and reflected on how the information we received could be capitalized in our policy development work. Using the "Zero Draft" as the foundation of our work, we spent the rest of the meeting focusing on developing several building blocks, which we prioritized via a survey. These topics were:

  • Authentication, authorization, accreditation of requestors.
  • Categorization of users.
  • Purposes for requesting non-public registration data.
  • Query policy, including bulk access and reverse lookup.

In addition, we also discussed the legal memos from Bird & Bird LLP, our external legal counsel. The legal memos provided guidance on the roles and responsibilities of the parties involved in the SSAD, how to conduct the balancing test under GDPR, and the potential automation of responses under SSAD, etc.

By the end of the meeting, we reached a preliminary agreement that SSAD should be automated as much as possible and standardized for the rest of its functions as much as feasible. We also agreed on a number of action items that will push us forward, including developing a potential accreditation model and considering who makes the ultimate determination to disclose non-public registration data. We will continue working on every building block, and in parallel, contemplating on the structural and architectural issues of the SSAD to reach agreement on how the system should function.

This three-day in-person meeting proved to be an effective use of the Team's limited time. We engaged in constructive dialogue and created a path forward to address the concerns of all stakeholders through a bottom-up multistakeholder process.

On behalf of the EPDP Team, I want to thank the expert facilitation of CBI's Gina Bartlett, who helped us keep the focus and momentum. Our thanks also go to the EPDP Team's support staff and other ICANN org staff who facilitated our work in Los Angeles.

Next Steps

We still have a lot of work to do. The next step for the EPDP Team is to follow up on action items, pull together the work products, and produce the "Draft 1.0" to further clarify our vision of the SSAD. We also need to work out a plan for the ICANN66 sessions to effectively steer the Team's deliberation.

In Montreal, the EPDP Team will organize four sessions, including a full-day session on Saturday, 2 November. Those following our work are welcome to attend the Plenary session on Monday, 4 November, during which we hope to provide an update on the progress made since the Los Angeles meeting and obtain input from the ICANN community.

More Information

The transcripts, recordings, and outputs of the EPDP Team's Los Angeles meeting are published on this wiki page.

To learn more about the ICANN org team tasked to engage with the EDPB, check these presentation slides [PDF, 10.5 MB].


    niğde escort  18:37 UTC on 12 October 2019

    reaaly good

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