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

Pilot Design Architecture

1. Executive Summary​

The Pilot Design has been developed to test how the logical model for the GRID can be implemented using a decentralised, loosely coupled approach that retains participant sovereignty and resilience while keeping the pilot inexpensive and easy to operate.

The pilot is deliberately constrained to infrastructure and tools that can be made available through the UNICC GitLab environment and participant-controlled GitLab or GitHub repositories. It is an experimental architecture. It is not a commitment to the eventual production architecture, procurement model or operating platform.

Logical Model

Logical model of the Global Registry Information Directory

1.1 Pilot architecture in one sentence​

Participant-controlled Sovereign Nodes publish Registrar metadata and trust material; GRID authenticates the participant-origin evidence, harvests approved metadata, publishes the directory, and where the applicable pilot conditions are satisfied supports the DIA pathway used by relying parties.

1.2 Design objectives​

The pilot is intended to explore whether GRID can:

  • remain lightweight by harvesting only the metadata required for discovery and trust enablement;
  • allow Authoritative Registrars to remain in control of their source data and infrastructure;
  • authenticate participant-origin updates before treating them as trusted GRID input;
  • separate Registrar discovery from entity-level credential verification;
  • preserve clear trust and responsibility boundaries; and
  • support reproducible participant-to-GRID-to-relying-party verification.

2. Core Trust Boundaries​

2.1 Authoritative Registrar and Register Operator​

The pilot distinguishes legal accountability from technical operation.

The Authoritative Registrar is the body with the applicable statutory, legal or formally delegated competence and accountability for the register and its legally relevant contents.

A National or Delegated Register Operator may operate repository, API, hosting, CI/CD or support infrastructure under authority from the Registrar. Operating that infrastructure does not by itself make the operator the authoritative source.

Pilot onboarding should record separately, where applicable:

  • the Authoritative Registrar;
  • the legal or formal basis for its competence;
  • the operational Register Operator;
  • the delegation basis or reference;
  • legal/policy contact; and
  • technical/operational contact.

2.2 GRID discovery and Registrar authority​

GRID is a discovery, reference and trust-enablement layer. It does not replace the underlying register or become the source of legal effect for the facts held by the Registrar.

A GRID directory record should therefore remain distinguishable from:

  • the underlying register;
  • the Registrar itself;
  • the Registrar's source data;
  • an entity-level DIA; and
  • a business assertion made by a trading party.

2.3 GRID-to-Registrar trust and Registrar-to-entity identity evidence​

The pilot must not conflate two different trust relationships:

  1. GRID-to-Registrar participation/discovery evidence: evidence that a Registrar has been recognised or onboarded in the GRID pilot and that its published material has been authenticated according to the pilot process.
  2. Registrar-to-entity identity evidence (DIA): evidence issued under the applicable DIA model that relates an entity's authoritative registration identifier to the relevant subject or cryptographic identifier.

These relationships can have different issuer, subject, liability, lifecycle and verification semantics.

Control of a DID, signing key or other cryptographic identifier is a technical assurance. It must not by itself be represented as proof of legal identity, registration status, or authority to act for a legal person.

An entity's legal identity remains grounded in the applicable authoritative register. Authority for a person, employee, agent or automated system to act for that entity requires a separate basis where that question is in scope.

3. Resilient Harvest Model and Separation of Concerns​

The pilot uses a harvest model in which participant data remains under participant control and GRID consumes the material that the participant exposes for the pilot.

  • The participant Sovereign Node maintains Registrar metadata and, where applicable, DID/trust material on participant-controlled infrastructure.
  • The participant authenticates source changes using the cryptographic method agreed for the pilot.
  • The GRID Harvester retrieves the participant material and verifies participant-origin evidence before treating it as authenticated input.
  • The GRID publishing process generates the directory and pilot outputs.

The participant repository and source record remain the origin of participant metadata. A public JSON endpoint alone does not prove participant origin unless the pilot defines and successfully applies an authentication path linking the endpoint to authenticated participant source.

4. Source Authentication and Chain of Custody​

4.1 Internal and external pilot nodes​

The pilot currently supports two source-authentication patterns:

  • Internal bootstrap nodes may be verified using repository-native SSH signature mechanisms and the local allowed_signers configuration.
  • External Sovereign Nodes use the participant-origin mechanism agreed for the pilot, currently including GPG commit-signature verification for the external-node profile.

