Skip to main content

Digital Identity Anchor - Legal Meaning and Data Structure

1. Introduction​

1.1 Purpose and Scope​

This document defines the legal nature and technical architecture of the Digital Identity Anchor (DIA) within the Global Trust Registry (GTR) framework.

The DIA is not a new identifier. 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 Credential1, and is part of the UNTP Specification 2.

This document establishes the "Functional Equivalence" of a DIA to traditional registry extracts while providing the cryptographic velocity required for modern supply chains.

1.2 The DIA as a Trust Wrapper​

The DIA serves as a secure and verifiable "envelope." While the content of the envelope (the identifiers) remains subject to national law and industry standards, the "seal" on the envelope is provided by an Authoritative Registrar listed in the GRID using their private key to cryptographically sign the credential.

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​

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 while safely conveying third-party IDs (GS1, LEI, etc.).

JSON-LD Implementation Example:​

{
  "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 identifier against their authoritative records.

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

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 only for the accuracy of the Authoritative Identifier.

  2. For identifiers marked as Verified, the Registrar's liability is limited to the accuracy of the "linkage" between the entity and the third-party ID.

  3. For identifiers 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 technologically neutral and does not require the adoption of specific proprietary platforms or central databases.

Article V: Data Protection and Privacy​

  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 trade transparency.

4. Governance and Cross-Border Recognition​

  1. The GRID as a Root of Trust: Verifiers shall use the GRID to retrieve the public keys of 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 (Revised)

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

To maintain system resilience, Registrars must distinguish between their Operational Key (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 and other supply chain participants will ping 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 (e.g., every 2–5 years).

  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://www.w3.org/TR/vc-data-model-2.0/ ↩

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