Skip to main content
Version: Stage 5 - Deliverable Acceptance Check

DIA - Legal Meaning and Data Structure

1. Introduction (non-normative)​

1.1 Purpose and Scope​

This document examines the legal nature and technical architecture of the UNTP1 Digital Identity Anchor (DIA) when issued by the GRID and by Authoritative Registrars who participate in the GRID.

The DIA is not a new identifier, nor does it modify or supersede the legal status of identifiers issued under national law. It is a verifiable digital attestation that "anchors" a national or commercial identifier in a verifiable credential issued by the Registrar.

The data model basis of the UNTP DIA is a W3C Verifiable Credential2. The version of the UNTP specification at the original review was 0.63. This document has been updated to ensure that the DIA data model aligns with the UNTP v0.8.0 specification and W3C Verifiable Credentials Data Model v2.0.

The issuance and use of a UNTP Specification DIA is not limited to Authoritative Registrars participating in the GRID. Other organisations may choose to issue DIAs recognising other organisations, and the ability to issue a DIA is not a precondition or post-expectation of participating in the GRID.

Authoritative Registrars may choose to participate in the GRID before they have the capability and make the choice to issue DIAs. Eligibility for GRID membership does not depend on digital maturity or capability but does depend on authoritative UN Member State legal basis and the legislative framework and operational capability to maintain an Authoritative Register. See the Eligibility Requirements section in the "Legal Governance and Target Operating Model for the Global Registry Information Directory (GRID)" for details.

The practice of issuing DIAs is strongly encouraged as a mechanism to achieve supply chain transparency as proposed by the UNTP Specification4.

This document defines the legal meaning of DIAs as issued by the GRID and by Authoritative Registrars participating in the GRID in comparison to traditional registry extracts, while providing the cryptographic verifiability required for supply chain transparency.

Note that control of a cryptographic identifier MAY not, by itself, provide sufficient evidence of legal identity, registration status or authority to represent the subject entity within a UN Member State jurisdiction. Legal identity and authority to act on behalf of a legal person are determinations governed by the UN Member State applicable law and the underlying register.

1.2 The DIA as a Trust Wrapper​

There are two instances of DIA issuance of relevance to the GRID operation, both are based on the UNTP DIA specification. The instances are:

  1. A DIA issued by the GRID. This serves as a secure and verifiable "envelope" that the Registry has met the eligibility requirements of the GRID.
  2. A DIA issued by an Authoritative Registrar (AR) participating in the GRID. This serves as a secure and verifiable "envelope" of their existing registration process and identifier(s).

As used in a GRID and Registrar context, there are two core data elements to the UNTP DIA specification:

  1. The registrar content. This includes relevant applicant information and the identifier issued by the AR together with any other Registrar controlled content. This content is subject to the Registrar's UN Member State law and standards and is expected to follow their current practice.
  2. A decentralised identifier (W3C DID) that the applicant controls and provides to the Registrar.

For GRID DIA issuance, the GRID confirms that the applicant meets eligibility requirements and then, if the applicant can create and control a DID, confirms that they control their DID through cryptographic challenge and response. The GRID then issues and signs a DIA for the Applicant as part of the process of adding the applicant to the GRID.

The AR follows a similar process for their DIA issuance. They check that the Registry applicant meets their requirements and that they control their DID. Then the AR creates a DIA for their applicant, cryptographically signing the DIA using their AR private key.

As a participant in the GRID, the AR registers and maintains their public key with the GRID so that the GRID can echo the public key and supply chain participants can verify DIAs claimed to be issued by them. This is similar to the way that the ICAO PKD system works for passports and international travel.

1.3 DIA Issuance Sequence​

The following sequence demonstrates how GRID DIA issuance is an optional extension of GRID registration process.

The following sequence demonstrates how AR DIA issuance is an optional extension of existing registrar processes.

1.4 Example Verification Flow​

In the UNTP ecosystem, credentials follow an issuer-hosted model: each issuing authority publishes and maintains the credentials it issues within a trustworthy space that it controls.

