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

A DIA references the versioned UNTP JSON-LD context alongside the W3C Verifiable Credentials context:

"@context": [
  "https://www.w3.org/ns/credentials/v2",
  "https://vocabulary.uncefact.org/untp/0.8.0/context/"
]

UNTP terms resolve against the UN/CEFACT vocabulary at https://test.uncefact.org/vocabulary/, including the two code lists this credential draws on: recognition-scope for scopeCode and registry-type for registerType.

The DIA is an implementation of W3C Recognized Entities v1.0, so one implementation can satisfy both UN and W3C conformance. UNTP vocabulary is used only for what Recognized Entities does not define; Relationship to W3C Recognized Entities sets out which terms come from where.

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 the registered member. Where the DIA anchors a member DID (its full semantic), a verifier receiving a DPP or other UNTP credential signed under that DID can confirm not only that the credential was issued by the holder of the DID, but also that the controller of the DID is the holder of an authoritative registered identity. A DIA may also be issued without yet anchoring a DID, as a register-signed attestation of registration; see Adoption pathway for registrants without a DID.

Conceptual Model

The Digital Identity Anchor (DIA) is a verifiable credential issued by a trusted authority that attests to a registered identity. Where the DIA anchors a DID, it asserts an equivalence between the member identity as known to the authority (eg a VAT number) and one or more decentralised identifiers (DIDs) held by the member. Before issuing a DIA that anchors a DID, 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.

Where a DIA names an authoritative URI as its subject rather than a DID, the issuer-to-subject cross-check in step three does not apply; the DIA attests to the registration but makes no key-binding claim, so a DPP signed under some DID cannot be bound to that attestation through the DIA alone.

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.

Design 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
01	Proof of DID control	credentialSubject.id SHOULD be a DID. Where it is a DID, the DIA issuer MUST establish, by a challenge-response exchange completed before issuance, that the party being anchored controls that DID, so that an impostor cannot have a well-known DID anchored to a registration they do not hold. Where it is the register's own authoritative URI for the entity, the DIA attests to the registration without anchoring any DID and no DID-control proof applies.	Proving control of the DID
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
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
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
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
06	Register Type	The DIA MUST specify the register type so that verifiers can understand the context of recognitionScope	RegisteredIdentity.registerType
07	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
08	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
09	DIA Discovery	The DIA SHOULD be discoverable given either the DID or the registeredID	DIA Discovery
10	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 Recognition scope, Register Type and No amplification.

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 subject identifier — a DID whose control the registrar proved, where present — 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.

A DIA is typed as both DigitalIdentityAnchor and RecognizedEntityCredential, with its subject typed as both RegisteredIdentity and RecognizedEntity, so a conforming Recognized Entities processor consumes a DIA unchanged.

Those two W3C class terms need a note, because Recognized Entities has no vocabulary namespace or JSON-LD context of its own yet and its own examples borrow the VC examples context. UNTP declares them against their normative definitions in the specification itself, §3.2 and §3.4, rather than against a namespace W3C has not minted. Following either IRI lands on the definition, which is what a term IRI is for. They re-point to the W3C context when there is one. That is the only W3C dependency a DIA has, and it affects two type IRIs rather than any property: a DIA is a valid UNTP 1.0 credential whatever Recognized Entities does next.

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	SHOULD be a DID. Where it is a DID, the registrar MUST have proved control of it before issuing — see Proving control of the DID. Where it is an authoritative identifier URI for the entity, the DIA attests to the registration without anchoring any DID. W3C permits any URL and says nothing about proof
credentialSubject	Exactly one RecognizedEntity. W3C permits a set; a DIA anchors one registration
recognizedIn	Optional, and SHOULD be omitted where the entity is discoverable from its own DID through a service endpoint — see Recognition resting on an external trust list
legalName, name, image, url, sameAs, description, digestMultibase	MAY be used, and the UNTP context defines each one so it expands to the same IRI a W3C processor expects — see General properties

General properties

W3C lists nine general properties any entity object may carry: id, type, name, legalName, image, url, sameAs, description and digestMultibase. A DIA MAY use any of them, and the UNTP context defines each so that it expands to the IRI a W3C processor expects — schema:name, schema:legalName, schema:url and so on, which is where the W3C Verifiable Credentials Data Model points name and description itself. Without those definitions an implementer following this page would get an IRI minted under the UNTP namespace instead, which is interoperable with nothing.

