Digital Identity Anchor

info

Please note that this specification is suitable for pre-production pilot implementations.

Artifacts

v0.8.0 Schema and Samples

The JSON schema and sample credential instance for the Digital Identity Anchor are maintained in this repository.

• JSON Schema:

Schema	Description
DigitalIdentityAnchor.json	Full credential schema including the W3C VC envelope and RegisteredIdentity subject
RegisteredIdentity.json	Standalone schema for the RegisteredIdentity credential subject

• Sample Instances:

Sample	Description
DigitalIdentityAnchor_smelter_instance.json	Business register anchors the smelter owner DID to a corporate number
DigitalIdentityAnchor_mine_instance.json	Mining cadastre anchors the mine operator DID to a facility registration
DigitalIdentityAnchor_battery_instance.json	Trademark register anchors the battery manufacturer DID to a registered trademark
DigitalIdentityAnchor_accreditation_instance.json	Accreditation body anchors a conformity assessment body, recording the standards and schemes it is accredited against

The samples illustrate different register types — business, facility, trademark and accreditation. The first three anchor a DID from the copper-to-battery supply chain to an authoritative registered identity; the fourth shows an accreditation whose scope names the standards the body is assessed against.

Vocabulary and Context

The DIA is built on the UNTP Core Vocabulary, which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published under https://vocabulary.uncefact.org/untp/.

A credential references the versioned context, not that base path. For this release that is https://vocabulary.uncefact.org/untp/0.8.0/context/, which is what the samples on this page use. The unversioned path is where the vocabulary is published, not a context a credential can resolve.

The optional scopeCode values used in recognitionScope are defined by the recognition-scope code list in the UN/CEFACT vocabulary, alongside the registry-type list that registerType draws on.

Overview

The Digital Identity Anchor (DIA) credential provides a means to verify the real-world identity of UNTP credential issuers. The issuer.id property of all UNTP credentials is a W3C decentralized identifier (DID), which allows credentials such as Digital Product Passports (DPPs) to be cryptographically verified as genuinely issued by the entity that controls that DID. However, as a self-issued identity, the DID alone does not provide confidence that the issuer is really who they claim to be.

Authoritative identity registers — national business registers, trademark registers, mining cadastres, and similar institutions — exist in most countries and have well-established registration and verification processes. Unfortunately, most of these registers only issue paper or PDF registration certificates that are easily faked and cannot be used for digitally verifiable proof of identity.

The UNTP DIA bridges this gap. It is essentially a digitally verifiable version of a registration certificate, issued by the authoritative register to authenticated members after the member proves ownership of their DID. When a DIA accompanies a UNTP credential such as a DPP, a verifier can confirm not only that the DPP was issued by the holder of the DID, but also that the controller of the DID is the holder of an authoritative registered identity.

The DIA is expressed as a profile of W3C Recognized Entities v1.0, so that one implementation can satisfy both UN and W3C conformance. The W3C specification is a Candidate Recommendation and its data model is under active discussion — UNTP has raised issue #135 proposing changes that this profile anticipates. The property names and shapes below are therefore provisional and will be re-aligned when that discussion concludes. See Relationship to W3C Recognized Entities.

Conceptual Model

The Digital Identity Anchor (DIA) is a verifiable credential that is issued by a trusted authority and asserts an equivalence between a member identity as known to the authority (eg a VAT number) and one or more decentralised identifiers (DIDs) held by the member. Before issuing the DIA, the authority MUST verify DID ownership (eg using DID Auth).

The outcome is that the subject of the DIA (eg the VAT registered business) can prove that they are the registered identity to any other party. In the UNTP context the DIA provides assurance that a DPP (or DCC/DFR/DTE) issuer really is who they say they are. The verification workflow is as follows

• A verifier (eg buyer of an identified product) discovers a DPP for the product and verifies the credential - confirming that the DPP has not been tampered-with, is genuinely issued by party identified by the issuer DID.
• The DID is resolvable to the DID document which contains a link to the DIA in the DID document service endpoint.
• The verifier verifies the DIA credential and confirms that the DPP issuer DID matches the credentialSubject.id of the DIA.
• The verifier confirms that the DID of the issuing authority (the authoritative registrar for the jurisdiction) is on the trusted register list.

The DIA can also be used for similar trust anchoring purposes such as:

• Accreditation authorities issue DIA to assert that a conformity assessment body is accredited against a given scheme.
• IP Offices issue DIA to assert that a registered party is the genuine owner of a trademark.
• Land registers issue DIA to assert that a regulated party is the owner of a geo-located property.

Requirements

The digital identity anchor is designed to meet the following detailed requirements as well as the more general UNTP Requirements

ID	Name	Requirement Statement	Solution Mapping
DIA-01	Proof of DID control	The DIA issuer MUST establish, by a challenge-response exchange completed before issuance, that the party being anchored controls the DID named in credentialSubject.id, so that an impostor cannot have a well-known DID anchored to a registration they do not hold.	Proving control of the DID
DIA-02	DIA Issuer DID	The DIA issuer MUST use a supported DID method (see DID Methods) as the DIA issuer and the domain MUST match the well known domain of the issuing authority so that verifiers can confirm authority identity via public records.	CredentialIssuer.id — the issuer DID in the Credential Envelope
DIA-03	Scheme registration	The DIA issuing authority SHOULD register the identity scheme (including the trusted issuer DIDs) with the UN/CEFACT identifier scheme registry so that verifiers can leverage UN maintained scheme metadata to simplify DIA discovery and verification.	UN GRID for authoritative registers; UNTP implementation registers for others
DIA-04	Multiple DIDs	A registered member may need to link multiple DIDs to one registered ID, either because there is a need to transition between DID service providers or because an organisation may choose to use different DIDs for different purposes. A registrar MUST NOT overwrite, withdraw or revoke an anchor merely because the member's DID has changed, so that credentials signed under a previous DID remain verifiable.	Issue multiple DIAs; Superseding an anchor is not revoking it
DIA-05	Recognition scope	The DIA MUST state the scope of the recognition — what the registrar recognises the member to be, and under what mandate — as one or more resolvable URIs with a human-readable name, so that verifiers can confirm the basis of the registration.	RegisteredIdentity.recognitionScope
DIA-06	Register Type	The DIA MUST specify the register type so that verifiers can understand the context of recognitionScope	RegisteredIdentity.registerType
DIA-09	W3C profile	The DIA MUST be typed as both DigitalIdentityAnchor and RecognizedEntityCredential, and its credentialSubject as both RegisteredIdentity and RecognizedEntity, so that a conforming W3C recognized-entity processor can consume a DIA unchanged.	Relationship to W3C Recognized Entities
DIA-10	No amplification	Where a DIA is one link in a delegation chain, a verifier MUST NOT accept a recognition scope broader than the scope held by the issuing registrar for the aspect being tested.	Delegation and non-amplification
DIA-07	DIA Discovery	The DIA SHOULD be discoverable given either the DID or the registeredID	DIA Discovery
DIA-08	White list	The DIA should include a mechanism to avoid malicious actors who are not the registrar from issuing DIAs that claim links to authoritative registered IDs	UN GRID and UNTP implementation registers maintain trusted issuer lists

The examples below help to clarify the application of DIA-05, DIA-06 and DIA-10.

Logical Model

The Digital Identity Anchor binds a registered identity to a DID controlled by the registered member. The diagram below shows the registered identity — the credential subject carried inside the credential envelope — and the components it composes. The surrounding W3C Verifiable Credential envelope (issuer, validity, status, rendering) is omitted for clarity; it is shown in full under Credential Schema.

Read it outwards from RegisteredIdentity at the centre. Its own attributes are the binding itself: id is the DID whose control the registrar proved, and registeredId is the number the register holds, given meaning by the idScheme it was issued under. registrar identifies the authority operating the register, and registerType tells a verifier what kind of register this is.

recognitionScope carries what the registrar recognises about the member — the legal form, licence category or classification class, and any standards or schemes the recognition rests on. Each entry may name the scheme it is drawn from, because a registrar commonly publishes several.

Each box is an object; each labelled arrow is a property, with its cardinality (1, 0..1, *) shown at the target end.

Credential Schema

The full JSON Schema for the credential — the W3C Verifiable Credential envelope wrapping the Registered Identity subject — is the working version, a candidate for UNTP v1.0.0.

Loading schema viewer...

For detailed class and property definitions, see the Core Vocabulary reference. For implementation details, sample JSON-LD snippets, and register-specific use cases, see The Components of a DIA below.

Relationship to W3C Recognized Entities

The DIA and W3C Recognized Entities v1.0 address the same problem — letting a verifier establish that an issuer is recognised by an authority — and the W3C specification carries a UN GRID cross-border trade example describing the same three-tier chain UNTP implements. UNTP therefore expresses the DIA as a profile of that model rather than as a parallel design.