Consider when a relying party (such as a customs authority or bank) verifies a commercial transaction (such as an invoice) signed by an exporter. Rather than relying on static, disconnected attachments, the verifier traverses the issuer-hosted trust chain:

Expanding this flow:

  1. Transaction Submission: The Exporter provides the Bank with a link or reference to the digitally signed commercial invoice hosted in the Exporter's trustworthy space.
  2. Invoice Resolution & Subject Binding: The Bank resolves the invoice from the Exporter's space, verifies that the Exporter's DID signed the invoice, and extracts the link to the Exporter's Digital Identity Anchor (DIA) hosted in the national Registrar's space.
  3. Registrar-Issued DIA Verification: The Bank resolves the Exporter's DIA directly from the Registrar's trustworthy space. The Bank verifies that:
    • The DIA is cryptographically signed by the Registrar's DID.
    • The Exporter's signing DID matches the decentralizedIdentifier bound to the national authoritativeIdentifier within the DIA.
    • The DIA remained valid and unrevoked on transaction date T_tx according to the Registrar's status mechanism. The Bank then extracts the gridReference link to the Registrar's directory entry in the GRID.
  4. GRID Trust Anchor Verification: The Bank resolves the Registrar's DIA (or directory trust record) directly from the GRID's trustworthy space. The Bank confirms that on the transaction date T_tx:
    • The Registrar was an active participant in the GRID (participationStatus: Member).
    • The Registrar's statutory mandate was authoritative and active.
    • The key used by the Registrar to sign the Exporter's DIA in Step 3 was a validly registered signing key at T_tx.

1.5 UNTP DIA Specification Alignment and Attribution Enhancements​

Data issued and controlled by the Registrar has a different quality to data received and checked by the Registrar (the DID supplied by the applicant).

We need to ensure that inclusion of the applicant supplied DID in the DIA does not change the legal meaning (responsibilities and liabilities) of the Registrar's registration process and outcome.

This meant the following changes to the original UNTP DIA specification:

  1. Objectification of the Authoritative Identifier. The flat identifier and scheme properties at the root of the credentialSubject are nested in an authoritativeIdentifier node object. This allows each discrete data point to be capable of holding the source property. By explicitly tagging relevant nodes with source: Authoritative, the credential binds the Registrar's legal responsibility to the specific data they natively issue and control.

  2. Explicit Encapsulation of the Applicant's DID. The W3C Verifiable Credentials Data Model necessitates the use of the id property to denote the subject of the credential. However, to satisfy the specific liability bounding of the DIA, the Decentralized Identifier (DID) provided by the applicant is also modelled as a discrete node object (decentralizedIdentifier). Because the Registrar cryptographically verifies control of this DID but does not natively issue it, this object is tagged with source: Verified. This reflects that the Registrar assumes liability only for the accuracy of the linkage at the time of checking, not the identifier's creation nor the content of the DID Doc.

  3. Implementation of the source taxonomy. The source attribute is applied universally across all identifier nodes. The values Verified and Asserted are used to delineate between content that the Registrar has actively cross-referenced against authoritative records, and content that the applicant provides and the Registrar conveys with zero assumed liability.

Summary of Changes from UNTP 0.6​

The following table explains the delta between the UNTP spec (at version 0.6) and the GRID specification:

AttributeUNTP Base SpecGRID Proposed ChangeRationale
identifierGeneric entity ID.Authoritative Identifier.Clarifies that the root ID is the one issued by the signing Registrar.
registrarImplicit.Added gridReference.Links the DIA directly to the GRID for root-key discovery.
sourceNot present.Added Enum (Authoritative/Verified/SubjectAsserted).Critical for Liability: Protects Registrars by distinguishing between what they control, what they actively vet and what they merely convey.

2. The Attribution Model (normative)​