registeredName is the one that matters, because it states the same fact as legalName. Rather than carry both, the context maps registeredName onto schema:legalName, so a W3C processor reading a DIA finds the general property it is looking for and a UNTP implementer keeps the name a register would use. The vocabulary records the equivalence.

The nine are not added to the JSON Schema. registeredName, registeredId, idScheme and publicInformation already carry what a register asserts, and duplicating them as legalName, url and sameAs would give an implementer two places to put one fact. They are permitted rather than expected.

Recognition resting on an external trust list

UNTP uses identifier-based discovery: resolve the DID, follow the service endpoint, fetch the DIA. That is the mode the W3C GRID example recommends for scale, and where it is available recognizedIn adds nothing — a second route to the same anchor is a second thing to keep in step, and a verifier given two answers has to decide which one wins.

The case it does serve is a recognition that rests on a trust framework outside the Verifiable Credentials ecosystem. A certification authority listed in an X.509 CA list, or a trust service provider on an ETSI trusted list, holds a recognition whose root of trust is the origin of that list URL rather than any credential. recognizedIn lets a DIA name that list, so a verifier already working from the PKI side can see the same entity from the UNTP side:

"recognizedIn": {
  "id": "https://ec.europa.example/tsl/lotl.xml",
  "type": "ExternalEntityList"
}

type here is the JSON-LD type of the referenced list rather than a code value, so it must be a term the context defines: ExternalEntityList for a list published outside the Verifiable Credentials ecosystem, or RecognizedEntityCredential for one that itself conforms to Recognized Entities. W3C states those two as a SHOULD over an open type space; UNTP restricts the value to the two it can interpret, because a third type is something a verifier could not act on. A verifier fetches the id to find out which list specification the resource complies with, and stops if it does not support it. The list is a bridge to another trust framework, so a DIA that uses it is saying the recognition is also recorded there, not that a verifier must go there instead.

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.
• geoBoundary is optional and bounds a territorial scope, using the same ordered closed polygon of latitude and longitude points as a facility location. It answers a question the other fields cannot: a mining licence, a fishing quota or a customs-broker authorisation is granted over an area, and a name alone does not let a verifier test whether a coordinate falls inside it.

It bounds what the registrar recognises, not where the entity is. Use Case: Land Register shows it in a credential. A company's registered office is an address; the territory a licence is valid in is a scope on the recognition. Where the two coincide, as they often do for a single-site facility, the facility record carries the location and the anchor carries the scope. Include it only where the scope is territorial; a legal form has no boundary.

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 and the area it covers, 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 (Recognition scope design requirement). 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.

Adoption pathway for registrants without a DID

A DIA SHOULD anchor a DID, and where it does, the Proof of DID control design requirement has no exception. For most registers, nearly all members arrive without a DID, so the specification admits two shapes a DIA can take. A register's choice between them is a step on an adoption pathway rather than a limitation of the credential, and matches the inclusive maturity model set out in the GRID governance framework.

With a DID (full anchor). credentialSubject.id is a DID that the registrar has proved control of. The DIA binds the registered identity to a key the member holds, so a verifier receiving a DPP, DFR or DCC signed under that DID can confirm the DID is controlled by the registered entity. This is the full semantic the credential is designed for, and the one the use cases on this page show.

Without a DID (registration attestation). credentialSubject.id is the register's own URI for the entity — the same URI a verifier would reach by resolving registeredId under idScheme. No DID-control proof applies. The credential is a register-signed statement that this entity exists with these attributes; it makes no key-binding claim and does not say who may sign on the entity's behalf. This is the shape a registrar at an earlier stage of the GRID maturity model issues for members who have not yet adopted DIDs. A member that adopts a DID later gets a new DIA with the DID as credentialSubject.id through the challenge-response exchange, issued alongside the earlier registration-attestation DIA rather than replacing it (Multiple DIDs).

Two routes are then open to a registrar whose members are adopting DIDs, and a register chooses which it supports:

• The register mints a DID at registration and transfers control on request. Where it does, that DID MUST use did:webvh. With did:web the DID document is whatever the domain owner serves, so a register that hosts the identifier keeps the ability to replace the member's keys and a verifier cannot tell that it has. did:webvh keeps a signed, append-only history: after handover only the member's key authorises an update, an attempt to override it is visible in the log, and the identifier can be moved to a domain the member owns without changing. Those properties are what make the handover real rather than nominal.
• The member brings its own DID. did:webvh SHOULD be used, for the same auditability reasons, but any supported DID method is acceptable. A member that already operates a did:web on its own domain should not have to replace it in order to register.

