Project Jake: A Collaborative Pathway from Policy to Practice

How an independent, open-source framework can strengthen ICANN’s RDRS and inform the future of standardized access to domain registration data

An Internet governance perspective | November 2026

Access to non-public domain registration data presents an opportunity to advance privacy protection and effective disclosure together. Better mechanisms can protect privacy while making legitimate requests more consistent, accountable, and practical to handle. Project Jake, an initiative of the Edgemoor Research Institute, is creating an open-source environment in which that opportunity can be explored collaboratively. By helping policymakers and participating organizations test alternatives and put duly established rules into operation, Project Jake connects policy objectives with practical experience while respecting ICANN’s multistakeholder processes and the authority of those responsible for disclosure. This contribution is particularly timely as ICANN evaluates its Registration Data Request Service (RDRS) and revisits the future of standardized access and disclosure.

A shared opportunity for the ICANN community

At ICANN87 in Bali, Project Jake engaged with Requestors, Data Holders, and representatives of the wider ICANN community. Constructive discussions highlighted a shared opportunity: to explore how an independent, open-source project can help translate domain registration data policies into effective operational mechanisms while working in step with ICANN’s established policymaking and implementation processes.

That opportunity builds on the strengths of Internet governance: legitimate institutions, transparent procedures, and meaningful participation by stakeholders with diverse interests. By making the boundaries of policy authority and operational responsibility explicit, collaborative technical experimentation can support accountability and give registrars, registries, Requestors, and registrants greater clarity about how proposed approaches would work in practice.

Project Jake builds on a clear division of roles. Policy and mechanism are complementary, with distinct responsibilities. Policy establishes what is permitted, required, or prohibited, and who has authority to decide. A mechanism provides the processes, software, controls, and records through which those decisions can be applied. A request form structures a submission without granting a right to obtain personal data. Verifying the identity of a police officer provides assurance about credentials while leaving the lawfulness of disclosure to the responsible authority. Software can streamline the handling of decisions while leaving underlying policy with its authorized decision-makers.

The distinction is central to Project Jake’s purpose. The project seeks to make governance decisions more informed and their implementation more effective, within the established governance framework. It can support several policy approaches within the same framework, demonstrate how alternatives perform, and help identify consequences that may not be obvious in a policy discussion. The choice among those alternatives remains with the appropriate policymaking authorities.

Building a workable balance for registration data disclosure

For many years, access to information associated with domain name registrations was treated largely as an information-retrieval problem. The central challenge today is more demanding. Non-public registration data may be important to a legitimate investigation, but it may also contain personal information that requires protection. The same data can have different implications depending on who requests it, why it is requested, and how it will be used.

Consider the interests involved. Registrants have a legitimate expectation that personal information will not be exposed unnecessarily or used for inappropriate purposes. Law enforcement agencies may need timely information when investigating serious harm. Cybersecurity professionals may seek to identify actors behind abusive infrastructure. Intellectual property representatives may need evidence to pursue infringements. Researchers and other public-interest Requestors may have well-founded inquiries. Registrars and registries, meanwhile, must assess requests in accordance with applicable laws, contracts, and policies while managing operational burdens and legal risk.

That complexity has practical costs. Requestors can be uncertain about where to send a request, which supporting information is needed, or why an apparently similar request received a different response. Data Holders may devote significant staff time to checking identities, interpreting incomplete submissions, requesting clarification, and documenting decisions. Repeating the same checks for each new request or organization is inefficient. The opportunity is to make necessary checks more efficient while preserving the safeguards on which responsible disclosure depends.

Project Jake’s working proposition is that much of this friction can be reduced while leaving substantive policy questions with the authorities responsible for them. Reliable identity information, well-structured requests, reusable Agreements, configurable rules, and auditable processes can improve the machinery of disclosure. These mechanisms preserve the need to determine what lawful disclosure requires in each case, while creating conditions for more consistent, better-informed decisions.

Complementary roles: policy development and implementation

Within ICANN, policy responsibilities are exercised through established institutions and processes. Supporting Organizations develop policy recommendations in their areas of responsibility, with input from Advisory Committees and the broader community. The ICANN Board acts within its defined responsibilities, and ICANN organization coordinates the implementation of applicable decisions. Contracted parties also remain subject to their contractual commitments and relevant law.