Every data element within a DIA issued by the GRID or by a participating Registrar MUST carry one of the following source classifications:

  1. Authoritative: The data is natively generated, issued, and controlled by the issuing authority under its direct governance or statutory mandate (e.g. gridDirectoryRecord for GRID; authoritativeIdentifier for Registrars).
  2. Verified: The data is provided by the subject or applicant and the issuing authority has verified it against official records or confirmed cryptographic control (e.g. authoritativeRegister and applicant DID for GRID; applicant DID control for Registrars). The issuer's liability is strictly limited to the correctness of the verification check at the time it was conducted.
  3. SubjectAsserted: [Optional] The data is provided by the applicant (who is also subject of the DIA) and conveyed by the issuing authority with zero assumed liability (e.g. registrarNotes for GRID; trade names or auxiliary contact info for Registrars). Note that the term subject is used with the meaning given by the W3C Verifiable Credential Data Model2.

The Attribution Model applies symmetrically across both credential tiers:

  • In a GRID-issued DIA (Tier 1): gridDirectoryRecord carries source: Authoritative; authoritativeRegister and the Registrar's decentralizedIdentifier carry source: Verified; and descriptive commentary (registrarNotes) carries source: SubjectAsserted.
  • In a Registrar-issued DIA (Tier 2): authoritativeIdentifier carries source: Authoritative; the entity's decentralizedIdentifier carries source: Verified; and applicant-supplied operational notes carry source: SubjectAsserted.
UNTP Issuer-Hosted Model & Repository Architecture

Under the UNTP architecture, credentials follow an issuer-hosted repository pattern:

  1. Authoritative Publication: Issuers (the GRID for Tier 1, Registrars for Tier 2) host and maintain the credentials they issue within a trustworthy, addressable web space (such as a sovereign node or HTTPS endpoint).
  2. Dynamic Discovery: Relying parties resolve credentials directly from the issuer's repository via deterministic URLs or UNTP Identity Resolvers (IDR), ensuring that verifiers always inspect the authoritative, live attestation rather than unverified third-party copies.
  3. Operational Simplicity: Registered entities do not need complex edge wallets to participate in cross-border trade; they simply cite the persistent link to their DIA hosted in the Registrar's space.

3. DIA Data Structure (Normative)​

The GRID ecosystem recognises two distinct applications of the Digital Identity Anchor data model:

  1. Tier 1: GRID-Issued DIA (Registrar Recognition Credential): Issued and hosted by the GRID to attest that an Authoritative Registrar has met GRID eligibility criteria, recording its participation status and registered trust anchors.
  2. Tier 2: Registrar-Issued DIA (Statutory Registration Credential): Issued and hosted by an Authoritative Registrar within its sovereign space to bind an applicant-controlled DID to an authoritative national registration identifier.

3.1 GRID Issued DIA (Registrar Recognition Credential)​

When an Authoritative Registrar participates in the GRID and controls a DID, the GRID issues a DIA attesting to the Registrar's validated status. The GRID hosts this credential within its directory space.

Data Model & Attribution​

In accordance with the Attribution Model (Section 2), the GRID-issued DIA strictly separates what the GRID natively governs from the national data it has vetted:

  • gridDirectoryRecord (source: Authoritative): Natively generated and governed by the GRID Board (e.g. gridReference, participantProfile, participationStatus).
  • authoritativeRegister (source: Verified): National statutory data vetted by the GRID Secretariat during onboarding (e.g. legalBasis, authoritativeBody, registerId).
  • decentralizedIdentifier (source: Verified): Cryptographic control of the Registrar's DID confirmed via challenge-response.
  • registrarNotes (source: SubjectAsserted): Operational descriptions or auxiliary endpoints provided by the Registrar and conveyed by GRID with zero assumed liability.