Provisional

W3C Recognized Entities is a Candidate Recommendation and its data model is under discussion. UNTP has raised vc-recognized-entities#135, arguing that the current model assumes every recognition confers a list of permitted actions, which does not hold for the most common case — a register that records that an entity exists and what legal form it takes, while constraining nothing. The recognitionScope shape below anticipates the outcome of that discussion and will be re-aligned when it concludes. Terms UNTP has proposed but W3C has not yet adopted are minted in the UNTP namespace rather than the Recognized Entities one. The W3C context URL is not yet published.

What the profile adds

W3C defines the recognition relationship but not the register-managed identifier. A RecognizedEntity carries only the subject's DID, so there is no way to state the number the register actually holds — the company number, licence number or accreditation number a verifier looks up. UNTP adds it:

DIA property	Status in W3C Recognized Entities
registeredId	Not defined. Proposed upstream in vc-recognized-entities#132
idScheme	Not defined. The scheme that gives registeredId its meaning
registeredDate, registerType	Not defined
registrar	Expressed by W3C as issuer; retained for convenience
publicInformation	Adjacent to the general url and sameAs properties, but specifically the register's own record of this entity

What the profile constrains

W3C property	UNTP profile
credentialSubject.id	MUST be a DID, and the registrar MUST have proved control of it — see Proving control of the DID. W3C permits any URL and says nothing about proof
credentialSubject	Exactly one RecognizedEntity. W3C permits a set; a DIA anchors one registration
recognizedIn	Omitted. UNTP uses identifier-based discovery — resolve the DID, follow the service endpoint — which is the mode the W3C GRID example itself recommends for scale. recognizedIn supports credential-based discovery and bridging to non-VC trust lists such as X.509 CA lists; neither applies here
legalName, name, image, url, sameAs, description	MAY be used. registeredName carries the legally registered name

Recognition scope

The v0.8.0 registrationScope property was described as "the roles or scopes of membership" but was used in practice for whatever the register recorded about an entity — a legal form, a licence category, a classification class. It is replaced by recognitionScope, an array in which each entry references a definition the registrar itself publishes:

"recognitionScope": [{
  "type": ["RecognitionScope"],
  "scopeCode": "legal-form",
  "id": "https://sample-business-register.example.com/entity-types/private-company-limited-by-shares",
  "name": "Private Company Limited by Shares",
  "scheme": {
    "type": ["IdentifierScheme"],
    "id": "https://sample-business-register.example.com/entity-types",
    "name": "Sample Business Register Entity Types"
  }
}]

• id is the authoritative meaning. Authority stays with the register, and UNTP maintains no list of the world's legal forms, licence classes or accreditation categories.
• name is the value as the register names it, in the register's own language — Kabushiki Kaisha, GmbH, Private Company Limited by Shares — so a verifier can display something meaningful without dereferencing.
• scheme is optional and identifies which of the registrar's controlled lists the value is drawn from. It matters because one registrar commonly publishes several, and the value URI alone does not say which.
• scopeCode is an optional discoverability hint from the UNTP recognition scope vocabulary, answering "which of these entries is the legal form?" without dereferencing every scheme. There is no other value: where no code fits, omit it.

A single property works across register types because the question is the same in each — a business register records a legal form, a mining register a licence category, a trademark register a classification class, an accreditation body a class plus the standards it accredits against. registerType tells a verifier how to read them.

Delegation and non-amplification

Where a DIA is one link in a chain — the UN GRID recognises a national registrar, which anchors a company, which issues a product passport — a verifier checks that no link grants more than it was granted. The check is scoped to the question being asked: for the scope entry under test, every level of the chain must carry a matching or broader entry. Entries irrelevant to the question are not compared, which is why a company's legal form is never tested against what GRID granted its registrar.

Matching is by URI. Where an authority publishes a scope hierarchy, a verifier MAY dereference a scope URI and accept a declared skos:broader relationship to an entry held at the level above. Anything a verifier can neither match nor resolve fails closed.

Validation rules live outside the credential

A DIA records what the authority asserts and governs — the identity, the registered number, and the scope of the recognition. It deliberately does not carry rules for validating the credentials its subject goes on to issue.