Project Jake operates alongside ICANN’s policymaking institutions as an independent research and technical initiative. Approval of ICANN consensus policies, determination of legal grounds for disclosure, and any instructions to registrars remain with the authorities responsible for those matters. Authentication capabilities developed through Jake become mandatory criteria for ICANN participants only if adopted through appropriate processes. Voluntary Agreements remain subject to privacy law, and each Data Holder retains the responsibility to assess requests and determine whether disclosure is lawful.

Jake’s distinctive contribution is to make policy options concrete. Stakeholders can examine a prototype that verifies individual identities, organizational affiliations, and roles to inform discussion of stronger authentication. They can test whether common request templates actually reduce clarification cycles and costs. They can also explore which steps are appropriate for automation and which require human or organizational review.

Technical design is never entirely neutral. Choices about default settings, available controls, data retention, or the visibility of decisions can influence outcomes. Project Jake therefore seeks to document its assumptions, expose significant design choices to scrutiny, and allow policies to be configured with their consequences visible. This makes engineering accountable to governance and allows technical choices to be examined openly by the institutions and communities they serve.

Evidence before, during, and after policy development

One of the most valuable opportunities in Internet governance is to test how proposed requirements will work before they are widely adopted. A policy can appear straightforward in principle but turn out to involve large costs, difficult integrations, inconsistent implementation, or unintended consequences. Conversely, a requirement that seems impractical may become manageable once a technical design is demonstrated.

Project Jake can assist at three points in that cycle. Before a policy is adopted, research can identify stakeholder needs, existing practices, legal and operational constraints, and possible approaches. Evidence can reveal whether a problem arises from the policy itself or from the way requests are handled. That distinction can prevent a community from trying to solve an implementation problem through unnecessary policy complexity.

During policy development, prototypes and pilots can make competing proposals testable. Different authentication methods, Agreement structures, request templates, or response workflows can be compared against common criteria. Does the approach reduce the amount of information a Requestor must resubmit? Does it improve Data Holder confidence? Is the additional administrative cost proportionate? Can exceptions be handled without turning the whole process into manual work? Such questions are easier to answer when there is an operating model to examine.

After a policy decision, configurable applications can support implementation while generating operational feedback. Data Holders and Requestors can learn where delays occur, what information is frequently missing, and which review steps are costly or effective. Policymakers can then consider adjustments on the basis of experience, rather than relying entirely on predictions made before deployment.

This is consistent with the broader purpose of operational and design assessments within ICANN: understanding feasibility and consequences while respecting the authorized decision process. Jake’s contribution is independent, supplementary evidence for those responsible for making decisions. Pilot participation does not constitute ICANN approval, and results should be evaluated for representativeness, reliability, and possible limitations.

Agreements are the bridge between rules and operations

The central organizing idea of the Jake Framework is an Agreement between a Requestor Group and a Data Holder Group. Requestor Groups bring together people or organizations with a shared operational context, such as a law enforcement agency, an intellectual property practice, or another defined community of Requestors. Data Holder Groups enable participating registrars, registries, or other relevant holders to publish and manage the conditions under which requests may be considered.

An Agreement makes applicable conditions visible in advance. It can describe recognized request purposes, information requirements, permitted uses, confidentiality expectations, supporting evidence, and accountability arrangements. The participants can then configure their applications to prepare and process requests against those conditions. For Requestors, this means fewer surprises about what a submission must contain. For Data Holders, it creates an organized basis for reviewing recurring categories of requests.

An Agreement creates operational clarity within the existing legal framework. Its provisions remain subject to applicable law, ICANN contractual obligations, and any binding policies. A template or Agreement cannot by itself justify disclosure of protected information, and participation by a Requestor Group leaves intact the duty to examine the circumstances of an individual request whenever that examination is required.

This is why the framework separates group administration from individual decisions. The Requestor Group Administrator manages members, affiliations, roles, and their relationships to Agreements. The Data Holder Group Administrator manages the publication and administration of relevant Agreements on the holder side. The individual Data Holder retains responsibility for lawful disclosure. In other words, the system can establish a trusted process without transferring legal responsibility away from the party that holds the data.

Project Jake also contemplates Data Holder-defined sensitivity classifications, including a four-level model described in the project’s introductory material. Such classifications can help organize different categories of information and support proportionate controls. They are not a substitute for legal analysis: the applicable policy and law determine how sensitivity is assessed and what follows from it. The operational framework makes those choices more explicit and manageable.

Imagine an intellectual property firm with an established relationship to a participating Data Holder Group. Its authorized staff could use a relevant Agreement to prepare a request that identifies the domain name, the purpose of the inquiry, the legal or factual basis offered, the information sought, and any applicable confidentiality requirements for a single or multiple inter-related inquiries. The receiving Data Holder would have a more complete and standardized record to examine. It could still request clarification, approve a lawful disclosure, make a limited disclosure, or decline the request as appropriate.