Implementation Example (JSON-LD)​
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/v2"
  ],
  "id": "https://grid.example.com/registers/ES.CORP/dia",
  "type": [
    "VerifiableCredential",
    "DigitalIdentityAnchor",
    "GRIDRecognitionCredential"
  ],
  "name": "GRID Authoritative Registrar Recognition Credential",
  "description": "Administrative recognition and trust anchor attestation issued by the Global Registry Information Directory (GRID) to an Authoritative Registrar of a UN Member State.",
  "issuer": {
    "id": "did:webvh:QmZ7bUNgridRootAnchorSCID987654321abcdef:grid.example.com",
    "name": "United Nations Global Registry Information Directory",
    "url": "https://grid.example.com/"
  },
  "validFrom": "2026-01-01T00:00:00Z",
  "validUntil": "2036-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:webvh:Qma3B8RegistradoresCentralSCID123456789xyz:registry.example.com",
    "type": "DigitalIdentityAnchor",
    "name": "Colegio de Registradores de España",
    "legalName": "Colegio de Registradores de la Propiedad, Mercantiles y de Bienes Muebles de España",
    "url": "https://registry.example.com/",
    "decentralizedIdentifier": {
      "identifier": "did:webvh:Qma3B8RegistradoresCentralSCID123456789xyz:registry.example.com",
      "keyProvenance": "did:webvh",
      "didLogEndpoint": "https://registry.example.com/.well-known/did.jsonl",
      "whoisEndpoint": "https://registry.example.com/whois.vp",
      "keyStatus": "Active",
      "effectiveFrom": "2026-01-01T00:00:00Z",
      "source": "Verified"
    },
    "gridDirectoryRecord": {
      "gridReference": "https://grid.example.com/registers/ES.CORP",
      "participantProfile": "C",
      "participationStatus": {
        "status": "Member",
        "effectiveFrom": "2026-01-01T00:00:00Z",
        "effectiveTo": null,
        "governedBy": "GRID Board",
        "statusReason": "Admission ratified following verification of authoritative legal basis and trade relevance."
      },
      "source": "Authoritative"
    },
    "authoritativeRegister": {
      "unMemberState": "ES",
      "subdivisionCode": null,
      "registerId": "ES.CORP",
      "registrarIdentifierCode": "CORP",
      "registerName": "Registro Mercantil Central",
      "registerType": "Organisation",
      "legalBasis": "https://www.boe.es/buscar/act.php?id=BOE-A-1996-17402",
      "authoritativeBody": "https://www.mjusticia.gob.es/",
      "mandateStatus": {
        "status": "Authoritative-Active",
        "effectiveFrom": "1996-06-08T00:00:00Z",
        "effectiveTo": null
      },
      "registeredIdPattern": "https://registry.example.com/registro-mercantil-central/{id}",
      "source": "Verified"
    },
    "registrarNotes": {
      "commentary": "The Central Mercantile Register provides official information on all Spanish legal entities and acts as technical coordinator for provincial registers.",
      "queryEndpoint": "https://registry.example.com/registro-mercantil-central/busqueda?q={id}",
      "source": "SubjectAsserted"
    }
  },
  "credentialStatus": {
    "id": "https://grid.example.com/status/2026/list#104",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "104",
    "statusListCredential": "https://grid.example.com/status/2026/list"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2026-01-01T12:00:00Z",
    "verificationMethod": "did:webvh:QmZ7bUNgridRootAnchorSCID987654321abcdef:grid.example.com#grid-key-1",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
  }
}

3.2 Registrar-Issued Entity DIA​

Where an Authoritative Registrar chooses to issue DIAs under the UNTP specification, the credential binds the legal entity's authoritative registration to an applicant-controlled DID. The Registrar hosts this credential in its own sovereign space.

Data issued and controlled by the Registrar has a fundamentally different legal quality from data received from the applicant (the DID). The data model enforces this distinction so that issuing a DIA does not alter the legal liabilities of the underlying statutory registration.