Those rules belong in graph validation shapes, and UNTP already publishes them. AssessorAccreditedForScope checks that the issuer of a conformity credential holds a DIA whose recognitionScope covers the scheme or profile being attested; IssuerDiaSubjectMatch checks that an issuer DID is anchored at all. The rule is a query over the graph, maintained by the community that maintains the schemas it refers to.

The reason is lifecycle. A registrar refreshes an accreditation on its own cycle — annually, or on audit — and that cycle has nothing to do with how often a credential schema is versioned or a criterion URI is restructured. Embedding a schema reference in a DIA would mean reissuing registration credentials whenever a downstream artefact changed, which is not how any register works and not something a registrar could be asked to track. The DIA is the digital counterpart of the paper certificate the authority already issues, and it should carry what that certificate carries.

W3C Recognized Entities defines an optional outputValidation property for ecosystems that want in-credential constraints. The UNTP profile does not use it.

Implementation Guidance

Who Issues DIAs?

DIAs are issued by authorities that already operate authoritative identity registers — national business registers, mining cadastres, trademark offices, accreditation bodies, and similar institutions. These authorities have well-established registration and verification processes. The DIA simply extends their existing function by issuing a digitally verifiable credential that binds a member's DID to their registered identity, rather than only issuing paper or PDF registration certificates.

The critical trust question for a verifier is: how do I know that the DIA issuer is genuinely the authority it claims to be, and not a fraudulent actor masquerading as an authoritative register?

Any credential issuer

The business, facility, and trademark samples on this page illustrate registerType. The same DIA anchors any issuer of a DPP, DCC, DFR, or DTE, including parties whose role is trade execution: an exporter, importer, carrier, freight forwarder, customs broker, certifier, regulator, or trade-finance institution.

The role is recorded in recognitionScope (DIA-05). A customs-broker licence, a carrier authorisation, or an accreditation is a scope on a registration the party already holds. registerType remains one of business, facility, product, trademark, land, or accreditation.

A party may be the subject of several DIAs. Each register asserts only the identity it is competent to assert. A national business register may anchor the legal entity, and a separate licensing authority may anchor a broker authorisation. The registers stay independent. Statutory registers are listed in the UN GRID. Other schemes are listed in the UNTP implementation registers. UNTP does not publish a catalogue of which register covers which trade role, and it does not add a central identity authority to fill gaps between registers.

Where no register covers a role, the party may still issue credentials from its DID. Verification then confirms that the credential was signed by the controller of that DID. Confidence that the controller holds a registered identity starts when a register that knows the party issues a DIA. The verifier decides which DIAs it accepts.

A carrier's Digital Traceability Event and a customs broker's credential in the same shipment are checked the same way, using DIA Discovery: resolve the issuer DID, follow the untp:dia service endpoint, verify the DIA, and confirm the DIA issuer is a recognised register. recognitionScope shows whether that registration covers the role the verifier needs. Names of registers in an implementation are illustrative. The directory of statutory registers is the UN GRID.

Authoritative Registers and the UN GRID

The UN/CEFACT Global Registrar Information Directory (GRID) is designed to address this trust question for authoritative registers operated by regulatory authorities in UN member states. Registers listed on the GRID — such as national business registers, land registries, and government-operated accreditation bodies — are maintained by recognised sovereign authorities. When a DIA issuer DID appears on the GRID, a verifier can have high confidence that the issuer is the legitimate authority for that identity scheme.

Register operators that wish to issue DIAs should:

1. Register their identity scheme on the UN GRID, including their trusted issuer DID(s).
2. Implement DID Auth or equivalent DID ownership verification before issuing DIAs to registered members.
3. Make DIAs discoverable from both the member's DID document and the register's identity resolver service.

Non-Authoritative Registers

UNTP recognises that trust in the supply chain ecosystem is also supported by identity assertions from registers that are not operated by sovereign regulatory authorities. These include product registers (e.g. GS1 GTIN), industry association membership registers, facility registers operated by industry bodies, and similar non-governmental schemes. While these registers may not carry the same sovereign authority as government registers, they are nonetheless well-established and trusted within their respective domains.

Because the UN GRID is designed to list only registers operated by regulatory authorities in member states, these non-authoritative registers are not eligible for GRID listing. Instead, UNTP maintains lists of recognised non-authoritative registers in its implementations register pages, providing a similar level of register identity assurance. Verifiers can consult both the UN GRID (for authoritative registers) and the UNTP register pages (for non-authoritative registers) to determine whether a DIA issuer is a recognised register operator.

Proving control of the DID

