Skip to main content

Technical Reference - GRID & DIA

Purpose and positioning​

This document exists to hold the implementation depth that does not belong in the high‑level Economic Argument.

It describes how GRID/DIA can be implemented using established digital identity and credential patterns, while keeping the economic narrative focused on outcomes.

Component overview​

Global Registrar Information Directory (GRID)​

What it is: a UN‑hosted directory of authoritative registrars (business registries, land registries, trade registries, etc.) and the information needed to verify what they issue.

What it is not: a centralized repository of entity data.

What GRID typically contains​

  • Registrar identity and official service endpoints (website, contact, verification service)
  • Registrar digital identifiers (where used)
  • Registrar verification material (e.g., public keys / trust anchors) required to authenticate evidence issued by the registrar
  • Registrar metadata (jurisdiction, scope, governance and operational status)

Typical verifier questions GRID enables​

  • “Is this issuer the authoritative registrar for this jurisdiction?”
  • “Where do I validate a credential issued by this registrar?”
  • “What verification material should I use to authenticate what this registrar issues?”

Data sovereignty model​

A strict “directory, not database” model:

  • national registries remain authoritative and keep custody of their data
  • GRID stores pointers and verification material, not the registries’ underlying entity records
  • verification is performed against the authoritative source, not against copies

Digital Identity Anchor (DIA)​

What it is: a standard “container” for legal‑entity identity assertions that is machine‑readable and cryptographically verifiable.

A DIA can hold (at minimum):

  • legal name
  • registration number / existing national identifier
  • jurisdiction and registrar
  • status (active, dissolved, etc.)
  • key attributes required for cross‑border KYB decisions (as policy permits)

Why a credential model​

Static documents (PDFs, images, email attachments) are easy to imitate. A credential model enables:

  • tamper evidence: modifications invalidate the signature
  • issuer authentication: the verifier can confirm the issuer is the authoritative registrar (via GRID trust anchors)
  • automation: systems can validate without manual document inspection

Standards and formats​

One feasible implementation uses:

  • W3C Verifiable Credentials (VCs) for the credential envelope1
  • JSON‑LD (or other serializations consistent with VC usage) for machine readability
  • Decentralized Identifiers (DIDs) (or equivalent issuer identifiers) to reference issuer and verification material
  • conventional API integration patterns so national Single Window environments can issue and verify without replacing legacy systems

Multiple technical stacks can satisfy the same strategic objective. The key requirement is: issuer authenticity + tamper evidence + machine checkability + revocation.

Integration patterns​

Minimal path: “directory‑only” participation​

A country can participate by publishing:

  • authoritative registrar identity + service endpoints
  • governance and contact metadata
  • verification material for what the registrar issues

This enables cross‑border verifiers to locate authoritative sources even before credential issuance is fully modernized.

Progressive path: DIA issuance​

Over time, registrars can add:

  • an issuance service (credential issuance)
  • a verification service
  • a revocation / status mechanism (so relying parties can detect stale or withdrawn evidence)

Interoperability with existing systems​

GRID/DIA should not introduce new legal identifiers or replace national regimes. It wraps existing identifiers and adds verifiability:

  • registrars remain the source of truth
  • existing identifiers remain valid
  • GRID enables discovery; DIA enables reusable evidence

Security and assurance considerations (optional depth)​

Public/private key separation​

Issuer authenticity depends on protecting signing keys:

  • verifiers use public verification material (via GRID trust anchors)
  • issuers protect private keys in national operational environments

Revocation and “freshness”​

A credential that cannot be revoked or status‑checked becomes a liability. Implementations should support:

  • explicit expiry
  • online status checking (where feasible)
  • revocation semantics aligned with registrar governance

Privacy and selective disclosure (where needed)​

Some use‑cases benefit from “prove X without revealing Y” patterns. Where relevant, these can be implemented with selective disclosure and zero‑knowledge techniques, but they are not prerequisites for the economic case.

  • UN Transparency Protocol (UNTP)2
  • W3C Verifiable Credentials Data Model1

Footnotes​

  1. W3C Verifiable Credentials Data Model v2.0, accessed 2 December 2025, https://www.w3.org/TR/vc-data-model-2.0/ ↩ ↩2

  2. UN Transparency Protocol, accessed on 2 December 2025, https://untp.unece.org/ ↩