Verifiable Credentials

info

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

Overview

The World-Wide-Web Consortium (W3C) has defined a data model for Verifiable Credentials (VCs). A VC is a portable digital version of everyday credentials like education certificates, permits, licenses, and registrations. VCs are digitally signed by the issuing party and are tamper-evident, privacy-preserving, revocable, and independently verifiable.

The UN has previously assessed this standard and has recommended its use for a variety of cross-border trade use cases in a recent white paper. VCs are inherently decentralised and so are an excellent fit for UNTP, which recommends that Product Passports, Conformity Credentials, Traceability Events, Facility Records, and Identity Anchors are all issued as W3C VCs.

A related W3C standard called Decentralized Identifiers (DIDs) provides a mechanism to manage the cryptographic keys used by verifiable credentials and to link multiple credentials into verifiable trust graphs. DIDs are not the same as the business, product, or location identifiers maintained by authoritative agencies, but can be linked to them.

Authenticity and auditability

UNTP credentials rely on digital signatures (and related cryptographic proofs) for authenticity and integrity: a verifier can confirm that a credential was issued by the controller of the issuer identifier and that the credential content has not been tampered with. That does not by itself prove that the verifier has seen every credential the issuer ever published, or that no issued credential has been omitted from discovery.

Digital signatures provide assurance of credential integrity and issuer authenticity. Some implementations may additionally use transparency mechanisms that provide verifiable inclusion proofs or append-only audit logs. These mechanisms enable relying parties to validate not only credential authenticity but also the completeness and history of published data. Such mechanisms are implementation-specific and are not required for UNTP conformance. Caching and mirroring of DID documents and status lists, content-addressable storage, and downstream preservation of a verification graph are the same class of optional pattern; see Durable Storage.

Business requirements for UNTP application of VCs

There are many different technical implementation options for verifiable credentials, which presents an interoperability risk — credentials issued by one party may not be understandable or verifiable by another. UNTP does not design new technical standards (that is the role of standards bodies such as W3C or IETF). Instead, UNTP enhances interoperability by recommending the narrowest practical set of technical options for each business requirement.

A key design principle for decentralised ecosystems is Postel's robustness principle: an implementation should be conservative in its sending (issuing) behaviour, and liberal in its receiving (verifying) behaviour. Sustainability evidence in a given value chain may arrive as many different versions of W3C VCs, or as ISO mDL credentials, Hyperledger Anoncreds, or even human-readable PDF documents. Being open in what is received and verified allows sustainability assessments to draw on a wide set of evidence. Conversely, choosing a narrow set of ubiquitous technology options when issuing UNTP credentials simplifies the task of verifiers and minimises costs for the entire ecosystem.

ID	Name	Requirement Statement	Solution Mapping
VC-01	Integrity	Support tamper detection, issuer identity verification, and credential revocation so verifiers can trust the integrity of UNTP credentials.	All VC options support this
VC-02	Compatibility	Recommend the narrowest practical set of technology options aligned with the most ubiquitous global choices to minimise the cost of interoperability.	Basic profile
VC-03	Human readable	Support both human-readable and machine-readable credentials so that actors with lower technical maturity are not blocked from participating.	Render method
VC-04	Discovery	Enable discovery and verification of credentials from product identifiers, so that verifiers need no prior relationship with issuers or subjects.	Identity Resolver
VC-05	Semantics	Use standard web vocabularies so data from independent credentials can be meaningfully aggregated.	Vocabularies
VC-06	Performance	Enable efficient traversal and verification of graphs containing hundreds of credentials.	Basic profile (JOSE or COSE proof), Verification during traversal
VC-07	Compliance	Meet any technology-based regulatory requirements in the countries where credentials are issued or verified.	Basic profile
VC-08	Openness	Avoid driving users towards closed ecosystems or proprietary ledgers.	DID methods
VC-09	Portability	Allow issuers to move DID documents between service providers so long-duration credentials remain verifiable.	DID methods (webvh method)
VC-10	Evolution	Evolve UNTP recommendations as VC tools and versions mature.	Roadmap

Verifiable Credential Profile

The UNTP Verifiable Credential Profile defines a narrow, interoperable subset of W3C VC technology choices. It comprises four parts: the VCDM profile (the core data model and proof mechanism), the render method (for human-readable presentation), the vocabularies (for semantic interoperability), and the DID methods (for issuer identification).

