Skip to main content

Digital Identity Anchor - Legal Meaning and Data Structure

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.

1. Introduction​

1.1 Purpose and Scope​

This document explores the legal nature and technical architecture of the UNTP 1 Digital Identity Anchor (DIA) when issued by Authoritative Registrars who participate in the Global Registrar Information Directory (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" existing national and commercial identifiers in a verifiable credential issued by the Registrar.

The DIA is a W3C Verifiable Credential2, and is part of the UNTP Specification 1.

The issuance and use a UNTP Protocol Specification DIA is not limited to Authoritative Registrars participating in the GRID. Other organisations may choose to issue DIAs to 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 before they make the choice to develop the additional capability 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.

This document establishes the "Functional Equivalence" of a DIA as issued by Authoritative Registrars to traditional registry extracts while providing the cryptographic verifiability required for supply chain transparency.

1.2 The DIA as a Trust Wrapper​

A DIA issued by an Authoritative Registrar (AR) participating in the GRID serves as a secure and verifiable "envelope" of their existing registration process and identifier(s).

There are two core elements to the UNTP DIA:

  1. The registrar content. Relevant applicant information and identifier or identifiers issued by the AR together with any other content such as the Registrar name). This is subject to their UN Member State law and standards and is expected to follow their current practice.
  2. One or more decentralised identifiers (W3C DIDs) that the successful applicant controls and provides to the registar.

The AR checks that the applicant controls the DIDs (through cryptographic challenge and response) and then the AR cryptographically signs and issues the resulting DIA using their private key.

As a participant in the GRID, the AR registers and maintains their public key so that 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 DIA issuance is an optional extension of existing registrar processes.

2. DIA Data Structure (Normative)​

To ensure interoperability with the UNTP Specification, the GTR framework extends the base schema to accommodate the multi-identifier nature of global trade.

2.1 Proposed UNTP Schema Extension​

The are two extensions proposed to the existing DIA specification:

  1. Recognition that there is a difference between data issued and controlled by the Registrar and data provided by the registrant (such as DIDs) that are not under the control of the Registrar. We describe these in terms of "trustLevels".
  2. The option for a registrar to include more than one identifier value in the DIA. Current UNTP specifications define a single identifier for a legal entity. The GTR project proposes an extension to support a Multi-Identifier Trust Stack. This allows a Registrar to certify their own ID(s) and convey third-party IDs (GS1, LEI, etc.) without a liability shift - while the registar may verify supplementary IDs, it does not issue or control them.

Implementation Example​

The example below uses the JavaScript Object Notation Linked Data (JSON-LD) format.

{
  "credentialSubject": {
    "type": "DigitalIdentityAnchor",

    // 1. The Authoritative Sovereign Anchor
    "identifier": "123456789", 
    "scheme": "NationalBusinessRegistry_AU",

    // 2. The GTR Discovery Reference
    "registrar": {
      "name": "ASIC",
      "gridReference": "https://gtr.un.org/registrars/au-asic"
    },

    // 3. The Trust Wrapper (Proposed UNTP Extension)
    "supplementaryIdentifiers": [
      {
        "identifier": "549300863866281234",
        "scheme": "vLEI",
        "trustLevel": "Verified"  // Registrar verified this
      },
      {
        "identifier": "9312345678901",
        "scheme": "GS1_GLN",
        "trustLevel": "Asserted"  // Company claimed this; Registrar not liable
      }
    ]
  }
}

2.2 Rationale for Changes​

The following table explains the delta between the current UNTP spec and the GTR requirement:

AttributeUNTP Base SpecGTR 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 Global Trust Registry for root-key discovery.
supplementaryIdentifiersNot present.Added Array.Enables "Identifier Agnosticism"—allowing GS1/LEI to coexist with National IDs.
trustLevelNot present.Added Enum (Verified/Asserted).Critical for Liability: Protects Registrars by distinguishing between what they vet and what they merely convey.

2.3 The Trust Attribution Model​

Every data point within the supplementaryIdentifiers array MUST carry one of the following trustLevel flags:

  1. Verified: The Registrar has cross-referenced this information (e.g. confirmed control of DID, allocation of identifier etc.) against authoritative records.

  2. Asserted: The data is provided by the Organisation. The Registrar conveys it but assumes no liability for its accuracy.

Issuance models and Data Storage Implications

The intent of the DIA design is that enables the issuance of a cryptographically verifiable record of registration. Registrars are by definition keepers of records, and the aim is to minimise additional processes and records management. Should the Registrar decide to issue DIAs, then they will need to have management processes to support their life cycle and additional data storage.

The anticipated path for DIA issuance is that Registrars make them available for discovery and verification as participants in the UNTP transparency graph process. This means that Registrars will need to record all the data provided by the applicant.

If the DIAs are made available as cryptographic records to the applicant (issued to the applicant's enterprise wallet/repository) then there is a possibility to reduce the volume of data managed.

Article I: Legal Status and Non-Substitution​

  1. The DIA 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. Possession 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. A DIA may only be issued by an Authoritative Registrar — a public body or designated authority with a statutory mandate to maintain the register of truth.

  2. The GTR/GRID serves as the global "Trusted List" of these authorities. A DIA issued by an entity not listed in the GRID shall be deemed "Unverified" for the purposes of international trade facilitation.

Article III: Attribution and Liability​

  1. The Registrar is legally responsible for the accuracy of the data that they issue and control Authoritative Data.

  2. For data marked as Verified, the Registrar's liability is limited to the accuracy of the "linkage" between the entity and the data.

  3. For data marked as Asserted, the Registrar assumes zero liability. The relying party accepts this data at their own risk.

Article IV: Sovereignty and Choice​

  1. Participation in the GTR/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.

4. 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: 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 (stored locally or held by the subject).

  • The GRID (Global): Acts as the "Phonebook" for your Registrar’s Public Key. You only update this when your organizational identity or signing keys change.

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

2. Refined Lifecycle Triggers Table​

This table separates Entity-level events from Registrar-level events.

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 your current Public Key to validate any DIA 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.

B. Handling Registrar Key Compromise​

In the event your private signing key is stolen:

  1. Kill Switch: Use your administrative access to the GTR to mark your Registrar record 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.

4. Verification Flow: How the Separation Works in Practice​

When a verifier receives a DIA from a company:

  1. Step 1 (The Root): They check the GRID: "Is this Registrar legitimate, and what is their current Public Key?"

  2. Step 2 (The Leaf): They use that Public Key to check the DIA signature: "Is this a valid attestation from that Registrar?"

  3. Step 3 (The Status): They check the Registrar's Status Endpoint (linked in the DIA): "Is this specific DIA still active?"

Footnotes​

  1. https://untp.unece.org/ ↩ ↩2

  2. https://www.w3.org/TR/vc-data-model-2.0/ ↩