A service and protocol named WHOIS, which is used to access certain data associated with registered domain names and Internet addresses, currently makes it possible to access personal information about individual registrants, such as the registrant’s physical address(es), telephone number(s), and email address(es).
Personal data privacy concerns arising from open access to personal data provided by the current WHOIS service and protocol is currently the subject of extensive discussion within (and outside) the ICANN community, and unfortunately, there’s no easy way to address these concerns directly with the currently deployed WHOIS model because that WHOIS model is primarily an ‘all data is available to everyone all the time’ service.
Thankfully, we now have protocols and tools available in the form of the Registration Data Access Protocol (RDAP), which includes support for access controls that may offer a potential solution that balances the necessitated access and privacy concerns.
How do we scale up?
Like WHOIS, RDAP is a client-server protocol. Clients send a command (such as a query for address 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 server operators 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. Some people describe this as ‘tiered access’.
The core RDAP security service protocol specified in RFC7481 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 make it an obvious candidate for extending the utility of RDAP, including:
- It allows clients to use one credential to access a multitude of services.
- It allows server operators to provide access to clients without having to issue or maintain credentials for every individual user.
- This type of service exists today and is being used to provide tiered client access to websites.
- RDAP is itself a web-service protocol that can be extended to use federated authentication services.
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 (I-D) 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 home page for instructions.
Benefits for end users and operators
‘Tiered access’ doesn’t mean ‘no access’ for users with legitimate use cases as defined by data protection authorities. An OAuth-based system allows end users to work with an identity provider who knows who they are and can vouch for their need to access data, and it allows server operators to make access control decisions based on information provided and verified by these trusted identity providers. For example, an identity provider can be created to issue credentials to law enforcement users.
Another identity provider can issue credentials to network operators. Server operators who recognize these identity providers can use these credentials to provide access to data based on the identity of the verified end user and the purpose of their query.
Server operators are often asked to provide high-volume query access to registration data. Unfettered, high-query volumes can put a strain on server-side resources, but server operators can make dynamic access control decisions if clients can be identified and authorized. Clients that operate within the server’s terms of service can receive the access they need, and abuse can be mitigated.
Join the experiment
Verisign currently supports 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 a Gmail or Hotmail username and password. Note:
- 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 contact information because .cc and .tv are both ‘thin’ registries, but hopefully, you’ll see how 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 help prevent disclosure of data to unauthorized clients.
We started our Verisign Labs experiment to demonstrate the viability of this approach, and so far, the news has been good. Here are a few of our findings:
- Existing open source software can be used to implement the features of OpenID Connect.
- Existing open source software can be used to implement an identity provider that allows clients to share information about themselves with server operators.
- Identity provider integration is easy and straightforward (we support providers developed by Google, Microsoft, and a ccTLD registry).
The technology we need is available to us. We’re currently working with RIR operators to participate in the experiment and explore how these services can benefit address registry users and operators.
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 can drive learnings that provide a balanced solution that keeps the Internet trustworthy and Internet end users safer by balancing the need for personal privacy and for data access.
Scott Hollenbeck is senior director of Verisign’s Innovation Lab. He has developed expertise in the Domain Name System, applications programming, systems architecture, network engineering, information security, financial analysis and personnel management.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.