A DIA asserts that a registered identity and a DID belong to the same party. That assertion is only worth anything if the registrar established, before issuing, that the party in front of it actually controls the DID. Otherwise anyone could present a well-known DID — a competitor's, or a large brand's — and have it anchored to their own registration, which is the single most damaging failure available against this credential.

DIA-01 therefore requires a challenge-response exchange, not a declaration. Asking an applicant to type a DID into a form, or to upload a document naming one, does not establish control. Neither does resolving the DID and finding a plausible organisation name in the DID document.

What the exchange must establish

Before issuing a DIA, the registrar MUST:

1. Generate a fresh, unpredictable challenge — a nonce with sufficient entropy, bound to this issuance and used once. It MUST have a short expiry, and the registrar MUST reject a response to an expired or already-used challenge.
2. Require the applicant to return a proof over that challenge, signed by a key that the DID document names for authentication.
3. Resolve the DID itself, from the DID's own method, at verification time. The registrar MUST NOT rely on a DID document supplied by the applicant.
4. Verify the signature against a verification method listed under authentication in the resolved DID document. A key that appears only under other verification relationships, such as keyAgreement, MUST NOT be accepted.
5. Confirm the DID in the proof is the DID being anchored — byte-for-byte the value that will appear in credentialSubject.id.
6. Retain evidence of the exchange, so the registrar can demonstrate the basis on which it issued. Retention SHOULD extend for the life of the DIA. Where a registrar's own regulatory framework caps how long it may hold such records, that framework governs, and the registrar SHOULD record that the exchange took place and when, even once the evidence itself has been disposed of.

DID Auth is the RECOMMENDED protocol. A W3C Verifiable Presentation containing the challenge and signed by the applicant's DID satisfies the requirement equally, and reuses machinery a UNTP implementer already has.

When it must be repeated

Proof of control is a point-in-time fact, so:

• A new DID for an existing registration needs its own exchange. DIA-04 allows a registered identity to have several DIDs, and each is separately proved and separately anchored.
• A change of key within the same DID does not require re-proof; that is what the DID document is for. A change of DID controller does, because control is precisely what was established.
• Registrars SHOULD re-verify periodically for long-lived anchors. How often is the registrar's call, and is best tied to a cycle it already runs — on renewal of the underlying registration, or at audit — rather than a separate schedule. Where a registrar has no such cycle, annual re-verification is a reasonable default. What matters is that the interval is published, so a verifier can reason about how stale a binding might be.

Superseding an anchor is not revoking it

A member's DID changes more often than its registration does — most commonly when the member moves between software providers, since a DID hosted on a provider's domain does not travel with the customer. Each DIA is bounded by validFrom and validUntil, which makes it a statement about a period rather than about the present, and a verifier checking a credential signed two years ago needs the binding that was current then.

• A registrar MUST NOT overwrite, withdraw or revoke an anchor merely because the member's DID has changed. It issues an additional anchor for the new DID (DIA-04) and leaves the superseded one in place, bounded by its validity dates, so that credentials signed under the previous DID remain verifiable.
• Revocation via credentialStatus is for a different situation: the binding was never true, was obtained fraudulently, or the underlying registration itself has ended. It says this assertion should never have been relied on, which is not what a change of software provider means.
• A registrar that treats an anchor as a record of current state, and updates it in place, silently breaks every credential its member ever issued. The signature still verifies; nothing any longer connects the signing DID to the registered entity, which is the whole purpose of the anchor.

A registrar that issues a DIA without this exchange undermines every credential downstream of it, because the whole chain rests on the binding the DIA asserts.

The Components of a DIA

This section provides sample JSON-LD snippets for each DIA component, drawn from the smelter identity anchor sample.

Credential Envelope

All DIAs are issued as W3C Verifiable Credentials (VCDM 2.0). The credential type includes both VerifiableCredential and DigitalIdentityAnchor, and the @context references both the W3C VCDM and UNTP context URIs. Critically, the issuer MUST be the authoritative register itself — not the entity whose identity is being anchored. The issuer id SHOULD be a DID using a supported DID method, and the domain MUST match the well-known domain of the issuing authority so that verifiers can confirm registry identity via public records. Please refer to DPP VC Guidance for further information about the use of the verifiable credentials data model for UNTP.