A register MUST NOT create a DID for a member who has not asked it to, which is the general rule for claimed and unclaimed identifiers, applied by the Digital Facility Record to facility identifiers. A register may hold as many identifiers as it likes and publish directory information about them; what it must not do is speak for a member that has not asked it to. Nor should a register hold signing keys for its members as a matter of course: a register that both attests to registrations and signs on behalf of its members is a single breach away from being able to forge both.

Where a member has no capability to operate a DID at all, custody belongs with its software provider rather than with its register — see identifier control and key custody, which separates control of the identifier from custody of the signing key and sets out the arrangements in between. A compromised provider cannot forge registrations, and a compromised register cannot forge signatures; putting both in one place removes that separation. A member does not need to understand DIDs, but someone acting for it does.

Proving control of the DID

This section applies to a DIA whose credentialSubject.id is a DID. A DIA whose subject is the register's own authoritative URI for the entity makes no key-binding claim, so no DID-control proof applies — see Adoption pathway for registrants without a DID.

Where a DIA names a DID, it asserts that the registered identity and the 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.

The Proof of DID control design requirement 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. The Multiple DIDs design requirement 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 (Multiple DIDs) 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 SHOULD be the DID of the registered member. Where it is a DID, the registrar MUST have proved that the member controls it before issuing — see Proving control of the DID. Where it is the register's own authoritative URI for the entity, the DIA attests to the registration without anchoring any DID — see Adoption pathway for registrants without a 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",
  "idScheme": {
    "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",
  "idScheme": {
    "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",
  "idScheme": {
    "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"
      }
    }
  ]
}

Use Case: Land Register

A land authority issues a DIA to anchor a titleholder's DID to a registered right over an identified parcel. The territory recognition scope carries the parcel boundary, which is what lets a verifier check a claimed location against the title rather than take it on trust: a facility publishing a geoBoundary can point locationInformation.geolocationEvidence at this credential, and the facility's boundary must fall inside the parcel the title covers. A boundary that does not is a mismatch a verifier can detect; without the geometry it cannot.

In this example a national lands and deeds registry anchors the mine operator's DID to its registered mining lease over a parcel in North-Western Province.

"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-mine.example.com",
  "registeredName": "Sample Copper Mine Pty Ltd",
  "registeredId": "ZM-NW-TITLE-004187",
  "registeredDate": "2019-11-04",
  "publicInformation": "https://sample-lands-registry.example.com/titles/ZM-NW-TITLE-004187",
  "idScheme": {
    "type": ["IdentifierScheme"],
    "id": "https://sample-lands-registry.example.com/titles",
    "name": "Sample National Register of Titles"
  },
  "registrar": {
    "type": ["Party"],
    "id": "https://sample-lands-registry.example.com",
    "name": "Sample Lands and Deeds Registry"
  },
  "registerType": "land",
  "recognitionScope": [
    {
      "type": ["RecognitionScope"],
      "scopeCode": "entity-class",
      "id": "https://sample-lands-registry.example.com/tenure-types/mining-lease",
      "name": "Mining Lease",
      "scheme": {
        "type": ["IdentifierScheme"],
        "id": "https://sample-lands-registry.example.com/tenure-types",
        "name": "Sample Register Tenure Types"
      }
    },
    {
      "type": ["RecognitionScope"],
      "scopeCode": "territory",
      "id": "https://sample-lands-registry.example.com/parcels/ZM-NW-04187",
      "name": "Parcel ZM-NW-04187, North-Western Province",
      "geoBoundary": [
        { "latitude": -12.15, "longitude": 26.35 },
        { "latitude": -12.15, "longitude": 26.41 },
        { "latitude": -12.2, "longitude": 26.41 },
        { "latitude": -12.2, "longitude": 26.35 },
        { "latitude": -12.15, "longitude": 26.35 }
      ]
    }
  ]
}

A title is a right over land, so the entity being recognised is the titleholder and the parcel is the scope of that recognition. The two scope entries say different things and a verifier should not conflate them: the first is what kind of tenure is held, the second is where it is held.

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