That example illustrates the value of the Agreement model. It standardizes preparation and processing, not the ultimate substantive result. Its value is a more predictable and accountable route to a decision, with disclosure still determined by applicable rules and circumstances.

The Jake Applications Suite in practice

Project Jake translates its framework into an open-source set of applications that can support different participants in the request-and-disclosure process. The applications have distinct functions, reflecting the separation between requesting, administration, and Data Holder decision-making.

Jaddar is the Requestor-facing component. It helps a Requestor prepare, submit, track, and record requests using the relevant forms and Agreements. By organizing the information at the point of submission, it can improve the quality and consistency of requests before they reach a Data Holder.

Jareg supports Data Holders. It is intended to help them review requests against configured requirements, manage the processing workflow, and document the response. Its role is operational: it provides information and structure for decisions that remain subject to the Data Holder’s responsibilities.

Jadmin is the Requestor Group management application. It supports the administration of users, organizational affiliations, roles, permissions, and Agreement relationships. Group-level identity management is significant because a Requestor’s authority to act for an organization may be as important as proof of personal identity.

Jaremin serves Data Holder Group Administrators. It supports group administration, publication and management of Agreements, and related approval processes. In combination with Jadmin, it creates a structured pathway for relationships between the groups to be established and maintained.

The architecture is distributed and configurable. Participating organizations may be able to use appropriate components within their own operational environments rather than depend on a single centrally operated application. The open-source approach also permits inspection, testing, adaptation, and contributions from different communities. Sound deployments, secure configurations, maintenance, and practical interoperability are essential to realizing those benefits.

The suite is in Alpha testing, with a Beta release planned for early 2027. Some capabilities are already working interfaces; others are designs or functions to be tested and improved. This development stage provides a practical opening for collaborative evaluation and refinement.

RDRS provides an important starting point

ICANN’s Registration Data Request Service addresses a specific operational need: a standardized means of submitting and tracking requests for non-public gTLD registration data to participating registrars. It offers a common point of entry in an environment where Requestors have often had to navigate different registrar procedures. It also gives ICANN and the community practical experience with the demand for requests, their handling, and the issues that arise.

RDRS provides the shared route through which requests are submitted and tracked. Participating registrars assess disclosure according to their obligations and applicable standards, while any delivery of non-public personal data takes place outside RDRS. This division of functions combines a standardized point of entry with the continuing responsibility of each registrar for disclosure decisions.

The original RDRS pilot concluded in November 2025. The ICANN Board subsequently directed continued operations while the community addressed longer-term policy questions. Its March 12, 2026 resolutions referred to the operational extension running through November 2027. RDRS therefore remains relevant not merely as an experiment, but as a service that can inform and support the next stage of work.

Project Jake approaches RDRS as a partner in that practical task. The two systems address overlapping but different layers. RDRS supplies a standardized route to participating registrars. Jake adds a framework for managing Requestors, validating affiliation and roles, structuring requests, administering Agreements, and assisting Data Holders with their internal workflows by providing a structured pathway for receiving responses.

A working interface demonstrates collaboration

This complementarity is not only conceptual. In September 2026, Project Jake announced that Jaddar had gained an interface to RDRS. The interface allows requests to be submitted through RDRS and enables Jaddar to receive and display registrar responses. Project Jake invited active RDRS users to help test the function.

For a Requestor organization, that can create a practical division of labor. Its members work in Jaddar, where request forms, user management, internal records, and relevant Agreements can be maintained. When a request is directed through RDRS, the organization can use the existing ICANN service without abandoning its own operational environment. Information about the request and response can be brought back into its workflow, subject to the actual interface’s capabilities and configuration.

The integration preserves a clear division of responsibility. Registrars continue to review requests, participation in a Jake Agreement does not guarantee disclosure, and RDRS remains a service for routing and tracking rather than exchanging non-public data. Disclosure communications and any delivery of information continue outside RDRS under the applicable process.

The RDRS interface is a concrete example of Project Jake supporting existing ICANN infrastructure within the current policy framework. The interface uses an authorized channel and assists the Requestor’s workflow. Any additional functions touching authentication, acceptance criteria, or disclosure conditions would still need to conform to the relevant rules and, where necessary, be separately recognized by ICANN or participating Data Holders.

Five practical contributions to RDRS