{
  "type": ["DigitalIdentityAnchor", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.8.0/context/"
  ],
  "id": "https://credentials.houjin-register.example.com/dia/ref-001",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:houjin-register.example.com",
    "name": "Sample National Tax Agency — Corporate Number System",
    "issuerAlsoKnownAs": [
      {
        "id": "https://www.houjin-register.example.com",
        "name": "Sample National Tax Agency"
      }
    ]
  },
  "validFrom": "2025-04-01T00:00:00Z",
  "validUntil": "2027-03-31T00:00:00Z",
  "name": "Corporate Identity Anchor — Sample Copper Refinery Co. Ltd",
  "credentialSubject": {
    "type": ["RegisteredIdentity"],
    "...": "..."
  }
}

Registered Identity

The RegisteredIdentity is the credentialSubject of the DIA. It establishes the binding between a DID controlled by the subject and a registered identity in the authoritative register.

• id MUST be the DID of the registered member, and the registrar MUST have proved that the member controls it before issuing — see Proving control of the DID.
• registeredName is the entity name as it appears in the authoritative register.
• registeredId is the identifier value that is unique within the register (but may not be globally unique), for example a corporate number, facility licence number, or trademark registration number.
• registeredDate is the date the entity was first registered.
• publicInformation links to the public record on the registrar's site.
• idScheme identifies the identifier scheme operated by the registrar. If the scheme is registered with UN/CEFACT then idScheme.id MUST match the identityRegister.id in the UN/CEFACT scheme register.
• registrar identifies the authority that operates the register.
• registerType classifies the register (one of business, facility, product, trademark, land, accreditation), allowing verifiers to distinguish between different DIA use cases.
• recognitionScope states the scope of the recognition — what the registrar recognises this entity to be and under what mandate. See Recognition scope.

Worked examples for each register type are shown in the use case sections below.

Use Case: Business Register

A national business register issues a DIA to anchor a company's DID to its registered corporate identity. This is the most common DIA use case — it allows a verifier who receives a DPP, DFR, or DCC issued by the company to confirm that the issuer DID is controlled by a legitimately registered business entity. In this example, the Japanese corporate number register anchors the copper refinery's DID to its corporate number.

"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-refinery.example.com",
  "registeredName": "Sample Copper Refinery Co. Ltd",
  "registeredId": "REF-001",
  "registeredDate": "1985-06-15",
  "publicInformation": "https://www.houjin-register.example.com/henkorireki-johoto.html?selHouzinNo=REF-001",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://www.houjin-register.example.com",
    "name": "Japan Corporate Number (Houjin Bangou)"
  },
  "registrar": {
    "id": "https://www.houjin-register.example.com",
    "name": "Sample National Tax Agency"
  },
  "registerType": "business",
  "recognitionScope": [
    {
      "type": ["RecognitionScope"],
      "scopeCode": "legal-form",
      "id": "https://www.houjin-register.example.com/EntityType?Id=kabushiki-kaisha",
      "name": "Kabushiki Kaisha",
      "scheme": {
        "type": ["IdentifierScheme"],
        "id": "https://www.houjin-register.example.com/entity-types",
        "name": "Houjin Register Entity Types"
      }
    }
  ]
}

Use Case: Facility Register

A national mining cadastre or environmental register issues a DIA to anchor a facility operator's DID to a registered mine site or production facility. This allows verifiers to confirm that the operator of a facility — as identified by their DID in a Digital Facility Record — is the legitimate holder of the facility licence. In this example, the Sample Mining Cadastre anchors the mine operator's DID to its large-scale mining licence.

"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-mine.example.com",
  "registeredName": "Sample Copper Mine",
  "registeredId": "ZM-NW-CU-0012",
  "registeredDate": "2003-09-22",
  "publicInformation": "https://sample-mining-register.example.com/facilities/ZM-NW-CU-0012",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://sample-mining-register.example.com",
    "name": "Sample Mining Cadastre"
  },
  "registrar": {
    "id": "https://sample-mining-register.example.com",
    "name": "Sample Mining Register"
  },
  "registerType": "facility",
  "recognitionScope": [
    {
      "type": ["RecognitionScope"],
      "scopeCode": "entity-class",
      "id": "https://sample-mining-register.example.com/LicenceType?Id=large-scale-mining",
      "name": "Large-Scale Mining Licence",
      "scheme": {
        "type": ["IdentifierScheme"],
        "id": "https://sample-mining-register.example.com/licence-types",
        "name": "Sample Mining Licence Types"
      }
    }
  ]
}

Use Case: Trademark Register

