How to Register Your Software

This guide walks software vendors through the steps required to get a software product listed in the UNTP Software Implementers (SWI) 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 vendors, see the register itself.

Who should register

You are a candidate vendor if your organisation builds software that issues or verifies UNTP credentials on behalf of customers (producers, manufacturers, brands, traders, conformity assessment bodies, registry operators, regulators). Typical SWI registrants include:

• ERP, supply chain, and product lifecycle management platforms
• Specialist sustainability and traceability platforms
• Digital Product Passport (DPP) issuance services
• Verifiable Credential infrastructure providers
• Open-source toolkits and reference implementations

What you'll get when you're done

• An entry in the SWI Register at https://registers.uncefact.org/untp/swi/{your-vendor-slug}.
• A UNECE-issued Digital Identity Anchor (DIA) credential about your vendor DID, hosted on your register entry.
• Continuous, automated conformity observation by the UNTP registrar agent — your register status reflects observed reality (the actual conformance of credentials your software issues in production).
• Discoverability for community activations selecting platforms to standardise on.

Quick summary

The full process boils down to three things:

1. Publish a vendor DID at a domain you control (typically did:web:yourdomain.com).
2. Embed the issuingSoftware block in every credential your software issues, referencing your vendor DID and a stable softwareVersionId URI per build.
3. Issue a registration Verifiable Credential describing your products and software versions, and notify UNECE.

The registrar agent does the rest: discovers credentials in the wild via the Identity Resolver, reads each credential's issuingSoftware block to identify the build that issued it, validates against UNTP core and registered extensions, and writes signed observations against your software versions.

Optionally — and strongly recommended for vendors operating at scale — you can stand up a binding-credential service that counter-signs credential-to-software bindings. See Step 6 below.

Prerequisites

Before you start, you'll need:

Item	Notes
A web domain you control	Required for did:web and for hosting your registration VC.
Software that issues UNTP credentials	At least one of DPP, DCC, DTE, DFR, DIA.
Per-build versioning discipline	You'll mint a stable URI per build (the softwareVersionId) that becomes the unit of observation.
Familiarity with the UNTP specification	Especially the credential types your software issues and the issuingSoftware block.
A representative who can liaise with UNECE	For initial onboarding and any future disputes.

You do not need:

• A separate certification step before the agent observes you.
• Pre-production test credentials submitted for review (the agent observes your live production credentials).
• Specific software architecture — the model is method-agnostic about how you build your platform.

Step-by-step

Step 1 — Get in touch with UNECE

Tell UNECE you intend to register a software product. UNECE will create a proposed register entry as a placeholder while you set up your DID and update your software. 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 vendor entry; both will be replaced once you publish your real DID and registration VC.

Step 2 — Publish your vendor DID