VCDM profile

The VC basic profile is designed to be as simple, lightweight, and interoperable as possible. A conformant implementation

• MUST implement the W3C VC Data Model v2.0 using the JSON-LD Compacted Document Form
• MUST implement W3C VC Bitstring Status List for credential status management including revocation
• MUST implement W3C-DID-CORE using DID methods defined in DID methods
• MUST implement the enveloping proof mechanism defined in W3C VC JOSE / COSE
  • Issuers MUST produce at least one of JOSE (Section 3.1.1, media type application/vc+jwt) or COSE (COSE Sign1, media type application/vc+cose). JOSE is the default for web and high-volume graph traversal. COSE (CBOR) is the alternate for constrained and IoT deployments that need a smaller binary envelope.
  • Verifiers MUST detect the proof format and MUST verify both JOSE and COSE. Detection is mechanical: a JOSE compact serialisation is three base64url segments separated by .; a COSE envelope is CBOR, typically a tagged COSE_Sign1 (CBOR tag 18) whose leading bytes are not ASCII.
• SHOULD verify each resolved credential using its associated signature, status, and verification material before incorporating that credential into derived conclusions or query results, when traversing a graph of linked credentials. See Verification during traversal.

Proposed for working-group decision

Allowing COSE as an alternate proof format is an architectural choice, not a documentation fix. Every conformant verifier would have to implement both stacks. This page states the proposed profile so the Technical Working Group can accept or reject it; it should not be merged without that vote. See #759.

Verification during traversal

Discovering a linked credential is separate from verifying it. An Identity Resolver returns a linkset so that clients can retrieve credentials; it does not check signatures, status, or issuer keys. Verification is the responsibility of the consuming implementation.

Implementations performing traversal of linked credentials SHOULD verify each resolved credential using its associated signature, status, and verification material before incorporating that credential into derived conclusions or query results. This recommended pattern does not change the UNTP credential data model.

Verification in this context means:

• Confirming the credential's signature (or enveloping proof) against the issuer's current verification material, typically retrieved from the issuer DID document.
• Checking credential status, including revocation, using the W3C VC Bitstring Status List as required by this profile.

Credentials that fail this check SHOULD NOT be treated as trusted input to graph queries, aggregated claims, or other derived conclusions. Graph-level business-rule validation — such as trust chains, accreditation scope, and completeness — is a further layer and is described in Transparency Graphs. Which of those rules apply is decided by the party applying them, or by a scheme or authority whose shapes they adopt. This profile does not prescribe a required combination of linked credentials for any particular use.

A status check reflects the Bitstring Status List as retrieved at that moment, and is not by itself a record that a relying party accepted a set of credentials on a particular occasion. Retaining material that allows an earlier check to be reconstructed is covered by the Durable Storage pattern.

The Identity Resolver specification restates this separation in Verification.

Status lists and DID documents are live resources. The Bitstring Status List credential MUST remain resolvable for as long as relying parties need to check revocation. DID documents for did:web and did:webvh resolve over DNS and HTTPS. did:webvh provides a verifiable history of keys while the DID remains resolvable; it does not replace durable copies of that history if the domain or host disappears.

This version of the profile does not specify a protocol for caching DID documents or status lists at Identity Resolvers, and it does not add a durability property on credentials.

Issuers of credentials intended to remain verifiable beyond the issuer's own expected lifetime SHOULD ensure that the verification material those credentials depend on — the DID document version(s) used to sign them, the Bitstring Status List credential(s) they reference, and the JSON-LD @context files used at issuance — remains retrievable for the credential's intended lifetime. How that is achieved is left to the implementer; the Durable Storage design pattern describes informative options and is not itself a conformance requirement.

Any copy, mirror, or archived replica of a UNTP credential MUST preserve the exact signed representation. For the enveloping JOSE proof required by this profile, that is the complete signed artefact: parsing a credential and re-serialising it produces different bytes and invalidates the proof.

Issuer private signing keys MUST NOT be published, mirrored, or included in any archived, cached, or preserved copy of verification material. Only public verification material is needed to verify a credential.

A dedicated preservation or timestamp profile may be added in a later version.

Render Method

