How to Register an Identifier Scheme

This guide walks scheme operators through the steps required to get an identifier scheme listed in the UNTP Identifier Scheme (IDR) Register.

If you want to understand how the registry itself is governed (registrar role, agent operation, dispute and retention policy), see the Governance document. If you simply want to browse already-registered schemes, see the register itself.

Who should register

You are a candidate scheme operator if your organisation runs a registry that identifies products, facilities, organisations, members, locations, or key assets that appear in UNTP credentials. Typical IDR registrants include:

• Standards bodies operating product, location, or asset identifier schemes
• Industry associations issuing membership IDs
• Facility data services
• Asset registries (e.g. equipment, vehicle, instrument identifiers)

If you operate a register with statutory authority under national or treaty-based law (e.g. a national business register, land registry, official customs code list), your register belongs in GRID, not IDR. The two tiers complement each other; cross-tier linking via mirrorsAuthoritativeRegister is supported when applicable.

What you'll get when you're done

• An entry in the IDR Register at https://registers.uncefact.org/untp/idr/{your-scheme-slug}.
• A UNECE-issued Digital Identity Anchor (DIA) credential about your operator DID, hosted on your register entry — the trust anchor for your scheme.
• (If you issue DIA credentials to your registered entities) a verifiable trust chain UNECE → you → your members, navigable by any UNTP-aware verifier.
• (If you implement the UNTP IDR specification) discovery via every UNTP-aware tool.
• Discoverability for software vendors and community activations choosing identifier infrastructure.

Quick summary

The full process boils down to three things:

1. Publish an operator DID at a domain you control (typically did:web:yourdomain.org).
2. Expose a publicly reachable resolver service URL with an RFC 6570 URI template that accepts {id} as a variable.
3. Issue a registration Verifiable Credential describing your scheme, the identifier format, and the resolver template, and notify UNECE.

The registrar agent does the rest: tests your resolver with the example identifier, validates UNTP IDR conformance where claimed, samples DIA credentials issued to your registered entities where claimed, and writes signed observations.

UNECE then issues a DIA credential about your operator DID and hosts it on your register entry — completing the trust anchor.

Prerequisites

Before you start, you'll need:

Item	Notes
A web domain you control	Required for did:web and for hosting your registration VC.
A publicly reachable identifier registry service	The base URL the agent crawls + an RFC 6570 resolver URI template.
Identifier format declarations	A regex pattern for valid IDs, an example ID, and the canonical URI template per ID.
(Optional) A DIA-issuing capability	If you want the trust-anchor pathway, your scheme issues UNTP DIA credentials to its registered entities.
A representative who can liaise with UNECE	For initial onboarding and any future disputes.

You do not need:

• A pre-existing UNTP IDR-conformant resolver. You can register at pilot with implementsUntpIdr: false and migrate later.
• A pre-existing DIA-issuance capability. The trust-anchor pathway is optional but strongly encouraged.
• Statutory authority. If you have it, you belong in GRID; if you don't, IDR is the right home.

Step-by-step

Step 1 — Get in touch with UNECE

Tell UNECE you intend to register an identifier scheme. UNECE will create a proposed register entry as a placeholder while you set up your DID and verify your resolver. There is no review or approval gate at this stage — proposals are accepted on intent.

You'll receive a placeholder DID and a slug for your scheme entry; both will be replaced once you publish your real DID and registration VC.

Step 2 — Publish your operator DID

Stand up did:web:yourdomain.org (or another DID method you prefer). Your DID Document must include at least one assertionMethod verification method usable to sign Verifiable Credentials.

Notify UNECE of your DID URL. UNECE will replace the placeholder DID on your entry, and shortly after will issue a UNECE-signed DIA credential about your DID — this is the trust anchor that downstream verifiers use to confirm your scheme is duly registered. The DIA is hosted on your register entry.

Step 3 — Verify your registry service URL

Confirm that your registry's base URL is publicly reachable and returns useful content (an HTML landing page, an API description, or both). The agent crawls this URL on every cycle to verify reachability.

