Skip to main content

Implementation Guidelines

ODP Stage 3: Draft Development

This document forms part of the project deliverables. This version is a draft and under development and review. When finalised, it will be one of the deliverables for the project.

Purpose and Scope of this document

These Implementation Guidelines set out the proposed approach for implementation of the Global Registrar Information Directory (GRID) and for implementation of Digital Identity Anchors (DIAs) by eligible Authoritative Registrars within the Global Trust Registry (GTR) framework.

These Guidelines shall be read consistently with the Glossary, the Eligibility Requirements, the Legal Governance and Target Operating Model for the GRID, the Participating Registrar Data Schema, and Annex A - Technical Reference for GRID & DIA.

These Guidelines are implementation-oriented. They do not alter the legal status, competence, mandate or evidentiary effects of any Authoritative Register or Authoritative Registrar under applicable law.


1. Common Implementation Principles

Implementation of the GRID and of DIAs shall be guided by the following common principles.

1.1 Authoritative Source Principle

The Authoritative Registrar shall remain the authoritative source of the registration data, status information and legal effects arising from the underlying register. Neither the GRID nor any DIA shall replace, supersede or diminish the authority of the Registrar under applicable law.

1.2 Discovery and Reference Principle

The GRID shall function as a discovery, reference and trust-enablement layer. It is not intended to replicate national registers, to centralise ownership of registry data, or to displace national registration systems.

Implementation shall preserve legal clarity as to the origin, status and function of any identifier used within the framework.

Where a DIA or related trust structure refers to one or more identifiers, the implementation shall clearly distinguish the identifier that is authoritative for the relevant registration purpose from any supplementary, associated or asserted identifiers.

The inclusion of additional identifiers shall not, by itself, imply equivalence of legal status, evidentiary value or Registrar responsibility.

The legal effect of registration, certification or official attestation shall continue to derive from the applicable law governing the underlying register. The issuance of a DIA shall not, by itself, create, modify or extinguish legal rights, statuses or priorities beyond those arising under the law governing the relevant register.

1.5 Voluntary Participation and Sovereignty Principle

Participation in the GRID shall be voluntary. Participation shall not transfer ownership or control over registry data to the United Nations or to any third party. Participating Registrars shall retain control over their own data, systems and issuance processes, subject to the applicable governance arrangements.

1.6 Technological Neutrality Principle

These Guidelines shall be applied in a technologically neutral manner. They define functional, legal and trust outcomes and shall not mandate a single domestic technical architecture, identifier model or implementation method, except where necessary to support interoperability, integrity, authenticity or trust.

1.7 Proportionality and Inclusive Maturity Principle

Implementation shall accommodate differing levels of legal and technical maturity among participating Registrars. Participation in the GRID shall not depend on full technical sophistication, provided that the applicable Eligibility Requirements are met.

1.8 Liability Clarity Principle

Implementation of DIAs shall clearly distinguish between information verified by the Registrar and information asserted by the subject or conveyed from another source. Such distinction is necessary to preserve legal certainty and to avoid unintended extension of Registrar responsibility.

1.9 Sovereignty and Subsidiarity Principle

National and sub-national legal frameworks, registry governance arrangements and public-law competences shall remain unaffected except to the extent that a participating jurisdiction expressly chooses to implement interoperable trust mechanisms in accordance with these Guidelines.


2. Implementation of the GRID

The GRID should be implemented progressively, in phased and operationally manageable steps. A phased approach supports inclusiveness, reduces barriers to participation, preserves national autonomy and enables trust to be built incrementally.

2.1 Phase 1 - Establishment of the Authoritative Discovery Layer

The first implementation objective should be the creation of a reliable global discovery layer for eligible Authoritative Registrars.

At this stage, a participating Registrar should be able to provide, at a minimum:

  • its official identity and jurisdiction;

  • evidence of its legal mandate or legal basis;

  • the type or types of Authoritative Register under its responsibility;

  • official service endpoints or resolver information by which the Registrar or its public services can be located;

  • designated contact and governance metadata; and

  • where available, verification material relevant to signed outputs or future credential issuance.

This phase corresponds to baseline participation and enables authoritative cross-border discovery even where full credentialing capability has not yet been implemented.

2.2 Phase 2 - Prioritisation of Initial Register Types

In the early phases of implementation, the GRID should prioritise register types that are both legally authoritative and materially relevant to cross-border trade, legal reliance, due diligence or rights verification.

Without prejudice to future expansion, these may include:

  • business and company registers;

  • registers containing trade-relevant legal entity information;

  • land and property registers where title, ownership, encumbrances or secured interests are relevant to trade, investment or financing;

  • maritime, vessel or asset-related registers; and

  • other public legal registers recognised by the GRID governance framework as trade relevant.