The first contribution is better Requestor identity information. Requestor Groups can verify individuals and their organizational affiliations, then manage roles and credentials through designated administrators. A registrar receiving a request from an agency could potentially benefit from assurance that the person submitting it genuinely belongs to that agency and is acting in a recognized capacity. The usefulness of that information depends on the assurance model and whether the registrar or relevant system trusts the verification method.

The second is more complete requests. Configurable forms linked to Agreements can prompt for purpose, justification, requested data, supporting information, and relevant safeguards. Although approval remains subject to the Data Holder’s assessment, a well-prepared request is less likely to stall because essential details are missing. Standardized submissions may also make it easier for Data Holders to compare similar requests and explain their decisions.

The third is reusable organizational arrangements. Many Requestors repeatedly approach similar types of Data Holders for similar reasons. When relevant conditions have been documented in advance, administrators need not reconstruct the entire process for every request. This can be particularly helpful for larger Requestor organizations with many users, or for Data Holders receiving substantial volumes of routine inquiries.

The fourth is support for Data Holder operations. Jareg and Jaremin offer a model for administering policies, Agreements, validation steps, and request handling on the receiving side. These functions could complement a registrar’s existing procedures. This offers opportunities for future integration, while Jake’s Data Holder software remains separate from RDRS today.

The fifth is improved cost control and accountability. Reusable forms, consistent records, automated preliminary checks, and clearer workflows may reduce repetitive effort. Because the system can preserve information about who submitted a request, under which Agreement, and how it was handled, it can also make later review more effective. Pilots can establish the scale of these cost and accountability benefits empirically, rather than relying on assumptions about software alone.

From the original SSAD to Supplemental Recommendations

The question of what follows RDRS is part of a longer ICANN discussion. The original System for Standardized Access/Disclosure proposals envisioned functions beyond request submission, including more elaborate arrangements for authentication and operational safeguards. That ambition brought important questions of feasibility, cost, responsibilities, and implementation into focus.

On March 12, 2026, the ICANN Board decided not to adopt the original package of 18 SSAD recommendations. The decision opened a new phase of work on these continuing challenges, initiating a process for the GNSO to develop Supplemental Recommendations informed by RDRS experience and the community’s subsequent analysis. The goal is to revisit the requirements for RDRS or a successor system in light of what has been learned.

As recorded in the September 29, 2026 meeting notes of the SSAD Supplemental Recommendations Team, the working schedule anticipated opening a public comment period on November 10, 2026 and delivering recommendations to the GNSO Council by March 2027. These were planned milestones at the time of writing, not completed events. Their significance is that the discussion has a concrete near-term policy horizon.

Project Jake can provide a useful test environment for elements of that discussion. Its framework addresses functions that have featured prominently in SSAD-related work: Requestor identification and affiliation, validation of organizational roles, structured submissions, defined processing conditions, Data Holder decision support, audit records, and operational efficiency. The framework therefore offers a test environment, rather than a claim of compliance with every original SSAD recommendation or with requirements still under development.

Through practical experimentation, Jake can make proposed requirements intelligible and testable. If the community considers several methods for communicating verified identity, the project can investigate how they might work within existing Requestor organizations. If a proposal requires a particular record of justification or an audit trail, a pilot can assess the burden of collecting and maintaining that information. If different implementations create different costs or risks, those differences can be documented for the policy discussion.

A future standardized access and disclosure arrangement need not assume that every function must be delivered by the same operator. The policy community can define requirements for trust, interoperability, safeguards, and accountability while leaving room for technically different ways to satisfy them. That prospect is central to Project Jake’s relevance.

Authentication and disclosure authorization: distinct, complementary steps

A central design principle for reliable access mechanisms is the distinction between authentication and disclosure authorization. The SSAD Supplemental Recommendations Team explicitly addressed it in September 2026. Authentication can establish a person’s identity, organizational affiliation, and the capacity in which that person is acting. It does not, by itself, establish that a Data Holder may lawfully release the requested information.

Even the word authorization can refer to different things. An agency may authorize an employee to submit a request on its behalf. That internal authority must be supported by evidence of the individual’s official role, while the registrar’s decision to disclose remains a separate act. Those are separate acts, governed by different responsibilities.

Project Jake’s group model makes that separation visible. A Requestor Group Administrator can attest to a member’s affiliation and role. A Data Holder Group Administrator can manage Agreements describing the conditions under which requests are to be considered. The individual Data Holder applies the relevant law and policy to decide what, if anything, can be disclosed. A pre-existing Agreement can simplify that assessment, but it cannot substitute for it.

