This is the third post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. You can also take a look back at our recap of the EPDP team’s work leading up to and during the conference, and our discussion of the Unified Access Model, which will eventually govern how access to Whois data is provided.

Although it may seem that the GDPR is the only thing that matters in the domain industry right now, it wasn’t the sole focus of ICANN 63, and we don’t want to lose sight of the other valuable work that came out of the conference.

Tucows is an active participant in the ICANN community: the Chair of the Registrar Stakeholder Group (RrSG) is our Analytics and Policy Director; some of our staff are members of the RDAP Pilot Project and PPSAI Working Group, and observers of the EPDP; and Tucows representatives collaborate with the RrSG’s Compliance and TechOps sub-teams to help develop and implement policies and processes that will benefit our customers and the community at large.

Privacy and proxy service accreditation

One significant work track within the ICANN community is around accreditation for providers of Privacy and Proxy services. Right now, any registrar can offer a Privacy or Proxy (“P/P”) service — our version is called Whois Contact Privacy —  for domains registered with them. However, one of the requirements in the 2013 RAA is that if ICANN adopts a policy establishing accreditation for P/P services, registrars must comply with that policy and become accredited to continue providing those services. Such a policy does not yet exist, but work towards one has been underway ever since that 2013 RAA requirement came into effect.

Back in December 2015, the Privacy & Proxy Services Accreditation Issues (“PPSAI”) PDP Working Group provided policy recommendations for how P/P Accreditation could work. Their Final Report included requirements for providers of P/P services and defined eligibility standards for users of P/P services.

An Implementation Review Team (IRT) was then convened in January 2016, in order to “assist [ICANN Org.] staff in developing the implementation details for the Privacy and Proxy Services Accreditation Program, to ensure the implementation conforms to the intent of the Final Recommendations” (reference). In the two and a half years that followed, the PPSAI IRT worked hard to transform the recommendations into actual accreditation agreement language.

One significant part of their implementation work was focused on the question of when underlying registration data is to be revealed. Another was related to the cost of accreditation; even now there remains unresolved conflict between the IRT members and ICANN staff resulting from ICANN setting the P/P accreditation fees extremely high — on par with ICANN’s actual registrar accreditation fee — without being able to justify this price-point.

We said this post would be focused on the non-GDPR meetings at ICANN 63, but the effects of that data privacy regulation are so far-reaching, it’s hard to avoid. Because of the GDPR, the ICANN community is now working to standardize how access to non-public Whois data will be provided. As a result, the PPSAI IRT work will be “slowed down” until the EPDP is complete and the full landscape of the GDPR’s effects on our Registrar Accreditation Agreement obligations is understood.

This is important for our resellers and registrants, because once the IRT resumes regular work and the Privacy/Proxy Accreditation Agreement is finalized, we’ll need to sign on and pass the requirements along to our resellers. The significant area of concern here is the fees that we mentioned previously, and so when the IRT reconvenes we’ll be pushing to understand the justification for those fees as well as reduce them as much as possible.

RDAP

RDAP, the Registration Directory Access Protocol, is the technical successor to Whois. As we’ve mentioned previously, Tucows is part of the RDAP Pilot Working Group, which met several times at ICANN63 in Barcelona to supplement the team’s regular weekly online meetings.

Since we’ve participated in the pilot project and already implemented an RDAP service (Tiered Access) for Tucows domain registration data, we’re a step ahead of many other registrars, who still operate solely on the Whois protocol. Using RDAP as the technical back-end allows us to define user access options at a very granular level. We can restrict access by the number of domains a user can query in a given time period, the data elements returned in response, and even which specific domains can be queried. We can also set the specific duration for which a user’s account remains active. These options were not available on the old Whois protocol, which would always return the same results to any query.

Participating in the RDAP Pilot has given us the unique opportunity to provide input towards the RDAP “profile,” which tells registrars and registries what an RDAP domain lookup response needs to look like from a technical perspective. Put another way, the RDAP profile is the technical underpinning that supports ICANN’s registration data policy requirements. We’re working to make sure the final required profile is aligned with what we believe to be legally compliant and appropriate, in accordance with ICANN policy. The draft profile has been released and the comment period is now complete. Currently, the RDAP team is analyzing the comments and considering modifications to the final RDAP profile.  

The other big piece of work remaining for the RDAP team is determining how users will authenticate. There are two main options: OAuth, or using an SSL Certificate to identify the user, although more consideration may determine that the ability to choose one or the other depending on the use case might make the most sense. Whatever option the Working Group settles on, it’s important to keep in mind that this team will not determine who gets access to what data, and when — that’s not within the RDAP Working Group’s scope. Instead, this group is focused on creating the technical mechanisms to facilitate that access, which will need to coordinate with the work from the EPDP and whatever Unified Access Model is ultimately adopted.

Transfer policy changes

The inter-registrar transfer process has changed significantly since personal data has been redacted from the public Whois. This change is formalized within the Temp Spec, and some of the work done at ICANN63 focused on this process.

The TechOps team is working on a proposed new transfer process, which is quite similar to what registrars are already doing post-GDPR. The general goal is to make transfers happen immediately instead of after the current 5-day waiting period, while also protecting the registrant with heightened security requirements. There are some very interesting open questions, such as: Who creates and controls the auth code, should it be the registrar or the registry? Should an auth code have a TTL, essentially a “use-by date”, or should it remain valid indefinitely? In what other ways can the strength and security of an auth code be improved? The team is also considering what an effective emergency transfer reversal process might look like.

In Barcelona, the group present at the TechOps meeting split into smaller work groups, each taking a section of the proposed new process to examine at a very granular level. I led the group working on how the losing registrar might verify the request to get the auth code. The proposal we reviewed allowed a third party other than the registrant to obtain the auth code, such as (for example) when an account holder wants to get the auth code for a domain that’s in their account but registered in someone else’s name.

Our team added in requirements to ensure that the requestor is verified sufficiently to prevent unauthorized transfers; we also opted to keep the notification to the registrant mandatory, ensuring they aren’t surprised by the transfer request and have a chance to contact their registrar if the request was improper. Our group agreed that even when bolstered with increased requirements around verification and notification to reduce the risk of domain hijacking, the option to allow someone other than the registrant to obtain the auth code should only be included in formal policy if there is an expedited transfer reversal process to go with it.

There was a shared dedication among participants in this session to ensuring that any new transfer policy is balanced — it needs to be a streamlined process that’s easy for the registrant to use, while also being secure enough to protect against domain theft.

ICANN Org has now put out a Policy Status Report and has solicited public comments on the transfer policy. Members of the TechOps group have submitted a comment, which will be included in the ICANN Staff Report that is due out on February 1 2019. We don’t yet know exactly how the changes to the transfer policy will unfold, but there’s certainly work to be done on how domain transfers are handled, and we’ll be a part of that work, representing our clients’ best interests.

We’ll keep our resellers posted as the various policy work we’ve discussed today progresses. Overall, we’re pleased with the level of cooperation we’re seeing among all those involved, and encouraged that our registrant-centric approach is being echoed by others working in policy development.