Step 4 — Define your identifier format

For your scheme, declare:

• registeredIdPattern — a regular expression that valid identifiers must match (e.g. ^\d{13}$ for a 13-digit numeric ID).
• registeredIdExample — an example valid identifier (e.g. 9506000164000). The agent compiles the regex and tests the example matches.
• registeredIdUriTemplate — an RFC 6570 URI template for constructing the canonical URI of any registered identifier, with {id} as the variable (e.g. https://id.example.org/scheme/{id}).

Step 5 — Define your resolver endpoint

Declare a resolverEndpoint URI template (with {id}) that resolves an identifier to verifiable data about the identified entity. The agent tests resolution by substituting your registeredIdExample into the template and confirming a 2xx response.

If your resolver implements the UNTP Identity Resolver specification — returning standard linksets with the documented link relations — set implementsUntpIdr: true and declare the spec version (e.g. 0.7.0). The agent will additionally test conformance.

If your resolver is custom (returns its own response shape), set implementsUntpIdr: false. You'll still be listed as a discovery directory entry; you just won't pass the UNTP IDR conformance check.

Step 6 — (Optional) Configure DIA issuance

If your scheme issues UNTP Digital Identity Anchor credentials to its registered entities (e.g. your members, registered facilities, or registered assets), set issuesDia: true.

If you use a community extension for your DIA credentials (e.g. a member DIA using an industry-extended DIA type), reference the extension's entry in the EXT register via diaExtension. The agent will cross-validate.

This step is optional but unlocks the trust anchor pathway — verifiers can chain trust UNECE → your operator DID → your registered entities, all the way back to the UN level.

Step 7 — (Optional) Configure GRID cross-tier link

If your community scheme mirrors or derives authority from an authoritative GRID register (e.g. your member registry mirrors a national chamber of commerce business registry), declare it via mirrorsAuthoritativeRegister pointing at the GRID entry's URI. The agent verifies the GRID entry exists.

This is the cleanest way to make the cross-tier relationship explicit when your scheme exists in both informal (IDR) and authoritative (GRID) form.

Step 8 — Issue your registration VC

Sign a Verifiable Credential whose credentialSubject matches the IdentifierSchemeEntry shape (per register-schema.json) including:

• Your scheme name, statement, identifier type (Organisation, Product, Facility, Asset, Location, Consignment, Member, or Person).
• The format declarations from Step 4.
• The resolver endpoint and (optionally) UNTP IDR version from Step 5.
• DIA issuance flags from Step 6.
• GRID cross-reference from Step 7.

Host the VC at a stable URI you control (e.g. https://yourdomain.org/.well-known/untp/idr/registration-vc.json). Notify UNECE of the URI.

Step 9 — First crawl

The registrar agent fetches your registration VC, verifies the signature, tests your resolver with the example identifier, runs the conformance checks, and (where issuesDia: true) samples a DIA credential. If everything passes, status moves to pilot and UNECE issues your registrar DIA.

You can ask UNECE for a faster-than-cyclical first observation; otherwise it runs at the next scheduled cycle (typically within 24 hours).

What gets verified

These are the conformance checks the agent runs on every cycle. Pass these and your status holds.

Check	What you need to do to pass
Registration VC signature valid	Keep your DID Document's verification methods current; re-sign and re-publish your VC after any key rotation.
Registry URL reachable	Use stable hosting; ensure the base URL serves content.
Identifier pattern compiles	Make sure your registeredIdPattern is a valid regex and registeredIdExample matches it.
Resolver template resolves	The template substituted with registeredIdExample must return a 2xx response.
UNTP IDR conformant (when claimed)	Resolver returns standard linksets per the IDR specification at the declared version.
DIA issuance verified (when claimed)	Resolution returns a DIA credential or a verifiable link to one; the DIA's signature verifies against your operator DID.
DIA extension consistency (when claimed)	The referenced EXT register entry must exist and be pilot or better; the issued DIA's type array must include the extension type.
GRID cross-reference resolves (when claimed)	The referenced GRID entry must exist.

A small failure (e.g. one broken URI template) yields partially-conformant. A fatal failure (signature, registry unreachable, claimed-but-absent DIA issuance) yields non-conformant. The agent records exactly which checks failed.

After registration: the lifecycle

After your initial registration:

• The agent crawls daily for active schemes and writes signed observations on every cycle.
• Drift in your resolver behaviour (changes to response shape, broken template, etc.) is detected automatically and surfaces as observation failures.
• Your status reflects the latest observation — no human review or re-submission is required.

Maintaining your registration

Updating your registration metadata

Re-issue your registration VC when scheme metadata changes (e.g. new resolver template, updated documentation URL, change to identifier format, addition of DIA-extension reference). Old VCs are superseded; the agent always uses the latest.

Upgrading UNTP IDR specification version

When you upgrade your resolver to a new IDR spec version, update untpIdrVersion and re-issue the registration VC. The agent re-tests conformance against the new version.

Rotating keys

If you need to rotate the signing key your DID controls:

1. Update your DID Document's verification methods.
2. Re-sign your registration VC with the new key.
3. Re-publish the VC at the same URI.
4. Notify UNECE — they will re-issue your registrar DIA after confirming the rotation.

The agent re-verifies the registration VC on every cycle. There is a brief window where an in-flight observation may fail signature validation; the next cycle will succeed.

Withdrawing

You may exit at any time. Tell UNECE; your entry is marked withdrawn. Historical observations are retained for audit. Your registry service should remain reachable for a reasonable transition period to avoid breaking historical credentials that contain identifiers from your scheme.

Disputes

If you disagree with an observation about your scheme:

1. Fetch the registrarAttestation linked from the observation. It points to a signed VC the agent issued, with all check details (test queries, resolver responses, DIA samples).
2. If you can demonstrate the check was incorrect (e.g. transient fetch failure, clock-skew issue, misinterpretation of the IDR specification), file a dispute with UNECE.
3. UNECE re-runs the relevant validation independently. If your dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the disagreement concerns interpretation of an IDR specification rule (rather than the data), the change goes through the formal change-control process described in the Governance document.

Common questions

Should I be in IDR or GRID? If your registry has statutory authority under national or treaty-based law (e.g. you are designated by legislation as the authoritative national register for some category of entity), you belong in GRID. If your registry has community/industry authority (e.g. you are an industry association or standards body), you belong in IDR. Many schemes are duals — an industry registry that mirrors an authoritative national register — and use both with the cross-tier link.

My scheme isn't UNTP IDR conformant yet. Can I still register? Yes. Set implementsUntpIdr: false in your registration VC. You'll be listed as a discovery directory entry. Implement IDR conformance later when you can; the agent will pick up the change on the next cycle after you update your registration VC.

My scheme doesn't issue DIAs. Can I still register? Yes. Set issuesDia: false. You're a pure-discovery operator. The trust-anchor pathway just doesn't apply to your scheme.

I operate multiple schemes. Do I need separate registrations? Each scheme is a separate IDR entry, but the operator DID can be shared (e.g. an operator running several identifier schemes can sign each scheme's registration VC with the same DID).

My scheme is jointly governed. Whose DID signs the registration VC? One organisation's DID is the registration signer. If governance is genuinely shared, consider standing up a joint-venture DID at a domain controlled by both parties.

Is there a fee? There is likely to be a minimal registration fee that is used to maintain register integrity on a non-for-profit basis. The actual fee structure will be determined before UNTP version 1.0 release.

Where to get help

• The UNTP Identity Resolver specification: https://untp.unece.org/docs/specification/IdentityResolver
• The Digital Identity Anchor specification: https://untp.unece.org/docs/specification/DigitalIdentityAnchor
• Sample IDR entries: see the register itself.
• Direct contact: raise an issue on the UNTP specification repository, or reach out via the UNTP mailing list or UNTP slack channel (join via the links on the home page).