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¹ 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" a national or commercial identifier in a verifiable credential issued by the Registrar.

In terms of the data model, the DIA is a W3C Verifiable Credential².

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 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 Registrar Information Directory (GRID)" for details.

The practice of issuing DIAs is strongly encouraged as a mechanism to achieve supply chain transparency.

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:

The registrar content. This include 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.
A decentralised identifier (W3C DID) that the applicant controls and provides to the Registrar.

The AR checks that the applicant controls the DIDs (through cryptographic challenge and response), and then the AR creates the DIA and cryptographically signs the 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)

2.1 Proposed UNTP Schema Extension

It is proposed to recognise that 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).

The reason for this distinction is that inclusion of the applicant supplied DID in the DIA is not intended to change the legal meaning (responsibilities and liabilities) of the Registrar's registration process and outcome.

Implementation Example

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

{
  "credentialSubject": {
    "id": "did:example:applicant-did-here",
    "type": "DigitalIdentityAnchor",

    // 1. The Applicant's DID (Checked and linked by the Registrar)
    "decentralizedIdentifier": {
      "identifier": "did:example:applicant-did-here",
      "source": "Verified"
    },

    // 2. The Authoritative Sovereign Anchor
    "authoritativeIdentifier": {
      "identifier": "123456789", // the Registrar issued and controlled identifier
      "registeredName": "Aussie As", // the subject name as it appears in the Register 
      "scheme": "NationalBusinessRegistry_AU",
      "source": "Authoritative"
    },

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

    // 4. Extended optional content (proposed UNTP Extension)
    "supplementaryIdentifiers": [
      {
        "identifier": "549300863866281234",
        "scheme": "vLEI",
        "source": "Verified"  // Registrar cross-referenced this
      },
      {
        "identifier": "9312345678901",
        "scheme": "GS1_GLN",
        "source": "Asserted"  // Company claimed this; Registrar assumes no liability
      }
    ]
  }
}

Things to note about this example:

Options. We have shown a DIA that includes several identifiers. The decision of whether to accept additional (applicant supplied) data and whether or not any such data can or should be verified is entirely up to the Registrar.
Mandatory. The DIA structure MUST contain at least one Registrar issued identifier and the associated "name" registered for the subject, and one applicant supplied DID.

In addition, the following changes have been made to the original UNTP specification:

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.
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.
Implementation of the source taxonomy. The source attribute is applied universally across all identifier nodes. Within the supplementaryIdentifiers array specifically, the values Verified and Asserted are used to delineate between commercial identifiers (like the vLEI) that the Registrar has actively cross-referenced against authoritative records, and identifiers (like the GS1 GLN) that the applicant provides and the Registrar conveys with zero assumed liability.

2.2 Summary of Changes

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

Attribute	UNTP Base Spec	GTR Proposed Change	Rationale
`identifier`	Generic entity ID.	Authoritative Identifier.	Clarifies that the root ID is the one issued by the signing Registrar.
`registrar`	Implicit.	Added `gridReference`.	Links the DIA directly to the GRID for root-key discovery.
`supplementaryIdentifiers`	Not present.	Added Array.	Enables "Identifier Agnosticism"—allowing GS1/LEI to coexist with National IDs.
`source`	Not present.	Added Enum (Authoritative/Verified/Asserted).	Critical for Liability: Protects Registrars by distinguishing between what they control, what they actively vet and what they merely convey.

2.3 The Attribution Model

Every data point within the credential, including the primary registry identifier and any entries in the supplementaryIdentifiers array, MUST carry one of the following source classifications:

Authoritative. The data (such as the primary Authoritative Identifier) is natively generated, issued, and controlled by the Registrar.
Verified: The data is provided by the Organisation (such as the applicant's DID), and the Registrar has cross-referenced this information against authoritative records or confirmed cryptographic control.
Asserted: The data is provided by the Organisation. The Registrar conveys it and 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.

3. Legal Articles of the DIA

Article I: Legal Status and Non-Substitution

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.
Possession of a DIA does not discharge any legal requirement to maintain or present primary evidence (extracts/certificates) where mandated by national law.
The DIA is intended to provide Functional Equivalence for identity verification in digital-first trade environments.

Article II: Authority to Issue

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

For data marked as Authoritative, the Registrar is legally responsible for the accuracy of the data that they natively issue and control.**.
For data marked as Verified, the Registrar's liability is limited to the accuracy of the "linkage" between the entity and the data.
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

Participation in the GTR/DIA framework is voluntary.
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.).
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.

The principle of Data Minimization applies. The DIA shall contain only the attributes required for identity verification and discovery.
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.

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

Event Type	Triggering Event	Action Required	Infrastructure Impact
Entity Level	New Registration	Issue initial DIA signed with current Registrar Key.	Local Only: New DIA generated.
Entity Level	Insolvency / Dissolution	Update DIA status to `Revoked` locally.	Local Only: No change to GRID metadata.
Entity Level	Subject Key Change	Re-issue DIA with the company’s new Public Key.	Local Only: Old DIA is superseded.
Registrar Level	Scheduled Key Rotation	1. Generate new key pair. 2. Update GRID Metadata.	GRID Update: Global verifiers see new key.
Registrar Level	Key Compromise	1. 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).

Preparation: Generate the new key pair in your secure environment (HSM).
Notification: Update your metadata in the GRID.
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 a Registrar private signing key is stolen:

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."
Immediate Warning: This instantly signals to automated systems to stop trusting DIAs signed with the compromised key.
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:

Step 1 (The Root): They check the GRID: "Is this Registrar legitimate, and what is their current Public Key?"
Step 2 (The Leaf): They use that Public Key to check the DIA signature: "Is this a valid attestation from that Registrar?"
Step 3 (The Status): They check the Registrar's Status Endpoint (linked in the DIA): "Is this specific DIA still active?"

1. Introduction​

1.1 Purpose and Scope​

1.2 The DIA as a Trust Wrapper​

1.3 DIA Issuance Sequence​

2. DIA Data Structure (Normative)​

2.1 Proposed UNTP Schema Extension​

Implementation Example​

2.2 Summary of Changes​

2.3 The Attribution Model​

3. Legal Articles of the DIA​

Article I: Legal Status and Non-Substitution​

Article II: Authority to Issue​

Article III: Attribution and Liability​

Article IV: Sovereignty and Choice​

Article V: Data Protection and Privacy​

4. Governance and Cross-Border Recognition​