As a practical matter, business registers are likely to constitute an appropriate starting point in many jurisdictions because they are widely used in legal entity identification, onboarding, KYC, KYB and transactional due diligence. However, these Guidelines do not assign superiority to one register category over another as a matter of legal principle. The determination of recognised trade-relevant register types remains a matter for the applicable GRID governance framework.

2.3 Phase 3 - Transition from Maintained Entries to Signed and Harvested Metadata

Once the discovery layer is established, participating Registrars should be encouraged to move toward publication of machine-readable and cryptographically protected Registrar metadata.

This phase should include, as appropriate:

  • structured Registrar metadata;

  • publication or controlled disclosure of public verification material;

  • support for trusted update, key rollover and lifecycle management;

  • harvesting arrangements for inclusion in the GRID; and

  • a clear operational distinction between manually maintained GRID entries and automatically harvested entries.

This phase increases assurance in the identity and authenticity of the Registrar itself and provides a stronger trust basis for subsequent credential issuance.

2.4 Phase 4 - DIA-enabled Participation

The most advanced participation profile should enable the Registrar to issue DIAs in accordance with applicable specifications and governance requirements.

At this stage, the Registrar is not merely discoverable through the GRID but is also capable of issuing digitally verifiable evidence linked to authoritative registration data.

Admission to the GRID shall remain subject to the applicable governance arrangements and Eligibility Requirements. A participating Registrar should be able to demonstrate authoritative status, legal mandate, accountability and responsibility for one or more trade-relevant registers or schemes recognised by the GRID governance framework.

The GRID shall preserve the distinction between:

  • the register;

  • the Registrar;

  • the underlying registry data; and

  • the GRID record that provides discovery and trust metadata relating to the participating Registrar or scheme.

Inclusion in the GRID shall not constitute endorsement of a Member State’s legal system, domestic policy or substantive legal rules. Its function is to support transparency, findability and trust-enablement within the framework.

2.6 Onboarding Pathway for GRID Participation

The operationalisation of the GRID shall include a clear, proportionate and legally robust onboarding pathway.

A typical pathway may include:

  1. Application - the prospective Registrar submits an application through the applicable GRID admission channel.

  2. Eligibility Verification / Vetting - the Secretariat or other competent body verifies authoritative status, legal basis, trade relevance, accountability arrangements, relevant trade data and other applicable criteria.

  3. Approval - admission is confirmed by the GRID Board or by a duly delegated mechanism.

  4. Integration - the admitted Registrar provides the required Registrar Data together with service endpoints, contact metadata and, where applicable, public verification material, Public Keys, Issuer DID information or related trust anchors.

  5. Publication - the Registrar is listed in the GRID either as a maintained entry or as a harvested entry, depending on its implementation profile.

  6. Fee Commencement - where applicable under the operating model, the participant commences contribution to the Operational Fund in accordance with the applicable fee arrangements.

  7. Lifecycle Management - subsequent updates, corrections, suspension, re-activation, withdrawal or retirement shall be managed through the applicable governance and data maintenance processes.

Admission to the GRID shall be based on authoritative legal status and compliance with the applicable Eligibility Requirements, and not on a requirement to have already implemented DIA issuance.

2.7 Technical Implementation Considerations for the GRID

From a technical perspective, implementation of the GRID should support:

  • stable Registrar metadata;

  • publication or controlled disclosure of public verification material;

  • resolver templates or equivalent deterministic discovery methods, where applicable;

  • lifecycle handling for updates, suspension, re-activation and retirement; and

  • publication or harvesting methods appropriate to the selected maturity level.

The technical implementation should remain lightweight and decoupled. National registry operations should remain unaffected if the GRID hub is unavailable.


3. Implementation of DIAs

A DIA is a verifiable credential issued by an Authoritative Register to a subject, linking a registered identifier controlled by the Authoritative Register to cryptographic proof of authenticity and integrity.

Implementation of DIAs shall preserve the following propositions:

  • the legal significance of the credential derives from the underlying register and applicable law;

  • the Registrar remains the authoritative issuer of the facts it is legally competent to attest; and

  • any additional identifiers or subject-controlled identifiers shall be distinguished according to their legal and evidentiary status.

Implementation of DIAs shall not displace the underlying register entry, the official extract, the certificate of registration, or any other legally recognised act or instrument where applicable law assigns to such instrument particular evidentiary, constitutive or opposability effects.

3.2 Relationship Between Implementation Models

The implementation models set out below shall be understood as permissible implementation patterns for DIA issuance. They are not mutually exclusive, and a Registrar may adopt one, the other, or move progressively from one to the other.

These models relate to the operational mode of DIA issuance and do not, in themselves, require the creation of a new legal identifier.