Implementation Example (JSON-LD)​

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/v2"
  ],
  "id": "urn:uuid:e7b34b12-9c48-43d9-9528-72439c0d3f21",
  "type": [
    "VerifiableCredential",
    "DigitalIdentityAnchor"
  ],
  "name": "Digital Identity Anchor - Iberia Exportaciones S.L.",
  "description": "Statutory corporate registration attestation binding national business register identifier to subject decentralized identifier, issued by the Authoritative Registrar Colegio de Registradores de España.",
  "issuer": {
    "id": "did:webvh:Qma3B8RegistradoresCentralSCID123456789xyz:registry.example.com",
    "name": "Colegio de Registradores de la Propiedad, Mercantiles y de Bienes Muebles de España",
    "url": "https://registry.example.com/"
  },
  "validFrom": "2026-03-15T00:00:00Z",
  "validUntil": "2036-03-15T00:00:00Z",
  "credentialSubject": {
    "id": "did:webvh:QmExPortErSCID998877665544332211aabb:exporter.example.com",
    "type": "DigitalIdentityAnchor",
    "decentralizedIdentifier": {
      "identifier": "did:webvh:QmExPortErSCID998877665544332211aabb:exporter.example.com",
      "source": "Verified"
    },
    "authoritativeIdentifier": {
      "identifier": "B82345678",
      "registeredName": "Iberia Exportaciones S.L.",
      "scheme": "ES.CORP",
      "source": "Authoritative"
    },
    "registeredAddress": {
      "streetAddress": "Calle de Alcalá 42",
      "locality": "Madrid",
      "postalCode": "28014",
      "country": "ES",
      "source": "Authoritative"
    },
    "businessRegistrationStatus": {
      "status": "Active",
      "registrationDate": "2010-05-20T00:00:00Z",
      "source": "Authoritative"
    },
    "registrar": {
      "name": "Colegio de Registradores de España",
      "registerId": "ES.CORP",
      "gridReference": "https://grid.example.com/registers/ES.CORP"
    },
    "tradeBrand": {
      "brandName": "Iberia Prime Logistics",
      "source": "SubjectAsserted"
    }
  },
  "credentialStatus": {
    "id": "https://registry.example.com/status/entities/2026#582",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "582",
    "statusListCredential": "https://registry.example.com/status/entities/2026"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2026-03-15T10:30:00Z",
    "verificationMethod": "did:webvh:Qma3B8RegistradoresCentralSCID123456789xyz:registry.example.com#key-1",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2BqK9WNm3ERegistrarSignatureExampleValueForTier2DIAValidationXYZ12345"
  }
}

Article I: Legal Status and Non-Substitution​

  1. A DIA issued by an Authoritative Registrar is a digital representation of an entry in an official register. It confers no legal personality or rights beyond those established by the underlying registration.

  2. The issuance of a DIA does not discharge any legal requirement to maintain or present primary evidence (extracts/certificates) where mandated by national law.

  3. The DIA is intended to provide Functional Equivalence for identity verification in digital-first trade environments.

Article II: Authority to Issue​

  1. The GRID may issue a DIA for a participating Authoritative Registrar confirming its admission, participation status, and registered trust anchors within the GRID. Inclusion in the GRID does not grant, modify, or license legal authority to the Registrar, which derives exclusively from its domestic legal mandate.

  2. An Authoritative Registrar participating in the GRID may choose to issue DIAs in accordance with its domestic laws and regulations.

  3. The UNTP specification is an open standard and any party may implement a DIA issuance capability. A DIA issued by an entity not listed in the GRID is not verifiable through the GRID. Establishing the validity of such an attestation is the sole responsibility of the relying party.

Article III: Attribution and Liability​

  1. For data marked as Authoritative, the issuing authority (the GRID for directory records, or the Registrar for registration data) is legally accountable for the accuracy of what it natively controls.

  2. For data marked as Verified, the issuing authority's liability is strictly limited to the accuracy of the linkage or vetting check performed at the time of onboarding or verification.

  3. For data marked as SubjectAsserted, the issuing authority assumes zero liability. Relying parties rely on asserted data entirely at their own risk.

Article IV: Sovereignty and Choice​

  1. Participation in the GRID DIA framework is voluntary.

  2. A Registrar’s decision to issue DIAs shall not interfere with its existing or future commitments to identifier standards (e.g., GS1, ISO, LEI, etc.).

  3. The DIA framework is part of the open UNTP specification and hence does not require the adoption of specific proprietary platforms or central databases.

Article V: Data Protection and Privacy​

In the initial implementations of the GRID and use of DIAs, no private identifiable information of individuals is to be included. Nevertheless, principles of data security, protection and privacy should be followed and all relevant regulations must be met.

  1. The principle of Data Minimization applies. The DIA shall contain only the attributes required for identity verification and discovery.

  2. Registrars shall implement privacy-by-design, ensuring that DIAs do not facilitate unauthorized tracking or profiling of legal entities beyond the scope of regulatory requirements and appropriate trade transparency.