Human-readable rendering of digital credentials is essential because UNTP must work for every actor in a global supply chain — from multinationals with mature digital systems to small producers with nothing more than a smartphone and a barcode reader. A structured JSON credential is perfectly verifiable by a machine, but it is meaningless to a buyer, an inspector, or a consumer who needs to see what the credential says.

The VC data model addresses this through the renderMethod property, which allows a credential issuer to embed or reference a template that a verifier can use to transform the credential into a human-readable document (typically HTML). The same signed credential can therefore be verified by a machine and displayed as a nicely formatted passport, certificate, or report to a person — without requiring a second, separate human-readable artifact that could drift out of sync with the verified data.

UNTP uses its RenderTemplate2024 type, retained from UNTP 0.7.0, until the W3C render method specification is stable and addresses the trade use cases described below.

Alignment with the W3C render method work

The W3C Verifiable Credential Rendering Methods specification is being developed on the Recommendation track. Its current status describes it as an experimental Working Draft that is undergoing regular revision and is not fit for production deployment. UNTP therefore does not normatively depend on that draft at this stage.

The W3C approach is valuable, and its secure rendering environment has a sound privacy goal: preventing a credential template from tracking a person by loading remote content or otherwise "phoning home". This protection is especially important for credentials about people, such as driver's licences.

Trade credentials have an additional requirement. A consumer who scans a product needs to be able to follow a link from its rendered passport to a conformity credential or other supporting credential and inspect that evidence. UNTP will continue to engage with the W3C work, participate in relevant working groups, and contribute these trade use cases so that a future W3C Recommendation can support privacy-preserving, user-initiated traversal. See Roadmap.

A conformant UNTP implementation:

• SHOULD include a renderMethod property as defined in the VC data model.
• SHOULD express each render method as a RenderTemplate2024.
• SHOULD reference a hosted HTML template using url, set mediaType to text/html, and include digestMultibase so that the fetched template can be checked against the credential.
• MAY embed the HTML template in template where remote retrieval is unsuitable.
• MAY use mediaQuery to identify the display conditions for which a template is intended.

The renderMethod value is an array. Each entry has a type array containing RenderTemplate2024 and either a url for a hosted template or a template containing an inline template.

digestMultibase is the SHA-256 multihash of the template file, multibase-encoded as base64url without padding (prefix u).

Publishing templates

Templates can outlive the systems that first publish them. The following guidance applies over the life of a credential.

• Inline templates add the full template to every credential. An HTML template is often as large as the credential data itself, is duplicated across every credential that uses it, and cannot be corrected after issuance.
• Linked templates with a digest keep credentials small and let many credentials share one template. A renderer compares the fetched template with the digest and refuses it if it has changed, so the template is tamper-evident. The template is also frozen: correcting it means publishing a new version at a new URL and reissuing the credentials that should use it. Issuers SHOULD publish each template version at its own URL, SHOULD NOT change the content at a URL once credentials reference it, and SHOULD keep it available for as long as those credentials are retained, alongside the other verification dependencies described in Verification during traversal.
• Linked templates without a digest can be updated after issuance, but anyone who controls the template host can then change how a signed credential appears. This is why a digest is recommended.
• Privacy: fetching a hosted template tells its host that a credential is being viewed. Issuers SHOULD NOT use per-credential template URLs.

Navigating to supporting evidence

Rendered UNTP credentials form part of a transparency graph. For example, a rendered product passport can link to a conformity credential, and that credential can link to the standard, scheme, or assessment evidence supporting its claims. These links need to remain actionable when the credential is viewed by a consumer, buyer, inspector, or other verifier.

• A renderer SHOULD present links contained in the rendered credential as user-activated controls.
• When a user activates a credential link, the scanner or renderer SHOULD resolve, verify, and render the linked credential so that the user can traverse the evidence graph.
• Allowing user-initiated traversal does not require unrestricted background network access. A renderer SHOULD prevent a template from making automatic requests that could disclose that a credential is being viewed, apart from retrieving the template itself, while still allowing the user to choose and follow a displayed link.
• A renderer MUST isolate the template from its host application and MUST NOT expose any credential other than the credential currently being rendered.

Vocabularies

A shared understanding of the meaning of claims made in verifiable credentials is essential to interoperability. The UNTP approach is to retain full JSON-LD linked-data compliance while also supporting developers who are unfamiliar with linked data and "just want the JSON schema". This is achieved by maintaining versioned @context files for semantic meaning and complete JSON schemas for each credential type for schema validation.