A national intellectual property office issues a DIA to anchor a trademark owner's DID to a registered trademark. This allows verifiers to confirm that the entity using a brand name on product passports is the legitimate owner of that trademark. In this example, a national patent and trademark office anchors the battery manufacturer's DID to its registered "VoltCell" trademark under Sample Goods Classification class 9 (batteries and electrical apparatus).

"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-battery.example.com",
  "registeredName": "VoltCell",
  "registeredId": "302024001234",
  "registeredDate": "2022-03-10",
  "publicInformation": "https://sample-trademark-office.example.com/trademarks/302024001234",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://sample-trademark-office.example.com",
    "name": "Sample National Trademark Register"
  },
  "registrar": {
    "id": "https://sample-trademark-office.example.com",
    "name": "Sample Patent and Trademark Office"
  },
  "registerType": "trademark",
  "recognitionScope": [
    {
      "type": ["RecognitionScope"],
      "scopeCode": "entity-class",
      "id": "https://sample-trademark-office.example.com/goods-classes/9",
      "name": "Goods Class 9 (electrical apparatus)",
      "scheme": {
        "type": ["IdentifierScheme"],
        "id": "https://sample-trademark-office.example.com/goods-classes",
        "name": "Sample Goods Classification"
      }
    }
  ]
}

DIA Discovery

DIA credentials SHOULD be discoverable from either identifier:

• Given a DID (eg as the issuer of a DPP) via DID document service endpoint.
• Given a registered identifier (eg a VAT registration number) via the ID scheme resolver service.

Via DID Service Endpoint

As described in the W3C Decentralized Identifiers specification, DIDs are resolvable to a DID document. The service property of a DID document contains an array of typed serviceEndpoint which can point to services or credentials relevant to the DID. A DID document may also contain an "alsoKownAs" property which is typically used to reference other identifiers. Controllers of DIDs that are linked to authoritative register SHOULD

• Include the URI of registered identifier in the alsoKnownAs property of the DID document to establish a bidirectional link. In the snippet below https://sample-register.gov/90664869327 has been added.
• Add proof that the relationship is reciprocal by adding a service object that references the DIA credential. In the example below, the DIA credential URL is https://sample-credential-store.com/credentials/dia-90664869327.json

{
  "id": "did:method:sample-business.com:123456789",
  "authentication": [{..}],
  ..
  "alsoKnownAs": ["https://sample-register.gov/90664869327"],
  "service": [{
    "id":"did:method:sample-business.com:123456789#90664869327",
    "type":"untp:dia"
    "serviceEndpoint": {
        "href":"https://sample-credential-store.com/credentials/dia-90664869327.json",
        "title":"Digital Identity Anchor",
        "type": "application/vc+jwt"
    }
  }]
}

Via Identity Resolver

As described in the UNTP Identity Resolver specification, existing identity registers are encouraged to make their registered identities resolvable and verifiable.

• Identifiers are made resolvable by implementing ISO-18975 to encode IDs as URLs and returning an IETF rfc-9264 link-set with links to relevant further data about the ID.
• Identifiers are made verifiable by issuing DIAs per this specification.

This presents the opportunity to make the DIA discoverable by returning an appropriate link in the link-set. For example, given a VAT registration number 90664869327 issued under scheme https://sample-register.gov and applying the scheme resolver template may yield a resolver service URL of https://resolver.sample-register.gov/vatNumber/90664869327

The resolver service may be called with parameters that define which link-types to return. https://resolver.sample-register.gov/vatNumber/90664869327?linkType=all will return a linkset that SHOULD contain the DIA credential link (among other links such as the registration history) as follows.

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.gov/vatNumber/90664869327",
      "untp:dia": [
        {
          "href": "https://sample-credential-store.com/credentials/dia-90664869327.json",
          "title": "Digital Identity Anchor",
          "type": "application/vc+jwt"
        }
      ]
    },
    {
      "anchor": "https://resolver.sample-register.gov/vatNumber/90664869327",
      "about": [
        {
          "href": "https://sample-register.gov/registrationHistory?id=90664869327",
          "title": "Registration History",
          "type": "text/html"
        }
      ]
    }
  ]
}

Alternatively, invoking the resolver service with the DIA specific link type https://resolver.sample-register.gov/vatNumber/90664869327?linkType=untp:digitalIdentityAnchor would redirect directly to the matching link

   https://sample-credential-store.com/credentials/dia-90664869327.json