5. Governance and Cross-Border Recognition​

See also the GRID Target Operating Model.

  1. The GRID as a Root of Trust: Verifiers shall use the GRID to retrieve the public keys of participating Authoritative Registrars to validate DIA signatures.

  2. Mutual Recognition: Following UNCITRAL Model Law on Identity Management (MLIT) principles, a DIA issued by a GRID-listed Registrar should be recognized as a reliable attestation of identity in cross-border transactions.

  3. Sustainability: The operation of the GRID discovery layer is supported by a cost-recovery membership model (based on the ICAO PKD model), ensuring the permanent availability of the directory for global verifiers.

Annex A: Registrar Operational Guide for DIA Issuance​

1. Separation of Concerns: Global vs. Local Management​

To maintain system resilience, Registrars must distinguish between their Operational Key (the public key of which is stored in the GRID) and the DIAs they issue (hosted in the Registrar's sovereign repository and dereferenceable via HTTPS/IDR).

  • The GRID (Global): Acts as the "Phonebook" for the Registrar’s Public Key. Participating Registrars update this when their organizational identity or signing keys change. Note that some changes will be subject to review by the GRID.

  • The DIA (Local): Acts as a specific "Attestation" for a registration. Registrars manage the lifecycle of these DIAs using a Revocation List (CRL) or an OCSP-like status check, without touching the GRID metadata.

2. Refined Lifecycle Triggers Table​

This table separates Entity-level events from Registrar-level events. Note that the actual events and states for entity's within a UN Member State Register are for the Registrar to determine. The following table is non-normative and provided as an illustation.

Event TypeTriggering EventAction RequiredInfrastructure Impact
Entity LevelNew RegistrationIssue initial DIA signed with current Registrar Key.Local Only: New DIA generated.
Entity LevelInsolvency / DissolutionUpdate DIA status to Revoked locally.Local Only: No change to GRID metadata.
Entity LevelSubject Key ChangeRe-issue DIA with the company’s new Public Key.Local Only: Old DIA is superseded.
Registrar LevelScheduled Key Rotation1. Generate new key pair.
2. Update GRID Metadata.		GRID Update: Global verifiers see new key.
Registrar LevelKey Compromise1. Immediately Revoke Registrar Key in GRID.
2. Re-issue all active DIAs.		High Impact: Immediate GRID update required.

3. Registrar Key Management & The GRID​

The GRID serves as the "Trust Anchor" for Registrar digital signature. Global verifiers (Customs, Banks, Port Authorities) and other supply chain participants will use the GRID to fetch a Registrar's current Public Key to validate DIAs they receive.

A. Key Rotation Protocol​

To maintain security best practices, Registrars should rotate their signing keys periodically (this is anticipated to be defined and agreed as a GRID operating procedure for participants).

  1. Preparation: Generate the new key pair in your secure environment (HSM).

  2. Notification: Update your metadata in the GRID.

  3. Grace Period: Allow a period where both the old and new keys are visible in the GRID to ensure continuity of verification. Prior public verification material must remain accessible via the Registrar's verifiable history log (e.g. did:webvh log) or historical archive so that credentials issued prior to rotation remain verifiable for past transactions.

B. Handling Registrar Key Compromise​

In the event a Registrar private signing key is stolen:

  1. Kill Switch: The Registrar's Point of Contact communicates to the GRID operation to request specific Registrar record(s) to be marked as "Suspended" or "Key Compromised."

  2. Immediate Warning: This instantly signals to automated systems to stop trusting DIAs signed with the compromised key.

  3. Recovery: Once secure, publish a new key to the GRID and re-sign your active DIA pool.

Footnotes​

  1. UNTP DIA Specification ↩

  2. W3C Verifiable Credential Data Model 2.0 ↩ ↩2

  3. UNTP DIA Specification 0.6 ↩

  4. UNTP Specification ↩