Key design points:

• Credential instances contain VCDM type references for each uniquely identified linked-data object. Each extension builds on parent types and is enumerated in the type array (e.g. ["Facility", "Farm"]).
• UNTP @context types are protected and MUST NOT be duplicated in extensions. Similarly, the UNTP @context does not duplicate protected terms from the VCDM @context.
• Unlike @context files, the JSON schema for each credential MUST be a complete schema that defines the entire credential including terms from VCDM and UNTP.

Conformant UNTP implementations:

• MUST use the JSON-LD syntax for the representation of data in all issued credentials.
• MUST reference the relevant versioned @context file from the UNTP vocabulary. The UNTP context file is an extension of the W3C VC Data Model 2.0 context.
• MAY extend credentials with additional properties and, if so, SHOULD include an additional @context file reference that defines the extended properties. The @vocab "catch-all" mechanism SHOULD NOT be used.
• SHOULD implement widely used industry vocabularies such as schema.org as a first choice for UNTP extensions requiring terms not in the UN vocabulary.
• MAY use any other published JSON-LD vocabulary for industry or country specific extensions.
• MUST maintain @context files at the same granularity and version as the corresponding credential type. This prevents verification failures when context files change after credentials are issued.
• SHOULD provide a complete and versioned JSON schema for each credential type, to facilitate simple and robust implementation by developers without detailed knowledge of JSON-LD.

DID Methods

UNTP supports the use of decentralised identifiers (DIDs) to uniquely and verifiably represent organisations, facilities, products, and other actors across global supply chains. These identifiers form the foundation for establishing Digital Identity Anchors (DIAs), resolving linksets via an Identity Resolver, and verifying credential issuers.

The W3C DID Core specification allows for a broad range of DID methods, many of which are registered in the W3C DID Extensions registry. Not all methods offer equivalent levels of verifiability, governance assurance, or operational fit for UNTP's trust model. Some methods rely solely on DNS and HTTPS infrastructure; others incorporate explicit proofs, registries, or governance contracts to strengthen control verification. The choice of DID method directly impacts the integrity of identity resolution and the downstream reliability of linked credentials. The UNTP working group expects that the proliferation of DID methods will consolidate over time to a much smaller number of methods, each designed to meet specific business needs.

Acknowledged DID methods

An acknowledged DID method is one that the UNTP working group has evaluated and determined to offer appropriate levels of verifiability, governance assurance, or operational fit for specific UNTP use cases. The list evolves through working group consensus as new methods mature.

Method	Status	When to use
did:web	✅ Recommended	Simple, widely interoperable organisational identifiers where trust in domain ownership is independently verified
did:webvh	✅ Recommended (Advanced)	Institutional and organisational identifiers requiring verifiable history, key rotation, and auditability

did:web

The did:web method enables identifiers to be derived from domain names and resolved via well-known HTTPS endpoints. It is widely supported and simple to implement, relying on existing DNS and TLS infrastructure to bind identifiers to hosting environments.

Within the UNTP framework, did:web offers a pragmatic entry point for identity publication and resolution. Its structure is compatible with the Digital Identity Anchor model and can be used to expose service endpoints, credential metadata, and other linkable assets.

However, did:web relies on implicit trust in domain ownership and HTTPS hosting. It does not by itself provide strong or auditable guarantees of control — particularly in shared hosting environments, federated platforms, or supply chains involving resellers and intermediaries. Its use is sensitive to domain expiration, certificate mismanagement, and untracked delegation. UNTP implementations SHOULD use did:web where simplicity and broad interoperability are prioritised, and where trust in domain ownership is independently verified.

A conformant UNTP implementation:

• MUST implement the did:web method as an Organisational Identifier
• SHOULD implement the did:web method using the web domain of the issuer to avoid portability challenges