In all cases, the DIA should identify the identifier that is authoritative for the relevant registration purpose, while any supplementary identifiers, where permitted, shall remain clearly distinguished as such.

Nothing in these Guidelines shall require all Registrars to adopt the same implementation sequence, provided that the applicable governance requirements, legal clarity and trust requirements are satisfied.

3.3 Model 1 - DIA Issuance Linked to an Existing Authoritative Identifier or Scheme Identifier

This model is appropriate where the Registrar already operates, assigns, maintains, certifies or legally recognises an authoritative identifier within a relevant register or scheme.

Under this model, the DIA is issued by reference to the identifier that is authoritative for the relevant registration purpose within the applicable register or scheme. That identifier may be national, sub-national, sectoral, regional or otherwise legally anchored, depending on the applicable legal and institutional framework.

The relevant point is not the territorial level of the identifier, but whether it is authoritative for the relevant registration purpose under the competent register or scheme and under the law governing that register or scheme.

Under this model, the DIA does not create a new legal identity. Rather, it provides a digitally verifiable representation of an identity, status or registration relationship already recognised within the underlying legal framework.

Where appropriate, the DIA may include:

  • the legal name or legally recognised designation of the subject;

  • the authoritative identifier issued or maintained by the Registrar;

  • the identity of the issuing Registrar;

  • the jurisdiction and, where relevant, the scheme;

  • the registration or status information that the Registrar is legally competent to attest; and

  • supplementary identifiers, subject to the trust attribution rules set out below.

3.4 Model 2 - DIA Issuance Integrated into the Registration Workflow

This model is appropriate where a Registrar chooses to integrate DIA issuance directly into the official registration workflow, whether in a newly established system or in a substantially modernised one.

Under this model, the successful registration process results in the issuance of a DIA as part of the official workflow.

This model does not, by itself, require the creation of a new legal identifier. The identifier reflected in the DIA should remain the identifier that is authoritative for the relevant registration purpose under the applicable register or scheme. Where that identifier is generated through the registration workflow itself, its legal status shall continue to derive from the governing law and from the underlying register.

Even where this model is used, the following elements shall remain conceptually distinct:

  • the legal act of registration;

  • the authoritative identifier for the relevant registration purpose; and

  • the credential evidencing that act.

This model may be operationally attractive in digital-native systems, but it does not alter the principle that legal effect remains grounded in the underlying register and the law governing that register.

3.5 Recognition of Both Implementation Models

Both implementation models should be recognised as valid within the GTR framework, provided that:

  • the issuing entity is, or acts under, the competent Authoritative Registrar;

  • the legal basis for the attested content is clear;

  • the identifier presented as authoritative is authoritative for the relevant registration purpose under the applicable register or scheme;

  • the distinction between authoritative facts and non-authoritative assertions is preserved;

  • verifier access to relevant trust material is supported; and

  • the implementation does not misrepresent the legal or institutional status of the issuing Registrar.

Recognition of both models supports inclusiveness, accommodates legacy and modernised systems alike, and preserves alignment with the project’s maturity-based approach.

3.6 Protection of Registrable Interests and Registrar Responsibility

Because the GRID and DIA architecture interacts with legally significant public registers, implementation shall be framed so as to preserve registrable interests, public-law functions and the evidentiary value of official registration systems.

3.6.1 No Displacement of the Register

Neither the GRID nor a DIA shall displace the legal authority of the register entry, the official extract, the certificate of registration, or other legally recognised acts or instruments issued under applicable law.

3.6.2 No Substitution of the Sovereign or Authoritative Identifier

Where a register already assigns or maintains an authoritative identifier, that identifier should remain primary for the relevant registration purpose. Supplementary identifiers or decentralised identifiers shall not be presented as replacing the sovereign or authoritative identifier maintained by the Registrar.

3.6.3 Registrar Control over What is Certified

The Registrar should attest only those facts, statuses, identifiers or relationships that fall within its legal mandate, operational competence and evidentiary authority.

3.6.4 Preservation of Title, Priority and Opposability Rules

Nothing in these Guidelines shall be interpreted as altering applicable rules relating to title, priority, opposability, constitutive effect, chain of title, statutory notice effect, publicity, registration priority or similar concepts applicable to a public legal register.

Where applicable law permits, a DIA issued by an Authoritative Registrar may serve as a digitally verifiable functional equivalent of a traditional certificate, extract or attestation for relevant transactional or due diligence purposes. However, such functional equivalence shall remain subject to the governing law of the underlying register and to any applicable form requirements.

3.7 Technical Implementation Considerations for DIAs

From a technical perspective, DIA-capable implementation should support:

  • secure issuer key management;

  • discoverability of trust material;

  • credential lifecycle handling;

  • mechanisms for status, revocation, expiry or freshness, as appropriate; and

  • a reliable verifier pathway.