Stand up did:web:yourdomain.com (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 vendor identity.

Step 3 — Mint a softwareVersionId per build

For every released build of your software, mint a stable URI on a domain you control that uniquely identifies the build. The recommended pattern is:

https://yourdomain.com/.well-known/untp/software/{product-slug}/{version}

For example: https://vendor.example/.well-known/untp/software/your-platform/2026.04.1

The URI is the unit at which conformance is observed. Don't reuse a softwareVersionId across builds; release a new build, mint a new URI.

Step 4 — Embed the issuingSoftware block in every credential

Update your software so that every UNTP credential it issues includes an issuingSoftware block at the top level of the credential payload. Minimum content:

{
  "issuingSoftware": {
    "vendor": {
      "id": "did:web:yourdomain.com",
      "name": "Your Vendor Name"
    },
    "id": "https://yourdomain.com/.well-known/untp/software/yourproduct/2026.04.1",
    "name": "Your Product Name",
    "version": "2026.04.1"
  }
}

The vendor.id is your vendor DID. The id is the softwareVersionId from Step 3. The agent uses both to correlate observed credentials with your register entry.

Step 5 — Issue your registration VC

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

• Your vendor name, statement, registration country, operating countries.
• Your declared UNTP scope (which credential types your software issues).
• Your products, each with one or more software versions.
• Industry focus where applicable.

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

Step 6 — (Optional) Stand up a binding-credential service

This step is optional but provides the strongest conformance signal in the register and protects against forged issuingSoftware claims by malicious deployers.

A binding credential is a vendor-signed counter-claim that confirms a particular UNTP credential was actually issued by a particular software version. The recommended architecture is:

• Per-customer-deployment delegate DID model. You issue a delegated DID to each customer deployment. The delegate signs binding credentials on behalf of your vendor root DID, but your vendor root key never leaves your premises.
• A discovery URI template declared in your registration VC's bindingCredentialDiscovery.uriTemplate, taking {credentialId} as a variable and resolving to the binding credential.
• A delegate discovery endpoint publishing the list of currently-authorised delegate DIDs.

When the agent observes a credential issued by your software, it fetches the binding credential, verifies the delegate DID is authorised, and confirms the (credentialId, softwareVersionId) pair. Vendors that offer binding earn a stronger binding signal in the observation.

Step 7 — First observations

The registrar agent crawls the Identity Resolver, fetches discovered credentials, reads each issuingSoftware block, and matches it to a vendor and software version in the register. New software versions are auto-created on first sighting.

For each observed credential, the agent runs five checks (signature, schema, vocabulary, binding, issuer authority) and records a signed observation. As observations accumulate, your software-version status reflects rolling pass/fail rates.

You can ask UNECE to seed the agent with your test product/facility identifiers if your software has not yet issued credentials in the wild; otherwise observations begin once your software has issued credentials that the agent can discover.

What gets verified

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

Check	What you need to do to pass
Signature	Issuers using your software must sign credentials with valid keys; their DID Documents must be reachable.
Schema	Credentials must validate against UNTP core schema for their declared credentialType, plus the schema of every extension type in their type array.
Vocabulary	All vocabulary terms (CVC topics, extension vocabulary terms) must resolve to known concepts.
Binding (optional)	If you've stood up a binding service, the agent fetches your binding credential and verifies the (credentialId, softwareVersionId) pair against an authorised delegate DID.
Issuer authority	The credential's issuer DID must be reachable and self-consistent.

A vendor's status is then derived from rolling observations within the assessment window (default 30 days):

• conformant — all dimensions pass for ≥99% of observed credentials.
• partially-conformant — schema and signature pass, but binding or vocabulary failures exceed threshold.
• non-conformant — schema or signature failures exceed threshold.
• insufficient-data — fewer than the minimum credentials observed in the window.

The agent always records exactly which checks failed for each sample credential, so you can fix exactly what's broken.

After registration: the lifecycle

After your initial registration:

• The agent observes credentials your software issues on every cycle.
• Each new build of your software (a new softwareVersionId) is auto-created in the register on first sighting — you don't need to pre-register every version.
• Your status reflects the latest assessment window — no human review or re-submission is required.

Maintaining your registration

Releasing a new software version

Just ship the build. The agent picks up the new softwareVersionId automatically when credentials carrying it appear in the wild. Optionally, you can publish a SCITT-anchored SBOM at the new version's URI for additional supply-chain integrity assurance.

You may also re-issue your registration VC if your declared product or scope metadata changes (e.g. you add a new product, expand operating countries, change your DIA-extension reference).

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.

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.

For binding credentials with delegated DIDs, follow the same pattern: rotate the delegate's verification methods, update your delegateDiscovery endpoint to reflect the new authorised delegates.

Withdrawing

You may exit at any time. Tell UNECE; your entry is marked withdrawn. Historical observations are retained for audit. Credentials your software issued during the active period remain referenceable; their issuingSoftware blocks still resolve to your archived register entry.

Disputes

If you disagree with an observation about your software:

1. Fetch the registrarAttestation linked from the observation. It points to a signed VC the agent issued, with all check details and references to the sample credentials it observed.
2. If you can demonstrate the check was incorrect (e.g. the sample credential the agent observed was actually invalid for reasons attributable to the deployer rather than your software), file a dispute with UNECE.
3. UNECE re-runs the 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 a conformance rule (rather than the data), the change goes through the formal change-control process described in the Governance document.

Common questions

Do I need to register every version of my software? No. The agent auto-creates software-version entries on first sighting of a softwareVersionId in the wild. Your registration VC describes your products, but individual versions appear automatically.

My customers issue the credentials, not me. Why does my software get observed? The issuingSoftware block your software embeds in every credential is the bridge between the issuer (your customer) and the vendor identity (you). The agent uses that block to attribute observed credentials back to your software.

What if a customer modifies my software and issues bad credentials? That's the case the optional binding-credential service protects against. Without binding, the agent records the failure against your software version (since the credential carries your issuingSoftware block). With binding, the agent can detect that the customer's bad credentials don't have a matching binding signature and the failure is recorded as a bindingFail rather than a schema/signature failure.

Can I be observed if I haven't issued any production credentials yet? You can be in proposed or planned status with just your DID and registration VC. To advance to observed or conformant, your software needs to be in production issuing credentials that the agent can discover via the IDR.

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 specification: https://untp.unece.org/docs/specification/
• Sample software vendor 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).