A law enforcement investigator, a cybersecurity researcher, and an intellectual property lawyer may each need information about the person or organization behind a domain name. A registrar receiving their requests has a different responsibility: protecting registrants’ data while determining what can lawfully be disclosed. All have legitimate interests. Yet too often they must navigate fragmented procedures, unclear expectations, and repetitive administrative work.

This is not simply a contest between privacy and access. It is an opportunity to build processes that protect both: processes in which Requestors know what information to provide, Data Holders can make well-supported decisions, and everyone can understand how those decisions are reached.

Project Jake, an initiative of the Edgemoor Research Institute, is creating an open-source framework for exploring that opportunity together with the Internet community in general and with Requestors and Data Holders in particular. Its proposition is practical: give the Internet community working tools with which to test ideas, measure their consequences, and improve the implementation of policies established through legitimate governance processes.

Policy Needs an Operational Counterpart

ICANN’s multistakeholder system provides the institutions and procedures for developing applicable domain name policies. Registrars and registries operate within those policies, their contracts, and relevant law. Project Jake contributes something complementary: the mechanisms through which a policy can be translated into a request, a review, a decision, and an auditable record.

The distinction matters. Confirming that someone is an authorized employee of a law enforcement agency does not establish a legal entitlement to non-public data. Equally, a standardized request form does not make every request valid. Authentication, assessment, and disclosure are different functions, often involving different decision-makers. Authentication is verifying who a requestor is and which organization and role they hold, such as confirming that someone works for a law enforcement agency. Authorization is deciding whether that verified requestor is entitled to receive a specific piece of non-public data, so authentication alone does not establish that entitlement. Assessment, the Data Holder’s check that a request meets the applicable legal basis and policy, is separate again from disclosure, the release of the data itself. A standardized request form does not make every request valid. Authentication, assessment, and disclosure are different functions, often involving different decision-makers, and unclear boundaries between them are where current processes tend to leave gaps. Project Jake offers a way to test how to make those boundaries more transparent and consistent, while responsibility for policy and disclosure stays where it currently sits.

Rather than predetermining a policy outcome, Jake lets stakeholders examine how several approaches might work. Can verified organizational affiliation reduce repetitive checks? Which information in a request genuinely assists a registrar? Where can automation help, and where is human judgment essential? These questions benefit from a working prototype rather than speculation alone.

A shared test environment can contribute at every stage. Before policy development, it can document stakeholder needs and distinguish shortcomings in existing rules from problems in existing procedures. During deliberations, participants can compare alternatives against the same operational criteria: time, cost, consistency, security, and administrative burden. After adoption, configurable applications can turn requirements into workflows and generate evidence about their actual effects. This feedback can help policymakers refine implementation without confusing a successful technical demonstration with a policy decision. Independent experiments must also be evaluated critically: a pilot involving a few motivated participants does not automatically represent every registrar, Requestor, or jurisdiction. Its value comes from what it teaches, not from an assumption that it proves universal feasibility.

Agreements Make Expectations Visible

The Jake Framework organizes cooperation through Agreements between Requestor Groups and Data Holder Groups. A Requestor Group might represent a law enforcement organization, an intellectual property practice, or another defined community. A Data Holder Group enables participating registrars, registries, or other Data Holders to publish and manage the conditions under which requests will be considered.

An Agreement can specify recognized purposes, required justification, supporting evidence, permitted uses, confidentiality conditions, and accountability arrangements. Requestors gain clarity before submitting. Data Holders receive more complete and consistent submissions, potentially reducing clarification cycles and processing costs.

Importantly, these Agreements operate within applicable law, ICANN requirements, and the individual Data Holder’s authority. They complement and operationalize the existing and agreed-upon process; they do not confer an independent right to disclosure. An Agreement can help a registrar assess a request, while the registrar retains responsibility for deciding what, if anything, may lawfully be released.

The framework also distinguishes institutional roles. Requestor Group Administrators manage users, affiliations, and permissions. Data Holder Group Administrators publish and administer Agreements. Individual Data Holders evaluate requests and make disclosure decisions. This division supports trust without blurring accountability.

A Practical Suite, Not Just a Concept

Project Jake is implementing this model through four open-source applications. Jaddar helps Requestors prepare, submit, track, and record requests. Jareg supports Data Holders in reviewing and processing them. Jadmin manages Requestor Groups, their users, roles, and Agreement relationships. Jaremin supports Data Holder Group administration and the publication and management of Agreements.

The architecture is modular and distributed. Participating organizations can explore hosted services or components deployed in their own environments, subject to suitable security and interoperability arrangements. The software is in Alpha testing, with a Beta release envisaged for early 2027. Some functions are operational interfaces; others are still being developed and tested. That is precisely why participation now is valuable: early users can help establish what works before the design becomes fixed.

Building on ICANN’s RDRS

