For more than 30 years, the industry has used a service and protocol named WHOIS to access the data associated with domain name and internet address registration activities.

• Do you need to find out who has registered a particular domain name? Use WHOIS.

• Do you want to see who an Internet Protocol (IP) address has been allocated to? Use WHOIS.

WHOIS security concerns

The challenge with WHOIS is that it was designed for use at a time when the community of users and service operators was much smaller and there were fewer concerns about data privacy. Today it’s possible to use WHOIS to collect personally identifiable information (PII), such as physical residence addresses, telephone numbers, and email addresses associated with an individual’s domain name and IP address registration activity. This is a cause for concern in many places where people care about personal privacy, and unfortunately, there’s no easy way to address these concerns using WHOIS because it’s an “all data is available to everyone all the time” service. Thankfully we now have new tools available in the form of the Registration Data Access Protocol (RDAP), which was designed to address the many deficiencies of WHOIS—including the lack of security services needed to provide data privacy.

How do we scale up?

Like WHOIS, RDAP is a client-server protocol. Clients send a command (such as a query for domain name registration information) to an RDAP server, the server receives and processes the command, and if all is well, the server returns the result of processing the client’s command. Unlike WHOIS, RDAP gives servers the ability to vary the amount of information returned in a response based on the client’s identity and the amount of information they are authorized to see. The core RDAP security service protocol specified in RFC 7481 requires server operators to provide basic client identification and authentication services based on usernames and passwords, but this form of client access is unwieldy when clients have to maintain credentials for thousands of servers and server operators have to maintain credentials for millions of clients. A more scalable solution is needed, and can be obtained in the form of a federated authentication service.

Use one credential to access all services

What is federated authentication? It’s a form of authentication in which the parties involved in using and providing a service agree to form cooperating units with third-party identity providers to create, manage and use identification credentials. If you’re familiar with how single sign-on services work you already understand the basic idea. If not, imagine a world in which you can take a username and password issued by one service and use it to access another service because the second service uses and trusts the first service to validate your username and password. It’s a great way to reduce the number of usernames and passwords that you have to acquire and remember!

There are several benefits to using a federated authentication system that makes it an obvious candidate for extending the utility of RDAP, including:

1. It allows clients to use one credential to access a multitude of services.
2. It allows server operators to provide access to clients without having to issue or maintain credentials for every individual user.
3. This type of service exists today and is being used to provide privileged client access to websites.
4. RDAP is itself a web-service protocol that can be extended to use federated authentication services successfully.

Verisign Labs launched an experimental service in February 2016, to demonstrate the viability of a federated authentication system for RDAP based on a protocol called OpenID Connect. OpenID Connect is built on top of the OAuth 2.0 protocol. The approach Verisign is taking is documented in an Internet-Draft document titled, “Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect.” The experiment can be accessed from our website at https://rdap.verisignlabs.com/; click the “Help” link on the homepage for instructions.

Join the experiment

We currently support both authenticated and unauthenticated RDAP queries for domain registration data associated with the .cc and .tv country code top-level domains (ccTLDs). Feel free to try the service using a query for a domain like “nic.tv.” You can experiment with authenticated access using your Gmail or Hotmail username and password.

• You’ll receive a very limited amount of data in response to an unauthenticated query.
• You’ll receive more data if you provide your access credentials.

We don’t return any PII, but hopefully, you’ll see how it’s possible to return more or less information based on client identity. Knowing who the client is allows the server operator to make access-control decisions based on client identity and associated levels of authorization. This information can be used to prevent disclosure of PII to unauthorized clients.

We started our Verisign Labs experiment to demonstrate the viability of an approach, and so far the news has been good. Here are some of the strides Verisign has made to date:

• The ability to use existing open source software to implement the features of OpenID Connect.
• Implemented our own identity provider (again using existing open source software) to demonstrate how clients can share information about themselves with server operators.
• Successfully integrated an identity provider developed by another ccTLD operator, and we’re currently working with Regional Internet Registry (RIR) operators to participate in the experiment and explore how these services can benefit address registry users and operators.

I’m convinced that the technology we need is available to us. Now we need more experimental implementations to help us explore the policies associated with client authorization and access control. The real benefits of a federation can only be realized when a significant number of like-minded users and operators decide to work together. We will all reap the most benefit from RDAP if we find a way to make it easy to access and use our services across operational boundaries.

Get involved

It’s important to note that there is a relatively new ICANN working group that was “tasked with analyzing the purpose of collecting, maintaining and providing access to generic top-level domain (gTLD) registration data and considering safeguards for protecting that data; determining if and why a next-generation Registration Directory Service (RDS) is needed to replace WHOIS; and creating policies, and coexistence and implementation guidance to meet those needs.” While this group’s mandate is limited to the services provided by gTLD registrars and registries, there is a very good chance that the work will also provide benefits to the users and operators of ccTLD and RIR RDAP services.

It’s well worth your time to join the group as either an active participant or observer. Additional information can be found on a wiki maintained by the working group.