Where subject-controlled identifiers, supplementary identifiers or externally sourced identifiers are included, the implementation should support an explicit means of indicating the trust status applicable to each such identifier or data element.

3.8 Trust Attribution and Supplementary Identifiers

Where a DIA contains content beyond the core authoritative registration identifier, implementation shall clearly distinguish the trust status of that content.

A DIA may include supplementary identifiers or linked identifiers, including identifiers from other ecosystems, schemes or technical domains, provided that the trust basis for each such identifier is made explicit.

For this purpose, implementations should distinguish at least between:

  • Verified - where the Registrar has cross-checked the identifier or related information against authoritative records or equivalent verification procedures; and

  • Asserted - where the information is provided by the subject and conveyed by the Registrar without the Registrar assuming responsibility for its independent correctness.

This distinction is recommended because it preserves legal clarity, protects the Registrar from unintended liability and allows multi-identifier interoperability without compromising the authority of the primary registry identifier.

Supplementary identifiers shall remain supplementary. They shall not obscure the primacy of the authoritative identifier issued or maintained by the Registrar.

3.9 Minimum Implementation Requirements for DIA-capable Registrars

A Registrar implementing DIA issuance should support, directly or through duly governed arrangements, the following capabilities:

  • a lawful basis for issuance;

  • a clearly identified credential issuer under the Registrar’s authority;

  • secure management of signing keys and issuer verification material;

  • a verification pathway for relying parties;

  • status, expiry, revocation or equivalent freshness mechanisms;

  • governance rules for updates, corrections and lifecycle events; and

  • an operational separation between authoritative Registrar content and any subject-asserted or third-party content.

Where decentralised identifiers or other subject-controlled identifiers are included, the Registrar should apply a proportionate control-verification process before marking such identifiers as Verified.

3.10 GRID-participant Issuance and Non-GRID Issuance

The preferred implementation pattern is issuance by Authoritative Registrars participating in the GRID.

This is the preferred pattern because GRID participation adds a trusted discovery layer for the Registrar, supports location of verification material and strengthens cross-border assurance in the identity of the issuing authority.

However, these Guidelines may also recognise that DIA-compatible issuance can exist outside formal GRID participation.

Accordingly:

  • an Authoritative Registrar may implement a DIA issuance capability before joining the GRID;

  • an entity that is not a GRID Participant may issue a technically conformant credential;

  • however, such issuance shall not be represented as GRID participation, GRID recognition or GRID-supported issuance unless the relevant Registrar has been duly admitted to the GRID.

In practical terms, a non-GRID credential may be technically verifiable, but it does not benefit from the same discoverability, governance path, listing status or institutional trust context as a credential issued by a GRID Participant.

These Guidelines should therefore maintain a clear distinction between:

  • DIA issuance by a GRID Participant, which combines entity-level verifiability with Registrar-level discoverability; and

  • DIA-compatible issuance outside the GRID, which may provide technical assurance but does not, without more, establish GRID status or GRID recognition.


4. Suggested Implementation Profiles

For practical implementation planning, the following profiles may be used.

4.1 Profile A - GRID Listing Only

The Registrar provides stable metadata, legal basis information and relevant service references sufficient for authoritative discovery.

4.2 Profile B - Signed and Harvested GRID Metadata

The Registrar publishes structured and cryptographically signed metadata suitable for harvesting and trusted inclusion in the GRID.

4.3 Profile C - GRID Participation plus DIA Issuance Linked to an Existing Authoritative Identifier or Scheme Identifier

The Registrar participates in the GRID and issues DIAs linked to an identifier that is authoritative for the relevant registration purpose within the applicable register or scheme.

4.4 Profile D - GRID Participation plus DIA-native Issuance

The Registrar participates in the GRID and issues DIAs as part of a digitally integrated registration workflow from the outset.

4.5 Profile E - DIA-compatible Non-GRID Issuance

An authoritative issuer implements DIA-compatible issuance outside formal GRID participation. This profile may support transition or experimentation, but shall remain distinct from GRID-recognised participation.


5. Concluding Implementation Position

The implementation of the GRID and DIAs should be progressive, inclusive, legally grounded and respectful of public registry functions.

As a general rule:

  • the GRID should first be established as a trusted global discovery layer for Authoritative Registrars;

  • participation should then mature toward signed metadata and stronger trust infrastructure; and

  • DIA issuance should be implemented either by linking to existing authoritative identifiers or by integrating credential issuance into a modernised registration workflow, provided in all cases that the authority of the Registrar, the continuity of the underlying legal identifier and the legal effects of the register are preserved.

The objective of the GTR framework is not to replace national registers, but to strengthen their cross-border discoverability, interoperability and verifiability while maintaining the integrity of their sovereign legal role.