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.