This division of responsibilities can improve both privacy and efficiency. Stronger assurance about the Requestor can reduce uncertainty at the first stage of processing. Clearer request information can improve the second stage. Recording the applicable Agreement and final decision can support review at the third. Each stage answers a different question, and a reliable system should not confuse them.

This division of responsibilities also identifies the conditions for trusted interoperability. A Jake credential would become an ICANN-recognized credential only through agreed assurance standards, technical interoperability, governance arrangements, and testing. Similarly, automated workflows must rely on valid decision rules, appropriate configuration, and necessary oversight to support lawful outcomes.

Law enforcement offers a valuable pilot opportunity

The law enforcement context makes these issues particularly concrete. Agencies need to establish that a Requestor is a genuine officer, belongs to a recognized organization, and is acting within an appropriate role. Registrars need confidence in those claims, especially when a request is presented as urgent. Reliable disclosure decisions also require an assessment of the circumstances and legal basis for the requested information.

In May 2026, ICANN published additions to its Registration Data Policy addressing urgent requests for lawful disclosure. The provisions include a response timeline of no more than 24 hours, subject to specified exceptions, for qualifying urgent requests from authenticated Requestors. The policy’s urgent-request provisions are not enforceable until an appropriate law enforcement authentication mechanism is implemented. That dependency makes the technical design of authentication especially consequential.

ICANN has established work to explore law enforcement authentication mechanisms, with proof-of-concept testing planned to begin in December 2026. This work is intended to assess operational and technical approaches that could support RDRS or a successor service. This technical exploration proceeds alongside, rather than in place of, policy development.

Project Jake offers a practical model for testing how a law enforcement organization can manage members through a Requestor Group, check identities and roles, and prepare requests through Jaddar. A Data Holder could receive structured information about the Requestor alongside the justification for the request. The practical question for testing would be whether such information can be conveyed securely, evaluated reliably, and trusted under an agreed framework.

Efficiency and safeguards can advance together

A sustainable access mechanism must work for those who operate it. Reducing repetitive manual checks, inconsistent documentation, and repeated correspondence can help legitimate Requestors receive timely responses and Data Holders manage administrative costs. Operational simplicity and economic sustainability are therefore essential to a durable policy solution.

Project Jake’s distributed model aims to reuse trusted arrangements where appropriate. Requestor organizations can maintain their own membership records. Data Holder Groups can publish reusable Agreements. Requestors can prepare structured submissions. Data Holders can apply configured rules and keep relevant records. For repeatable tasks, automation may reduce work that adds little value when performed again and again.

Project Jake pairs opportunities for automation with the safeguards essential to responsible disclosure. Access controls, purpose limitations, appropriately scoped disclosure, confidentiality measures, logging, secure handling of credentials, and mechanisms for review remain essential. The project’s sensitivity-based approach can help Data Holders differentiate handling requirements, but those controls must reflect applicable obligations rather than override them.

Transparency also requires careful design. The system should make processing understandable and accountable without exposing information that must remain confidential. In some situations, notifying a registrant may be appropriate; in others, notification could be restricted or harmful to a legitimate investigation. The appropriate operational response should follow applicable rules and case-specific circumstances through appropriately configured controls.

A practical pilot should therefore evaluate two questions together: does the mechanism reduce unnecessary cost and delay, and does it preserve or improve the protections that justify the process? The strongest results will show measurable progress on both dimensions. The long-term value of Project Jake lies in demonstrating that efficiency and responsibility can reinforce each other.

Independence and interoperability are complementary strengths

Project Jake’s independence is valuable because it allows research and experimentation to proceed across organizational and policy boundaries. Different Data Holders may have different systems, legal constraints, and operational preferences. Different Requestor communities may possess different forms of identity assurance or supporting documentation. A single rigid workflow may be ill-suited to that diversity.

An open, modular approach allows the same basic functions to be tested in different settings. Some participants may use centrally hosted services; others may deploy components in their own environments. Some Agreements may involve routine requests with highly structured forms; others may require more extensive review. What matters is that the participating systems can communicate the necessary information and preserve the authority of the relevant decision-maker.

Turning open-source components into interoperable services also requires more than publishing code. Interfaces must be defined, credentials must have a recognized meaning, data must be protected in transit and at rest, and the parties must understand the responsibilities attached to shared information. Independent components require governance of their own: change management, testing, maintenance, security practices, and documented expectations.

A collaborative roadmap for practical experimentation