ICANN’s Registration Data Request Service (RDRS) is an important step toward more consistent handling of requests for non-public gTLD registration data. It provides a common route for submission and tracking to participating registrars. The registrar, not RDRS, assesses whether disclosure is appropriate; the service is not the channel through which the non-public data itself is delivered.

Project Jake can build on this infrastructure. In September 2026, Jake announced an interface enabling Jaddar users to submit requests through RDRS and receive and display registrar responses. That is a concrete example of interoperability: a Requestor organization can use its own tools to manage users, prepare requests, and maintain records while relying on RDRS for the functions it already provides.

The potential benefits extend beyond that interface. Jake can help test richer identity and affiliation information, more complete request templates, reusable organizational arrangements, and Data Holder-side workflow support. None requires assuming that ICANN must operate every component or that every Data Holder must adopt the same software. The objective is to discover which division of functions delivers a reliable, economical, and accountable service.

The ICANN Board’s March 2026 decision to continue RDRS operations through November 2027 provides valuable space for such practical learning.

Informing the Next Stage of SSAD

The future of standardized access and disclosure remains an active policy question. On March 12, 2026, the ICANN Board decided not to adopt the original 18 recommendations for the System for Standardized Access/Disclosure (SSAD), instead setting in motion work on Supplemental Recommendations informed by RDRS experience. As of this writing, the team’s schedule anticipates public comment beginning on November 10, 2026, and recommendations to the GNSO Council by March 2027.

This creates a timely opportunity to connect policy discussion with experiments. The questions raised by SSAD—how to establish Requestor identity, communicate organizational roles, document justification, safeguard information, and control costs—closely match the functions Jake is designed to explore.

Law enforcement authentication offers an especially useful example. ICANN’s Registration Data Policy includes a response requirement of no more than 24 hours, subject to specified exceptions, for qualifying urgent disclosure requests from authenticated Requestors. Enforceability of those urgent-request provisions depends on an appropriate authentication mechanism. ICANN is examining options, with proof-of-concept testing planned from December 2026.

Jake’s Requestor Group model offers one candidate for collaborative testing: an agency verifies an officer’s affiliation and role, Jaddar helps prepare a structured request, and the receiving Data Holder evaluates it under the applicable rules. The experiment would not treat authenticated identity as permission to disclose. It would examine whether reliable identity information can be conveyed securely, recognized appropriately, and used to make the lawful assessment more efficient.

Three Experiments Worth Undertaking Together

The immediate agenda can be focused and measurable.

First, test RDRS interoperability with real users. Examine submission quality, status updates, response presentation, error handling, and recordkeeping. Identify which tasks are best performed by RDRS and which belong within Requestor or Data Holder organizations.

Second, compare authentication and assurance approaches. Test how organizations verify individuals, affiliations, and roles; how credentials are trusted across institutional boundaries; and what standards or governance arrangements would be required for wider recognition. Law enforcement is one obvious setting, but the lessons could extend to other Requestor communities.

Third, evaluate Data Holder-controlled workflows. Test whether published Agreements, configurable review procedures, and sensitivity-based controls reduce repeated effort while preserving appropriate confidentiality, purpose limitations, security, and auditability. The ongoing cooperation with TWNIC provides a setting for examining parts of this model.

Success must be measured in both directions. Fewer delays and lower costs are worthwhile only if the system also sustains, or improves, protection of registrants’ information. Trials should document exceptions, failures, and limitations as carefully as successful results. Confidentiality needs similar care. In some cases, notifying a registrant may be appropriate; in others, it could undermine a lawful investigation. Notification options, data sensitivity classifications, and disclosure scope therefore need to reflect applicable rules and the circumstances of each request, not a single software default. Open source makes independent scrutiny possible; effective interoperability will also require agreed interfaces, secure deployments, ongoing maintenance, and clear responsibilities.

An Invitation to Build Evidence Together

Internet governance works best when policy and implementation inform each other. Too often a community reaches agreement on principles only to discover later that implementation is costly, inconsistent, or unexpectedly complex. Prototypes and pilots make those consequences visible while there is still time to respond.

Project Jake offers a collaborative environment for that iterative approach. ICANN and other competent authorities remain responsible for policy. Data Holders remain responsible for lawful disclosure. Researchers, Requestors, registries, registrars, and technical experts can work together to explore the operational choices—and bring evidence back to the policy discussion.

The Alpha stage offers an unusually useful moment for that cooperation. Stakeholders can contribute test cases, examine real workflows, identify operational gaps, and help determine which features deserve priority. The resulting knowledge can benefit the wider community even where participants ultimately choose different technical solutions.

The next step is therefore an invitation, not a request for endorsement: test the framework, challenge its assumptions, compare alternatives, and share what you learn. By turning policy questions into practical experiments, the community can build a more predictable, privacy-respecting, and sustainable approach to domain registration data disclosure.

For an extended version of the article see: https://www.edgemoorresearch.org/article-collaborative-pathway/

The author would like to thank Dr Stephen D. Crocker, and Jake Fellow Sunčica Rosić for their valuable input to the article.