The mechanism is a pilot implementation choice and should not be read as a production trust requirement.

4.2 Sidecar verification​

Git signatures exist in repository history rather than inside the published metadata file. Where build-stage processing would otherwise lose that provenance, the pilot verifies at source and carries forward a sidecar or equivalent verification result so downstream generation can retain the authentication decision.

The required chain is:

The verification evidence should make it possible to reconstruct which source commit, signer, harvest run and output correspond to a given GRID state.

4.3 Key-purpose separation​

A participant repository-signing key and a DID verification key can serve different functions. They must not be assumed to be the same key.

For each key or cryptographic identifier, the pilot should document:

  • purpose;
  • owner/custodian;
  • trust relationship;
  • verifier;
  • activation and retirement state; and
  • rotation or compromise process.

GRID credential-signing keys should likewise remain distinguishable from participant repository-authentication keys.

5. DIA Conditions and Identifier Model​

5.1 DIA capability​

The GRID Pilots are interested in two types of DIA Issuer:

  1. The GRID Itself. The GRID issues DIAs for pilot participant Registrars that can create and control a DID. These are GRID issued DIAs and remain in the GRID Pilot controlled space.
  2. The Pilot Participant Registrars. Pilot Participants are encouraged to issue DIAs to represent their (test) pilot entries in their register. These are pilot participant issued DIAs and remain in the Pilot Participant controlled space.

Where DIA issuance is tested, the pilot should preserve the distinction between:

  • the legal act or status represented by the underlying register;
  • the authoritative identifier for the relevant registration purpose; and
  • the credential evidencing that identity or registration relationship.

A DIA does not create a new legal identity or a new identifier model merely because it introduces cryptographic material.

5.2 DID or cryptographic-identifier provisioning​

Where a DIA profile requires a DID or equivalent cryptographic identifier, the pilot should record the provisioning model. Supported experimental patterns may include:

  • applicant-controlled;
  • Registrar-provisioned; or
  • managed/delegated through an explicitly governed service provider.

Regardless of model, the pilot should record who generates and controls the private key, who may rotate or revoke it, how control is verified, how the authoritative organisation identifier is bound to the cryptographic identifier, and what happens when control changes.

In order to support history verification (see Verifiable History for details), the pilot design uses the did:webvh method as follows:

  • The node must publish its hash-chained event log at /.well-known/did.jsonl.
  • The Harvester and test verifiers must validate log continuity from the initial Self-Certifying Identifier (SCID) to the log tip.
  • Updates must test cryptographic pre-rotation using forward commitments in nextKeyHashes.

5.3 No cryptographic identifier, no entity-level anchor​

A Registrar can participate in the GRID without operating a DIA-capable profile. Where no DID is present, the Registrar can remain discoverable but the Registrar-level DIA is not issued by the GRID.

The absence of a DIA must not be represented as absence of Registrar authority or absence of GRID participation.

6. Technical Components​

6.1 GRID Hub​

The GRID pilot hub is the UNICC-hosted GitLab project that executes the harvesting and publishing pipeline and exposes the pilot directory and generated artefacts.

6.2 Sovereign Nodes​

Sovereign Nodes are participant-controlled repositories or equivalent publication environments used to maintain and publish participant Registrar metadata and trust material.

A typical hosted pilot node contains:

  • Registrar metadata under version control;
  • a participant DID document where DIA issuance is in scope;
  • signed source changes;
  • CI/CD that validates and publishes machine-readable output; and
  • predictable HTTPS endpoints.

A dedicated participant application server is not required for the baseline hosted profile.

Note use of did:webvh method as described in section 5.2.

6.3 Harvester​

The harvester should:

  1. locate the registered participant source;
  2. retrieve or clone the source as applicable;
  3. authenticate participant-origin evidence using registered trust material;
  4. reject or clearly flag unauthenticated material;
  5. validate Registrar data against the applicable schema;
  6. ingest accepted content; and
  7. expose sufficient evidence to associate source state with the resulting GRID state.

6.4 Generator and directory output​