Field	Description
Method Name	did:web
Identifier Syntax	did:web:<domain> or did:web:<domain>:<path>
Status	✅ Recommended — widely interoperable and suitable for institutional and organisational identifiers
Governance	W3C-registered DID method maintained by the Decentralized Identity Foundation (DIF) and the W3C community
Resolution	Well-known HTTPS endpoints (typically /.well-known/did.json or /did.json), resolved via DNS and TLS infrastructure
Use Case in UNTP	Organisational identifiers, Digital Identity Anchors, identity publication and resolution. Suitable where simplicity and broad interoperability are prioritised.
Advantages	Widely supported, simple to implement, relies on existing DNS and TLS infrastructure. Compatible with the Digital Identity Anchor model.
Known limitations	Relies on implicit trust in domain ownership. No strong or auditable guarantees of control, particularly in shared hosting or federated platforms. Sensitive to domain expiration, certificate mismanagement, and untracked delegation.
Implementation Notes	MUST be implemented as an Organisational Identifier. SHOULD use the issuer's own web domain to avoid portability challenges. Requires independent verification of domain ownership.

did:webvh

The did:webvh method extends did:web by introducing verifiable history — enabling tamper-evident tracking of identifier updates over time. It allows organisations to maintain a cryptographically linked log of key rotations, control changes, and migrations across domains, providing strong assurances of authenticity and continuity.

Within UNTP, did:webvh is recommended for institutional and organisational identifiers where auditability, long-term trust, and accountability are required — such as Digital Identity Anchors, credential issuers, and registry maintainers. It retains the accessibility of web-based publishing via HTTPS while adding a transparent, verifiable chain of control that aligns with UNTP's principles of traceability, integrity, and transparency.

A conformant UNTP implementation:

• MUST implement the did:webvh method where auditability of identity control is required, for example for accredited data publishers and credential issuers
• SHOULD maintain the did.jsonl file with version linking and proofs
• SHOULD plan for a change of domain using the method's alsoKnownAs and newDomain parameters

Field	Description
Method Name	did:webvh
Identifier Syntax	did:webvh:<domain> or did:webvh:<domain>:<path>. Resolved via HTTPS to a did.jsonl (JSON Lines) file containing a verifiable chain of DID document versions.
Status	✅ Recommended (Advanced) — suitable for institutional, organisational, and delegated identifiers requiring verifiable history, key rotation, and auditability
Governance	Maintained by the Decentralized Identity Foundation (DIF) as an extension of did:web. Defined in the DIF DID Web Verifiable History specification.
Resolution	HTTPS endpoints hosting a did.jsonl log file, typically at /.well-known/did.jsonl. Resolution verifies a chain of cryptographically linked versions (previousVersionHash + proof) to produce a tamper-evident DID Document history.
Use Case in UNTP	Digital Identity Anchors and institutional identifiers requiring auditability, traceability, and long-term trust. Supports continuity of identity even when domains change.
Advantages	Extends did:web with verifiable, append-only history of updates. Enables tamper-evident key rotation, continuity of trust, and portability between domains. Backward compatible with existing did:web resolvers when version history is ignored.
Known limitations	Still relies on HTTPS hosting and DNS domain ownership. A verifiable did.jsonl history cannot be resolved if the domain or host is gone; see Durable Storage — verification dependency closure. More complex to implement due to the requirement to maintain a valid did.jsonl chain. Historical transparency may expose metadata about operational changes — privacy implications should be assessed per use case.
Implementation Notes	MUST be implemented where auditability of identity control is required (e.g. accredited data publishers, credential issuers). SHOULD maintain the did.jsonl file with proper version linking and proofs. Implementers SHOULD plan for domain portability using the alsoKnownAs and newDomain parameters.

Operating a DID: identifier control and key custody

Requiring credentials to be issued under a DID does not require every issuer to understand or operate one. Smaller suppliers — and many facility operators — have no IT capability and no reason to learn what a DID is. Their software can make this invisible to them.

"Having a DID" is really two capabilities, and they can be delegated independently:

• Control of the identifier — whose domain the DID resolves under, and therefore who keeps the identifier when commercial arrangements change.
• Custody of the signing key — who holds the private key and performs the signing.

Separating them gives a ladder rather than a choice between running your own infrastructure and having none.

Arrangement	Identifier	Signing key	Suited to
Self-operated	Own domain (did:web or did:webvh)	Issuer	Organisations with the capability to manage keys; the expected end state
Domain-controlled, vendor-operated	Own domain (did:web or did:webvh)	Software provider	Most businesses — any organisation that already has a domain
Fully custodial	Provider's domain, usually one path per customer	Software provider	Smaller operators with no domain or IT capability
Non-issuing	None	None	Actors who are the subject of credentials issued by others, but issue none themselves

