Project Jake is named after Elizabeth “Jake” Feinler.

When you register a domain, you’re entering a maze of over 100 data fields. This information, initially meant for basic administrative tasks, has grown into a trove of data that can be misused. The old WHOIS protocol used to manage this, but it failed to keep up with evolving privacy laws, complex business models, and conflicting regulations. The result? An outdated system where personal data is exposed or hidden without proper control, leading to misuse and unnecessary headaches for everyone involved.

Understanding the Core Challenge
The main hurdle is aligning the needs of three key groups:
1. Registrants: The people or companies registering domains.
2. Requestors: Those needing access to registration data (e.g., law enforcement, researchers).
3. Data Holders: The organizations that store this data, such as registrars, registries, and privacy service providers.
________________________________________
The Data Holders’ Dilemma
Data Holders must balance many responsibilities. They handle DNS records that are public while guarding private data for their clients. When they receive a data request, they need to figure out if it’s legitimate, legal, and safe to fulfill it—while avoiding liability. They also must ensure that, if they do share the data, the Requestor handles it responsibly.
________________________________________
The Requestors’ Frustrations
Requestors have an important role in holding people accountable online, but they often run into dead ends. They face long, complex processes, only to be denied access to data because of privacy protections, proxy services, or inaccuracies. This creates a lot of frustration when their needs are legitimate.
________________________________________
Registrants expect their privacy and security to be respected. When their data is shared, they deserve to know why, how, and under what conditions. Special protections should be in place for vulnerable groups.
________________________________________

The collection and disclosure of DNS registration data evolved in an unplanned fashion over several decades. The disclosure function was implemented via the Whois protocol.

Whois data was used by a wide variety of requestors for an equally wide variety of purposes. Some of these purposes were troublesome to registrants, e.g. spam, harassment, fraud attempts, etc. In response, many registrants submit fake contact data or used privacy or proxy services to cloak their contact data. The resulting system served all parties poorly.

In the last several years, several jurisdictions have imposed general privacy regulations. The EU’s General Data Protection Regulation (GDPR) is the most visible and the most stringent of these. In response, most DNS Registrars have severely limited the data they make available publicly, and each Registrar has established its own procedures for evaluating requests for non-public data.

Although the current situation has improved privacy protection for Registrants, it is far from satisfactory. The broad emphasis on privacy has enabled bad actors to hide their identity. Further, the current system is expensive for Registrars and Registries, and it is chaotic and often ineffective for Requestors with legitimate needs for registration data.

In Project Jake we have been developing a framework designed to help all parties develop and implement policies which protect Registrant privacy and meets the needs of the Registrars, Registries and Requestors with legitimate needs.

The guiding principles behind this work are:

• Separation of mechanism from policy
• Support for multiple policies
• Clarity and predictability of Policies
• Efficiency

Collection and Labelling of Registration Data

• In principle, when data is collected during the registration process, each data element is assigned a sensitivity level and a validation level. (Four levels of each.)
• For existing registration databases, these values are inferred.
• The sensitivity level is used during the disclosure process. Disclosure depends on both the sensitivity level and the Requestor’s authorized access level

Collection and Disclosure

• Jake consists of a Collection Process and a Disclosure Process
• At Collection time, each data element is assigned sensitivity and validation levels
• At Disclosure time, the Requestor’s Access Level is compared to each data element’s sensitivity level
•  

Disclosure process

• Authorized requests are based on pre-defined request-types
• Purpose, Access level, etc.
• The Data Holder selects the data elements associated with the requested domain name, filtered in two dimensions
• Only data elements in the list of expected data elements
• Only data elements whose sensitivity level is less than or equal to the request-type’s Access level.
• Redaction rules are then applied

Requestor and Data Holder Groups

• For efficiency, Requestors and Data Holders each form groups
• Each group has an Administrator
• Administrators…
• Add/remove members and bind them to the rules of the group
• Enter into Agreements
• Provide recourse in case of reported problems

Agreements

• An Agreement between a Requestor Group (RqG) and a Data Holder Group (DHG) sets forth the terms and conditions for a Requestor to obtain registration data from any of the Data Holders.
• An Agreement includes location of Requestor Group’s Identity server and one or more request-types.
• Operation of Requestor Group’s Identity server must be acceptable to Data Holder Group
• Each request-type specifies the purpose, the maximum access level, the expected data elements, and the required and optional request parameters.

Illustrative Law Enforcement Group Agreement

• Limited to defined law enforcement purposes and specific countries, jurisdictions, etc.
• Data Holder Group decides if LEA Requestor Group is acceptable
• Request-types
• Pre-UDRP investigation
• After UDRP is in progress
• Data Holder makes decision on each request whether to decline, review or respond quickly

Illustrative Intellectual Property Group Agreement

• Limited to defined IP purposes and specific countries, jurisdictions, etc.
• Data Holder Group decides if IP Requestor Group is acceptable
• Request-types
• During an investigation
• With warrant or equivalent
• May include declaration of exigent circumstances
• Data Holder makes decision on each request whether to decline, review or respond quickly

At the center of Project Jake’s current work is JADDAR (Jake Domain Data Requestor) — an engineering framework that enables secure, policy-aligned access to non-public DNS Registration Data.

JADDAR:

• Supports modern identification, authentication, and authorization mechanisms
• Operates under local policy control by registries, registrars, and governing authorities
• Enhances clarity, auditability, and accountability
• Preserves privacy while enabling legitimate data requests

The objective is practical: reduce fragmentation while respecting evolving legal obligations and jurisdictional requirements.

Requestor Software Architecture

• RqG operates an OpenID server
• Requestors are registered on the server
• RFC 9560 token-based session option is used
• Each Requestor uses a persistent Requestor process to initiate requests and receive responses.
• JADDAR is ERI’s initial Requestor software
• Protocols are open. Others may build their own software
• Requests are sent to Data Holder’s RDAP server
• RDAP server responds quickly with either the response or “later.”
• Requestor software obtains response when it is ready.

Not every player in this ecosystem has the same rules. Our model allows each party—like Registrars and Registries—to set ranges of acceptable values for things like data collection and sensitivity. This flexibility ensures that different policies can coexist while still working together.

• Research and Insights: Project Jake’s research findings on data privacy, protection, and governance likely inform ICANN’s policy discussions, especially in balancing privacy concerns with the need for transparency in domain ownership.
• Policy Influence: If Project Jake involves studying the impact of regulations like GDPR on domain data policies, its insights could directly impact how ICANN approaches policy changes, including the design and implementation of frameworks like the Registration Data Access Protocol (RDAP).
• Stakeholder Collaboration: Both Project Jake and ICANN involve multi-stakeholder approaches, bringing together researchers, policymakers, and industry players. The outputs of Project Jake could be used by stakeholders within ICANN to advocate for specific policy positions.

In summary, the relationship lies in the intersection of research (Project Jake) and policy-making (ICANN’s PDP), particularly concerning the regulation of domain registration data in an era of increasing privacy concerns.

Toggle Content