The generation pipeline converts accepted Registrar data into the human-readable and machine-readable outputs required by the pilot. It should preserve source-to-output traceability and should fail visibly when required validation or authentication fails.

To preserve this source-to-output traceability for offline Relying Parties, the generator produces a signed Snapshot Manifest alongside the machine-readable directory (e.g., CSV). This manifest contains the cryptographic hash of the directory output, the pipeline execution identifier, and the GRID Hub's digital signature, allowing end-users to authenticate downloaded copies without querying the GRID for every transaction.

Each directory release manifest includes:

  • previous_manifest_hash: The SHA-256 hash of the preceding release manifest.
  • A canonical validity window (validFrom and validUntil).
  • Explicit instructions for Relying Parties to reject manifests exceeding maximum allowable cache age.

See Verifiable History for details.

6.5 DIA hosting​

The GRID Hub hosts Registrar Recognition DIAs in its directory space (URI: GRID_URL/registers/register_id/dia).

Sovereign Nodes host Tier 2 Entity DIAs in the Registrar's repository space (URI: REGISTRY_URL/entities/id/dia).

Verifiers resolve each credential directly from the respective issuer's trustworthy space.

7. Schema and Compatibility Discipline​

Every pilot payload should identify the schema version against which it was produced and validated.

Until a formal schema-version governance policy is applied to all pilot artefacts, implementations should:

  • pin or record the schema version used by each participant;
  • retain resolvable copies or references for versions used in evidence;
  • avoid assuming that an unversioned "latest" schema is backward compatible;
  • distinguish additive optional-field changes from breaking changes;
  • define migration behaviour before introducing newly mandatory fields; and
  • retain enough historical schema information to interpret previously issued records.

A pilot must not silently reinterpret a historical record using a newer incompatible schema.

Where more than one schema version is supported, compatibility testing should confirm that supported versions are accepted, unsupported versions fail explicitly, evidence records the schema version, and historical verification applies the schema appropriate to the artefact or a documented compatible interpretation.

8. Lifecycle, Status and Historical Verification​

See Verifiable History for details.

9. Production Boundary​

The current pilot deliberately simplifies several concerns that require separate production treatment. Examples include:

  • hosted Git and CI as an experimental operating substrate;
  • Git signatures as pilot-origin authentication;
  • simplified or manually managed participant onboarding;
  • pilot-grade key custody rather than a mandated production HSM/KMS model;
  • incomplete production status and revocation infrastructure;
  • manually configured harvester sources;
  • limited service-level and availability guarantees;
  • pilot-specific use of synthetic data; and
  • experimental proof and credential-processing choices.

Passing the pilot does not certify production readiness.

Pilot execution should actively collect evidence for later production decisions in the following areas:

  • Registrar authority authentication and onboarding;
  • key registration, rotation, compromise and historical validation;
  • availability, freshness and stale-state semantics;
  • Registrar and entity status semantics;
  • audit and retention requirements;
  • authoritative versus asserted data representation;
  • interoperability requirements;
  • support and service levels; and
  • automation of participant configuration without centralising authority.

10. GRID Operator Boundary​

GRID/UNICC operations are responsible for GRID-side actions including participant-source registration, harvester configuration, execution and monitoring of GRID-side pipelines, diagnostics, and any pilot DIA-generation action assigned to the operator.

A participant-side green CI status must not be interpreted as GRID-side success. The pilot should expose participant and GRID processing as separate evidence-bearing stages.

Detailed participant and GRID-side execution steps are in the Pilot Participant Guide.

11. Test Architecture​

The Pilot Test Sandbox contains the canonical synthetic supply-chain exemplar used to exercise this architecture. It tests:

  • Registrar discovery;
  • participant-source authentication;
  • DIA resolution and verification where available;
  • identifier and organisation-name consistency;
  • negative signature and schema cases;
  • stale and unavailable endpoints;
  • status and historical verification;
  • key-control versus legal-identity boundaries;
  • delegation/authority boundaries;
  • entity restructuring and termination scenarios;
  • verifying a transaction signed under a retired/rotated key using historical log traversal;
  • verifying a transaction against an archived directory snapshot for a Registrar that has since withdrawn; and
  • enforcing an INDETERMINATE result when an intermediate log or manifest entry is missing.

The Sandbox is test material, not a production dataset or normative specification.