A conformant UNTP implementation:

• SHOULD issue credentials under a DID whose identifier the issuing organisation controls, on a domain it owns.
• MAY delegate custody of the signing key to its software provider. An issuer is not expected to understand or operate a DID in order to issue a conformant credential.
• MAY use a DID hosted entirely by its software provider where the issuer has no domain of its own.
• SHOULD populate issuingSoftware whenever the signing key is operated by a software provider rather than by the issuer, so that a verifier can see which software held the signing key — see Software identification.

The middle arrangement deserves emphasis: publishing a DID document at a well-known path on a domain the organisation already owns is a small step that software can perform on the issuer's behalf. The organisation keeps its identifier and its credential history when it changes software, without ever handling a key. It is the recommended arrangement for any issuer with a domain.

Custodial issuance is an accommodation for organisations that cannot yet operate an identifier of their own. It is not the assumed pattern, and implementations SHOULD support an issuer's move up the ladder: publishing the DID document to the issuer's own domain on request, and exporting or rotating keys to an issuer that takes over custody. did:webvh makes such a move auditable rather than a fresh start, because the key rotation and any change of domain are recorded in the verifiable history rather than appearing as an unrelated new identifier.

Continuity when the arrangement changes

An issuer whose identifier resolves under its own domain keeps that identifier when it changes software. Where the DID is hosted by a software provider, a change of provider means a change of DID. That does not break identity continuity, provided three things hold:

• Every credential carries the issuer's stable business identifier, through registeredId and idScheme on the issuer, not the DID alone. This is what allows a verifier to recognise successive DIDs as the same organisation.
• The binding between that business identifier and the DID is time-bound. A Digital Identity Anchor records which DID a registered entity controlled, and for what period, so a credential can be checked against the binding that was current when it was signed. Identity continuity across a change of DID therefore rests on the anchor rather than on the DID itself. How anchors are issued, superseded and retained is defined by the Digital Identity Anchor specification.
• The DID document remains resolvable for the useful life of the credentials signed with it. A provider hosting DIDs on its own domain SHOULD undertake to keep those documents resolvable, or to transfer them, when a customer leaves. Removing a departed customer's DID document makes every credential that customer ever issued unverifiable: the identity still resolves through the anchor, but the signature cannot be checked.

Where a provider ceases to operate regardless, the fallback is preservation of the verification material alongside the credential — see Durable Storage — verification dependency closure.

Delegated key custody has a governance consequence that no schema can address: a provider holding the key is technically able to issue credentials the issuer did not approve, and the issuer cannot cryptographically repudiate them. That is a matter for the agreement between the issuer and its software provider, and a reason for organisations with the capability to hold their own keys. The Digital Identity Anchor limits the exposure in either arrangement, because the binding between the business and its identifier is asserted by an independent authority rather than by the software provider.

Software identification: issuingSoftware

Every UNTP credential envelope MAY carry an issuingSoftware object identifying the specific software build that produced the credential. It sits on the credential itself, alongside issuer — not inside credentialSubject — because it describes how the document was produced rather than anything about the subject.

The property serves two readers. For a verifier, it records which software held the signing key, which is why the custody guidance above recommends populating it whenever a software provider operates the key. For the Software Implementer (SWI) register, it is the attribution mechanism: the registrar agent discovers credentials in the wild and uses this block to attribute each one to a registered vendor and software version, so the register can update itself from observed evidence.

When the block is present, id and vendor.id MUST be populated. They are the keys the registrar uses to attribute a credential. name, version and vendor.name SHOULD be populated: the register already holds the authoritative values, and these fields align a credential with that record for a human reader.

Property	Content
id	MUST. A stable URI identifying this specific software build — the register's softwareVersionId. MUST NOT be reused across builds.
vendor.id	MUST. The software vendor's DID. MUST match the vendor DID registered in the SWI register.
name	SHOULD. The name of the software product.
version	SHOULD. The human-readable version label of the build (for example a semantic version).
vendor.name	SHOULD. The name of the software vendor.

A conformant UNTP implementation:

• MUST include issuingSoftware on every credential it issues if that software is listed in the SWI register.
• MAY omit issuingSoftware otherwise. A credential without it is still a valid UNTP credential, and verifiers MUST NOT reject a credential solely because it is absent.