Project Jake invites the community to move from shared interest to specific, measurable experiments. Three priorities follow from the framework and from the policy issues now before the ICANN community.

First, test RDRS interoperability in realistic conditions. The existing Jaddar interface provides a starting point. Testing with actual users can examine request preparation, submission, status information, response presentation, error handling, and recordkeeping. It can also clarify which functions belong in RDRS and which are better maintained by the Requestor or Data Holder organization.

Second, explore complementary authentication models. Requestor Groups offer a way to examine verification of identity, affiliation, and role without assuming that one centrally managed identity database is necessary. Work with law enforcement agencies is an obvious candidate, particularly in view of ICANN’s authentication proof of concept. Tests should make clear what assurance is being provided, who stands behind it, and what additional recognition would be required for use in an ICANN-related process.

Third, test distributed, Data Holder-controlled disclosure workflows. Published Agreements and configured review procedures can be evaluated for consistency, cost, auditability, and protection of non-public data. The ongoing collaboration with TWNIC, identified in Project Jake’s source article, offers one setting in which the technical and administrative model can be examined. Carefully documented results should capture successes as well as limitations, including instances where a process does not work as expected.

The current development stage is particularly suitable for that participation. Project Jake has open-source applications in Alpha testing and is inviting early adopters to improve the framework before a wider rollout. The aim should be to collect credible operational evidence in time to inform relevant policy and implementation discussions, while leaving the outcomes of those discussions to the appropriate decision-makers.

A broader opportunity for Internet governance

The debate about non-public registration data highlights an opportunity to bring policy development and implementation into closer, more productive dialogue. When requirements are developed over years and tested only later, their detailed operational consequences can emerge too late to shape the design efficiently. Early experimentation makes it possible to identify difficult or costly requirements while there is still room to adapt them to the community’s expectations and the practical needs of users.

A better relationship is iterative. Policy retains its authority, but engineering informs it. Proposed rules are tested against real workflows. Costs and risks are measured. Implementation produces feedback, and that feedback returns to the policy community for consideration through legitimate processes. Governance institutions and engineers can each strengthen the process within their respective roles.

Project Jake’s contribution is to offer a concrete environment for that relationship. It can make abstract questions visible: what does identity assurance actually require, how should an Agreement be represented, where is human judgment needed, and which checks can be reused responsibly? These are implementation questions with real policy consequences. Making them easier to understand reinforces the multistakeholder model.

Conclusion: collaboration turns policy goals into workable solutions

Project Jake’s purpose is to help legitimate policymakers make better-informed decisions and help responsible organizations implement those decisions effectively. ICANN’s multistakeholder process and other authorized institutions retain their policymaking responsibilities, while Data Holders remain accountable for lawful disclosure. Project Jake contributes the independent tools and operational evidence that can make those decisions effective in practice.

RDRS offers a common route for requests. The renewed SSAD policy work is examining what a more comprehensive long-term framework should require. Project Jake can connect these efforts to practical tools: verified Requestor information, structured submissions, reusable Agreements, configurable Data Holder workflows, and evidence from real-world testing. Its existing RDRS interface demonstrates one concrete point of cooperation; its wider architecture offers further possibilities that must be tested, evaluated, and governed.

The invitation is to work together: test Jake’s mechanisms, examine its assumptions, and use the resulting evidence wherever it adds value. ICANN and other authorized institutions determine the rules. Data Holders remain accountable for lawful disclosure. Project Jake provides a practical environment for exploring and implementing those arrangements. This clear division of responsibility is a strength of the project and the foundation of a viable, collaborative pathway for exploration, experimentation, and improvement.

Selected source references

ICANN Board, Approved Resolutions, 12 March 2026 (SSAD Supplemental Recommendations and RDRS continuation): https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-12-03-2026-en

SSAD Supplemental Recommendations Team, Notes and Action Items, 29 September 2026: https://lists.icann.org/hyperkitty/list/gnso-ssad@icann.org/thread/BCCPMFE4ZNYTB5WB3F666JAXTUJXQ5DM/

ICANN, Registration Data Policy (urgent requests and response requirements): https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy

ICANN, Law Enforcement Agency Authentication Mechanisms Input Group: https://www.icann.org/rdrs/input-group-lea-auth

Steve Crocker, Project Jake update including RDRS interface, ICANN SSAD mailing list, September 2026: https://lists.icann.org/hyperkitty/list/gnso-ssad@icann.org/thread/LRKVHLVDIQXXTO5RZWLFLK32F5BKWXRS/