The SWI registrar agent attributes an observed credential to a register entry only where issuingSoftware.vendor.id resolves to a registered vendor and issuingSoftware.id resolves to a registered software version of that vendor. A credential that fails either check is not attributed and is not counted in conformance reporting, but MAY still be a valid UNTP credential.

The registrar agent correlates observed credentials with the SWI register schema as follows. The first two rows are the match keys; the remaining rows are informative alignment.

Credential field	Register field
issuingSoftware.vendor.id	entries[].vendor.id
issuingSoftware.id	entries[].products[].versions[].softwareVersionId
issuingSoftware.version	entries[].products[].versions[].versionLabel
issuingSoftware.name	entries[].products[].name
issuingSoftware.vendor.name	entries[].vendor.name

For the registration workflow — minting a softwareVersionId per build, a worked example of the block, and the optional binding-credential service that protects against forged issuingSoftware claims — see the SWI registration guide.

Wallets and Presentations

The verifiable credentials ecosystem is typically designed around a model where a human holder stores credentials in a personal digital wallet and presents them to verifiers on demand. This works well for personal credentials such as driver's licenses or educational certificates, where the holder is a person who can actively participate in a presentation exchange.

UNTP operates in a fundamentally different context. The subject of most UNTP credentials is an inanimate object — a box of goods, a shipment of steel, a battery module. The box of goods cannot create verifiable presentations on demand, and the credential binding is to the identity of the goods rather than to a holder. Any party with access to the product identifier (via a barcode, QR code, or RFID tag) discovers credentials about that product through an Identity Resolver. This is why UNTP's architecture centres on a resolver-based "pull" model rather than a wallet-based "push" model.

Verifiable Presentations

A conformant UNTP implementation:

• MUST issue and publish product passports, product conformity credentials, and traceability events as verifiable credentials and MUST include the identifier of the goods within the VC subject.
• MAY exchange these and any other credentials as verifiable presentations in wallet-to-wallet transfers or any other method.

Wallets

UNTP is wallet-agnostic. It neither mandates nor precludes the use of digital wallets for storing, managing, or exchanging verifiable credentials. Digital wallets are relevant in several legitimate implementation contexts — including organisational identity and accreditation presentation, regulatory compliance in wallet-mandated jurisdictions such as the EU Digital Identity (EUDI) Wallet, and business-to-business credential exchange as part of procurement or onboarding workflows. In these scenarios, wallets are one possible mechanism among several, complementing rather than replacing the resolver-based discovery model.

For detailed guidance on when and how to use digital wallets with UNTP, including design patterns and implementation considerations, see Digital Wallets.

Roadmap

Future versions of this specification will

• Provide richer guidance on DID methods via a decision tree that helps to select the right method for the right purpose
• Address the proliferation of DID methods and their consolidation to meet specific business needs
• Provide guidance for different use cases (e.g. legal entities vs products), including infrastructure durability as a dimension of that decision tree — domain expiry, organisation restructuring, hosting-provider changes, and similar DNS/HTTPS risks that affect credentials with multi-year or multi-decade validity
• Document, as a complementary pattern to did:webvh rather than a competing DID method, anchoring of DID document hashes or credential digests to a public blockchain so that proof of existence and integrity at a point in time does not depend on the original resolution infrastructure remaining available
• Explore registration of credential digests and appended-evidence hashes with an IETF SCITT transparency service, whose append-only log and countersigned receipts provide proof of existence and integrity for credentials and the evidence they reference, independent of the issuer's own infrastructure
• Provide guidance on selective redaction methods to better support confidentiality goals
• Provide timelines for transition between versions of technical specifications
• Address long-term verification of DID documents and status lists when original hosts are unavailable, without turning the Identity Resolver into an archive (see Durable Storage — verification dependency closure)
• Confirm after implementer feedback whether COSE remains an issuer alternate or is scoped to a later profile
• Participate in relevant W3C working groups and contribute UNTP trade use cases, including privacy-preserving user navigation from a product passport to conformity credentials and other supporting evidence
• Monitor the W3C Verifiable Credential Rendering Methods specification and align with the Recommendation when it is stable and supports UNTP's trade requirements
• Publish a transition path from RenderTemplate2024 to the W3C Recommendation, including vocabulary, schema, renderer, and credential-version implications