Identity Resolver

info

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

Artifacts

Linkset Schema

The UNTP linkset schema defines the structure of linkset responses returned by identity resolvers. It is aligned with and extends the GS1 resolver linkset schema which implements RFC 9264. A UNTP linkset that omits the UNTP extension properties (rel, method, encryptionMethod, accessRole) will also validate against the GS1 schema, with one exception: the GS1 schema only accepts link relation URIs made of letters, digits, . and /, so it rejects the hyphenated UN/CEFACT link relation URIs. The UNTP schema accepts any absolute http(s) URI, as RFC 8288 allows.

Artifact	Link	See also
Linkset JSON Schema	LinksetSchema.json	GS1 linkset-schema
IDR API Specification (OpenAPI)	idr-api.json
IDR API Documentation	idr-api.html

Link Relations

RFC 8288 allows two forms of link relation type. A type registered in the IANA Link Relations registry is written as a bare token. Any other type is an extension relation type and MUST be written as a URI that dereferences to its definition.

Only dpp is registered with IANA, with this specification as its reference. The other UNTP credential types are defined in the UN/CEFACT link-type code list, and linksets, DID service types and linkType query values MUST use the full URI for them. Elsewhere on this site the short names (dcc, dte and so on) are used in prose for readability; they always mean the URI in this table.

Short name	Value in a linkset	Links from a context URI that identifies...	See also
dpp	dpp (IANA registered)	a product, to its digital product passport	GS1 dpp
dcc	https://test.uncefact.org/vocabulary/link-type/dcc	a product, manufacturer or facility, to an applicable digital conformity credential
dfr	https://test.uncefact.org/vocabulary/link-type/dfr	a facility, to its digital facility record (see Facility resolution)
dte	https://test.uncefact.org/vocabulary/link-type/dte	a product or batch, to a digital traceability event about it
dia	https://test.uncefact.org/vocabulary/link-type/dia	a business, to its digital identity anchor
dcr	https://test.uncefact.org/vocabulary/link-type/dcr	an organisation, to its digital corporate record

A link to another resolver, such as a secondary resolver, uses the IANA-registered linkset relation from RFC 9264, whose target is itself a set of links.

UNTP 0.7 used compact untp: aliases in the IDR API and bare, unregistered names in some linksets. For compatibility with deployed 0.7 implementations, resolvers SHOULD accept untp:dpp, untp:dcc, untp:dfr, untp:dte, untp:dia and untp:idr in registration and linkType query values. Clients SHOULD also recognise those values and the bare names dcc, dfr, dte, dia and idr in responses from a 0.7 resolver. They map to the canonical values above: untp:dpp maps to dpp; untp:idr and idr identify a secondary-resolver link whose canonical relation is linkset; and the dcc, dfr, dte and dia aliases map to their UN/CEFACT URIs. When used as a legacy query value, untp:idr selects a secondary-resolver link; it does not have the control meaning of linkType=linkset, which requests the full linkset. Resolvers conforming to this version MUST emit the canonical values in linksets. Clients and publishers SHOULD NOT use the aliases for new requests or records, but a client MAY use or retry a legacy alias when communicating with a 0.7 resolver.

Registration of dcc and dfr with IANA has been proposed. If either is registered, the bare token becomes the preferred form, and clients SHOULD treat the token and the URI as the same link type.

Overview

Supply chains rely on many types of identifiers for businesses, locations, and products of which each are governed by distinct schemas. These identifiers are essential for maintaining integrity and trust by enabling systems to trace, verify, and link data about physical or digital entities.

UNTP does not attempt to replace these existing identifier systems. Instead, it builds upon them by allowing high-integrity registries and sector-specific schemas to be reused while also supporting self-issued identifiers under the control of the entity itself.

To accommodate this variety, UNTP implementations work with two broad classes of identifiers

• Registry-managed identifiers are issued or recognized by an authoritative register (e.g., national business registry, product catalogue, or sector-specific scheme). The register defines the rules for identifier issuance and for authorizing identifier usage and management. Implementations can therefore rely on the register as the authoritative source for discovery and verification.

• Self-assigned identifiers created and controlled by the entity itself. In UNTP this is achieved with Decentralized Identifiers (DIDs), where the controller publishes the resolver information directly via DID Documents. The DID method specifies how identifiers are created, updated, and revoked. The DID Document exposes service endpoints that behave like link-sets and contains cryptographic material that supports proof of control.

Characteristic	Registry-managed	Self-assigned identifiers
Issuance	Assigned by an authority or registry	Created and controlled by the entity
Governance	Central registry or scheme operator	Decentralized, method-specific rules
Discovery	Resolver templates from the registry	DID resolution via DID methods
Resolution	Scanner/system maps ID to resolver URL using scheme rules (registry templates, ISO/IEC 18975)	DID string is resolved per DID method, returns DID Document
Verification	Trust anchored in the registry (issuance + authorization rules)	Trust anchored in cryptographic keys inside the DID Document
Use cases	Leverages existing schemes, interoperability	Autonomy, no reliance on central registry

The Identity Resolver (IDR) defines how both classes can participate in a consistent discovery and verification workflow.

Scheme neutrality

UNTP does not require GS1 identifiers. The Leverage existing schemes design requirement is explicit on this. The Identity Resolver is deliberately scheme-agnostic: any scheme that can present identifiers as globally unique, discoverable, resolvable URIs can participate.

That posture aligns with the multi-scheme approach in EN 18219 (Digital product passport — Unique identifiers), which recognises several families of product (and related) identifiers — including ISO/IEC 15459 / ISO/IEC 18975 web-enabled identifiers using GS1 Application Identifiers or ASC MH10.8.2 Data Identifiers, Identification Links (EN IEC 61406), decentralised identifiers (DIDs), and Digital Object Identifiers (DOI). UNTP does not mandate any one of those families; it defines a common resolve-to-linkset pattern that each scheme can map onto.

Illustrative identifier URIs (different schemes, same IDR workflow):

Family (EN 18219-aligned)	Example identifier URI
GS1 Digital Link (structured path)	https://id.example.com/01/09506000134352/21/SERIAL123
ISO/IEC 15459 + ASC MH10 Data Identifier (structured path)	https://resolver.example.com/25S/IAC42PROD987654
Identification Link (EN IEC 61406)	https://il.example.com/p/ABC-12345-XYZ
Opaque registry-managed product ID	https://products.sample-register.example/ABC123456
Decentralised Identifier (DID)	did:web:manufacturer.example:products:serial-98765

GS1 examples appear frequently in this page because Digital Link is a common structured-path encoding — not because GS1 is mandatory for UNTP.

Path segments and “qualifiers”

Some schemes (notably GS1 Application Identifiers) split identity across a primary key and additional path segments (for example GTIN + serial). In the OpenAPI and in ISO/IEC 18975 those extra segments are often called qualifiers. In UNTP:

• Qualifiers are scheme-defined and optional. They are not a UNTP-required construct.
• For many schemes the full identity is a single opaque path value; there are no separate qualifier segments — the “qualifier path” is empty and the identifier is the ID.
• Where a scheme does use multi-segment paths, those segments are simply part of that scheme’s identifier syntax, not a general UNTP data model.

Resolvers MUST accept scheme configurations that use only primary identifier types with an empty qualifier path.

Conceptual Model

Regardless of identifier class, the UNTP applies a shared workflow:

"Given an ID of a thing, I can find verifiable data about that thing."

This workflow is described in terms of Discover-Resolve-Verify (D-R-V)

• Registry-managed identifiers delegate resolution rules to the registry, which may be governed or audited by a third party.
• Self-issued identifiers (DIDs) embed resolution logic within the DID method and DID Document, giving the controller direct control but also the responsibility to ensure availability.

Implementors should select the approach that best fits their governance model, subject to existing identification schemas and identity resolver capabilities for their sector or geography.

To fulfill the D–R–V workflow, all identifiers in UNTP MUST support four essential features. Where an existing scheme lacks one or more, UNTP provides a framework to uplift it:

• Unique - no risk of collision across schemas. See Identifier Representation for identifier representation conventions.
• Discoverable — retrievable as structured data in documents, or machine-readable (barcode, QR, RFID). See the implementation guidance for Registry-Managed and Self-Issued identifiers.
• Resolvable — dereferencing an identifier to obtain structured data. See Resolution and Linksets for the shared resolution model.
• Verifiable — claims made by the identifier's controller can be distinguished from third-party statements. See Verification for verification processes.

Design Requirements

This section defines the formal requirement statements for Identity Resolver implementations.

• Scheme means an identifier scheme such as a national business identifier scheme.
• Carrier means a machine readable device such as a barcode, QR code, RAIN or NFC tag that encodes an identifier issued under a scheme.
• Link means a URL that points to a page or document or credential that contains further information related to the identifier.
• Target means the document or credential that the link references.
• link-set means a collection of links with meta-data that describe each link.
• Resolver means an implementation of this specification that returns a link-set about a given identifier.

ID	Short name	Requirement	Solution Mapping
01	Global uniqueness	All identifiers, whether for products, assets, facilities, or businesses used in UNTP credentials MUST be globally unique so that they can be unambiguously referenced and resolved.	Identifier Representation
02	One carrier, many links	One data carrier (or one resolvable identifier URI) for a physical product, asset, or facility MUST be able to reference any amount of linked data or documents so that user or system confusion from multiple carriers can be avoided	Linkset Format
03	Leverage existing schemes	Existing identifier schemes MUST be usable for UNTP IDR functions so that existing investments can be leveraged and UNTP rollout can be accelerated because there is no need to re-tool existing identifier infrastructure.	This specification supports any identifier scheme.
04	Leverage existing carriers	Existing data carriers, whether 1D barcodes on products or RFID tags on livestock are entrenched and unlikely to change quickly. Therefore identity resolvers MUST be able to work with existing carriers so that digitalisation can proceed at pace without the need to re-tool existing physical scanning infrastructure.	Data Carriers
05	Seamless transition to 2D	As industry transitions from 1D barcodes to 2D/QR codes, the UNTP identity resolver process MUST work equally well with either so that implementers can transition at their own pace	Mapping Carriers to URIs - either create a resolver query from a 1D barcode / 2D matrix or embed the query into a QR.
06	Understanding link-sets	When a link-set is returned by a resolver, each link MUST include sufficient meta-data so that user systems can understand the purpose and usage of each link as well as the relationship between links	Linkset Format
07	Filtering link-sets	Resolvers MUST allow users to request specific links, all links, or (if unspecified) then receive a default link - so that user experience can be optimised.	IDR Query URL and Requesting the full linkset
08	Responsive links	Resolvers SHOULD leverage available user information such as language preferences to choose the most appropriate redirect target - so that user experience is optimised. The full linkset remains complete.	Defaults and Automatically returning the right language
09	Logical grouping of links	Link-set meta-data SHOULD provide an ability to group related link targets such as a product passport and related traceability events - so that user experience can be optimised.
10	Versioning of link targets	When multiple version of link targets exist (eg multiple version of a product passport) then resolvers MUST include version information in link metadata and MUST ensure that any defaults reference the latest version - so that users receive current information and can audit historical data	Versioned targets
11	Resolver redirection	Resolvers SHOULD, where available, include links that reference secondary resolvers so that product/facility owners can maintain additional document and credential links in their own resolvers. A typical example is the case where a global scheme maintains identifiers only at product class level but the manufacturer manages identifiers and related data at serialised item level. In such cases the primary resolver would say "here's what I know about the product and here's a link to another resolver that can tell you about the serialised item"	Secondary resolvers
12	Self-issued product identifiers	This specification MUST support self-issued identifiers so long as they are equally discoverable, resolvable, and verifiable - so that each value chain actor is free to make their own choice between third party product registers and self-managed product registers without any lock-in.	DID Documents as Resolvers and DID Discovery
13	Existing standards	This specification SHOULD use existing standards such as ISO/IEC 18975 and IETF RFC 9264 so that implementers can maximise re-use of existing infrastructure and maintain interoperability.	ISO/IEC 18975 is the basis for mapping an ID to a query. IETF RFC 9264 is the bases for the structure of the linkset response.
14	Domain sovereignty awareness	Implementers MUST recognize that domain owners have complete authority over their URI space (IETF BCP 190). Clients MUST validate actual content after dereferencing and MUST NOT assume URL patterns guarantee specific services or content types. Resolver operators SHOULD declare services via /.well-known/resolver per ISO/IEC 18975.	Domain Sovereignty
15	Public resolution	Resolvers MUST answer linkset queries without requiring authentication - so that any data requestor, who is typically unknown to the data holder in advance, can discover and resolve identifiers from anywhere in the value chain. Confidentiality is enforced on link targets, not on the resolver itself.	Public Access

Identifier Representation

Linked data architectures, of which UNTP is an example, depend on unique and consistent identifiers of entities such as products and facilities so that they can be matched across different credentials. For this reason URIs are heavily used as identifiers of entities throughout UNTP credential types. But without consistency in the way globally unique identifiers are constructed, there is a high risk that valuable links are not made. For example, consider the same product identified in two credentials:

• A digital product passport issued by a manufacturer with a sustainability claim about product http://product.sample-register.example/123456789
• A digital conformity credential with a third party sustainability assessment about product urn:example:sample-register:product:123456789

Although these are the same product, the construction of the ID is different and so a validation that attempts to confirm that a product passport claim is genuinely supported by third party assessment may fail.

There are thousands of identifier schemes in active use around the world and only a few have well defined conventions for consistent representation of their identifiers as globally unique URIs. To address these challenges, in this section, we define conventions for the consistent representation of identifiers that can be leveraged by any existing or new identifier scheme, whether the identifiers are managed by an issuing authority or self-managed.

These conventions support the D-R-V workflow by ensuring identifiers can be consistently discovered, resolved, and verified across different schemes.

Uniform Resource Name (URN)

URNs are a type of URI that are designed to be used as globally unique and persistent identifiers that remain available long after a specific resource that they identify ceases to exist or becomes unavailable. URNs MAY be used for any identifier and SHOULD be used as persistent identifiers for long lived entities such as organisations, facilities and long-lived products.

In patterns below:

• {identifier-scheme} is any string of characters permitted in URN Namespace Specific Scheme (alphanumeric characters, hyphen, period, underscore, colon).
• {identifier-value} is the string of characters after the last colon (limited to alphanumeric characters, hyphen, period, underscore).

For existing IANA registered URN namespaces

Use your IANA registered URN namespace.

• pattern: urn:{ns}:{identifier-scheme}:{identifier-value}

For all other schemes

Either register your own scheme with IANA or use the UN global trust register gtr URN namespace (IANA registration pending).

• pattern: urn:gtr:{identifier-scheme}:{identifier-value} where gtr represents the UN global trust register namespace.
• examples:
  • urn:gtr:register.business.gov.xx:90664869327 - representing any typical national business registration number
  • urn:gtr:nlis.com.au:QDBH0132XBS01234 - representing an Australian livestock identifier

The gtr namespace represents identifier schemes that are listed in the UN global trust register (GTR). When the gtr namespace is used, the {identifier-scheme} MUST be a DNS domain name comprising URN allowed or percent-encoded characters (i.e. no / unless encoded as %2F).

Uniform Resource Locator (URL)

URLs are a type of URI that represent addressable web locations. URLs as identifiers have the advantage that they are immediately resolvable but the disadvantage that they may become dead/broken links whenever a document is moved or a web site is restructured or a domain name changes.

IDR URLs as identifiers

When URLs are used as identifiers in UNTP credentials they SHOULD be Identity Resolver URLs that conform to the ISO/IEC 18975 structured path syntax without parameters.

• pattern: https://{identifier-scheme}/{identifier-value} where {identifier-scheme} is a DNS domain name (without / characters unless %2F encoded) and {identifier-value} is a valid ISO/IEC 18975 path (which can include / characters to separate class, sub-class, and instance id as defined in ISO-18975)
• examples:
  • https://products.sample-company.example/1234567
  • https://facilities-register.example/ABC123456
  • https://id.gs1.org/01/07332402265910
  • https://id.gs1.org/01/07332402265910/21/1234

When a given identifier scheme uses both URN and URL mechanisms to represent identifiers as URIs then the {identifier-scheme} part SHOULD be the same for both. If the identifier scheme is registered in the UN global trust register then the {identifier-scheme} MUST match the corresponding scheme ID in the trust register.

Universally Unique Identifier (UUID)

As an alternative to being issued by an issuing agency, identifiers can be algorithm-generated. The best-known example of this is the Universally-Unique Identifier (UUID). This relies on it being extremely unlikely, but not impossible, that the same identifier will be generated twice. For many practical applications, that can be "good enough" although there are some instances where duplicates have arisen (known as "collisions").

UUIDs as the complete identifier

When using a UUID as the identifier for an entity, the syntax would be

• pattern: uuid:{UUID}
• example: uuid:709f3df6-4cdf-4bda-94d9-ce0ec9428616

Such identifiers have no scheme information which could be used for resolvability and verifiability. Therefore usage SHOULD be limited to cases where there is no need for discovery of further data.

UUIDs as the scheme specific identifier value

UUIDs can be useful as scheme specific identifiers, particularly when there is value in the identifier being un-guessable. For example as a means to limit visibility of item specific data to the genuine holder of the goods - as described in the UNTP Decentralised Access Control specification.

• pattern: {uri-scheme}:{identifier-scheme}[:or/]{UUID}
• examples:
  • urn:gtr:products.sample-register.example:709f3df6-4cdf-4bda-94d9-ce0ec9428616
  • https://products.sample-register.example/709f3df6-4cdf-4bda-94d9-ce0ec9428616

Decentralised Identifiers (DID)

Decentralised Identifiers (DIDs) are a type of URI that are resolvable and verifiable by design. They are self-issued by any party and do not depend on any central register or issuing authority. The general structure of a DID is defined by the W3C Decentralised Identifiers recommendation.

DIDs are particularly suited for self-issued identifiers and provide a different approach to global uniqueness compared to URNs and URLs. They achieve uniqueness through cryptographic methods and decentralized resolution rather than centralized registry management.

Important: DIDs do not require any specific path structure or hierarchical organization. While examples in this specification may show organizational path components (such as :products: or :facilities:), these are purely illustrative. Organizations are free to structure their DIDs in any way that ensures global uniqueness and complies with their chosen DID method specification. Simple flat structures (e.g., did:web:example.com:ABCD1234) are equally valid as hierarchical structures (e.g., did:web:example.com:products:123456789).

For DID-specific resolution processes and implementation examples, see Implementation Guidance: Self-Issued Identifiers (DIDs).

GLUE identifiers

Some business identifiers need to appear in UNTP payloads even though they cannot be a DID and may never resolve to a discovery document. Typical cases are a company number issued decades ago by an authority that is no longer in business, a register whose original domain is gone, or a small issuing authority that does not participate in GRID. The Party id (and therefore issuerAlsoKnownAs, partyAlsoKnownAs, and facilityAlsoKnownAs) already accepts any URI string, so these identifiers can be recorded without a schema change.

The IETF GLUE Identifiers draft (draft-ietf-spice-glue-id) is an informative option for that URI: glue:{authority-identifier}:{external-identifier} wraps a legacy identifier under the issuing authority's GLUE registry code. GLUE identifiers are not resolvable like DIDs, are not a UNTP identifier class, and are not required for conformance. Prefer a DID or an Identity Resolver URL when a live, authoritative register exists.

Non-normative example — a historic national business number populating issuerAlsoKnownAs on a Digital Facility Record:

"issuerAlsoKnownAs": [
  {
    "type": ["Party"],
    "id": "glue:example-abr:50123456789",
    "name": "Sample Copper Refinery Co. Ltd",
    "registeredId": "50123456789",
    "idScheme": {
      "id": "https://abr.example.gov",
      "name": "Example National Business Register"
    }
  }
]

glue:example-abr:50123456789 is a protocol-neutral URI for the register's own number 50123456789. The idScheme still names the register for humans and for matching; the GLUE URI is the globally unique identifier of that pair. Authority identifiers in production would be those registered by the GLUE specification, not the example-abr placeholder used here.

See also Related Standards — IETF GLUEID.

Resolution and Linksets

Once an identifier has been normalized to a URI, the next step is resolution: dereferencing the URI to obtain structured data describing the identified entity and related resources. This section covers the shared resolution model that applies to both registry-managed and self-issued identifiers.

Public Access

A resolver conformant with this specification MUST answer linkset queries without requiring authentication. No API key, OAuth token, or other access mechanism may be a precondition for fetching a linkset. This is a structural consequence of the UNTP architecture: the party resolving an identifier — a downstream manufacturer, a regulator, a consumer scanning a QR code — is typically unknown to the data holder in advance, so discovery cannot depend on any credential or key issued beforehand.

Public resolution does not mean public data. Confidentiality is enforced one layer down, on the link targets rather than on the resolver:

• Sensitive targets are published as encrypted content, with keys released via shared secrets or decentralised authentication, or are protected by access control at the storage location.
• Publishers may issue a different signed variant of a credential for each audience. A variant limits the claims in that credential but does not restrict who can retrieve it.
• Every link remains visible in the full linkset. Its accessRole metadata tells clients which audience the target is intended for; it is not a query parameter and protects nothing by itself (see Secure Targets).

A scheme operator MAY offer authenticated services alongside its resolver — for example, a richer commercial data API behind an API key — but the resolver endpoint declared for UNTP purposes (for example, in an identifier scheme register entry) must remain publicly reachable. Standard operational protections such as rate limiting are acceptable provided ordinary anonymous resolution remains available.

Authenticated linkset retrieval — where a resolver returns an extended linkset to a requestor who proves a role or identity — is under exploration for a future version of this specification. See Roadmap.

IDR Query URL

IDR queries are URLs that take the general form:

https://{domain}/{path}?{query} where

• domain is the web domain of the resolver service, usually operated by the identifier scheme register (e.g., resolver.sample-register.example)
• path carries the specific ID of the product or facility being queried. The path syntax is defined by the identifier scheme (ISO/IEC 18975 structured path or query-string forms, Identification Link URLs, etc.). Some schemes append scheme-specific segments (for example GS1 serial/batch Application Identifiers); others use a single opaque identifier with no extra segments.
• query can carry a linkType parameter selecting the kind of link wanted (e.g., linkType=dpp). A linkType value names a link relation type exactly as it appears in the linkset: a registered token such as dpp, or the percent-encoded URI of an extension type (see Link Relations). Language is negotiated with the HTTP Accept-Language header, not a query parameter. Other parameters, such as GS1 Application Identifier data attributes (?17=271231), describe the item rather than filter the response: a resolver passes them on when it redirects and ignores them when it builds a linkset. accessRole is not a query parameter; it is metadata on each link (see Secure Targets).

Requesting the full linkset

A resolver MUST return the full linkset for the requested identifier, as defined by RFC 9264, instead of redirecting, when the request:

• includes the query parameter linkType=linkset, or
• carries an HTTP Accept header that includes application/linkset+json.

The HTTP Accept header selects the representation of that linkset. When it includes application/linkset+json, the resolver MUST return the linkset serialised as that media type. A resolver SHOULD return the same JSON representation for Accept: application/json. For Accept: text/html, or when the header is absent, a resolver SHOULD return a human-readable HTML page that presents the links and embeds the linkset as JSON-LD.

The contents of the linkset are not filtered by any other query parameter or request header. Each link carries metadata such as hreflang, type and accessRole, and the client selects the links it needs from it.

Clients MUST use one of these two forms to request the full linkset. A client that requires the machine-readable JSON representation MUST send Accept: application/linkset+json; linkType=linkset alone requests the linkset but does not select its representation. The query parameter is useful for cases where the client cannot set request headers, such as a URL printed in a QR code or a hyperlink in a document, where an HTML representation is appropriate. A resolver that selects either the kind or representation of its response using the Accept header SHOULD send Vary: Accept, so that a cache does not hand a redirect or the wrong representation to a client.

This rests on RFC 9264, which defines the linkset format and media type, and on ISO/IEC 18975, which is the basis of the query URL (see requirement 13). It does not depend on any scheme-specific resolver standard.

note

Earlier versions of GS1 Digital Link (1.1) used linkType=all for this purpose. GS1 has since deprecated it. The Log of Changes in the GS1-Conformant Resolver Standard says:

The preferred value to be used for the linkType parameter when requesting the linkset is now 'linkset'. The previous value, 'all', is deprecated but existing implementations are encouraged to continue to support 'all' until further notice.

Resolvers MAY accept linkType=all as an alias for backwards compatibility; clients SHOULD NOT send it.

Example: opaque product register (non-GS1)

A typical IDR query for a scheme that treats the product ID as a single opaque value:

https://resolver.products.sample-register.example/ABC123456?linkType=linkset

which requests the complete link-set about product ABC123456. There is no separate serial/batch segment — granularity (model, batch, or item) is whatever the scheme encoded into that single ID.

Variants:

• https://resolver.products.sample-register.example/ABC123456?linkType=dpp → Product Passport only
• https://resolver.products.sample-register.example/ABC123456 → redirect to the default link target

Example: ASC MH10 / ISO/IEC 15459 structured path (non-GS1)

Schemes that use ASC MH10.8.2 Data Identifiers with ISO/IEC 18975 structured paths follow the same resolve-to-linkset pattern. For example, a primary DI for a serialised product might resolve as:

https://resolver.industrial-ids.example/25S/IAC42PROD987654?linkType=linkset

Here 25S is the scheme’s registered identifier key type (Data Identifier shortcode) and IAC42PROD987654 is the identifier value. No GS1 Application Identifier is required.

Example: GS1 Digital Link-style path (optional multi-segment)

Where a scheme does use multi-segment identity (common with GS1), a query might be:

https://resolver.sample-register.example/01/09506000134352/21/1234?linkType=linkset

This is a GS1 Digital Link URI (GTIN 09506000134352, serial 1234), and a GS1-Conformant Resolver answers it with the same RFC 9264 linkset. See Composing with GS1 Digital Link for using one on-pack QR code for both.

Another scheme might use human-readable shortcodes it has registered itself (GS1 Digital Link no longer allows these, so this is not a GS1 URI):

https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset

which requests the complete link-set about product class ABCD9876 with serial 1234. Those extra path segments are part of that scheme’s ID syntax — not a UNTP requirement for every scheme.

Further variants for the shortcode form:

• https://resolver.sample-register.example/products/ABCD9876?linkType=linkset → product class only
• https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=dpp → Product Passport only
• https://resolver.sample-register.example/products/ABCD9876/items/1234 with Accept-Language: de → redirect to the German-language default link
• https://resolver.sample-register.example/products/ABCD9876/items/1234 → redirect to the default link

DID-based identifiers follow the same Discover–Resolve–Verify workflow via DID resolution rather than a registry path; see Implementation Guidance: Self-Issued Identifiers (DIDs).

Facility resolution

Facility identifiers use the same IDR query and linkset model as products. A facility-only register does not introduce a separate resolution protocol: it reuses the ISO/IEC 18975 structured path and RFC 9264 linkset response, typically without serial/batch qualifier segments.

A typical facility IDR query might be:

https://resolver.facilities-register.example/ABC123456?linkType=linkset

which is requesting the complete link-set about facility ABC123456 in the facilities-register.example scheme. Equivalent structured-path forms (depending on how the scheme registers its identifier key type) include:

• https://resolver.facilities-register.example/facility/ABC123456?linkType=linkset
• https://resolver.facilities-register.example/facility/ABC123456?linkType=https%3A%2F%2Ftest.uncefact.org%2Fvocabulary%2Flink-type%2Fdfr → redirect or return only the Facility Record link (dfr is an extension relation type, so the query carries its percent-encoded URI)
• https://resolver.facilities-register.example/facility/ABC123456 → redirect to the default link target (often the Facility Record)

A typical linkset response for that facility query:

{
  "linkset": [
    {
      "anchor": "https://resolver.facilities-register.example/facility/ABC123456",
      "https://test.uncefact.org/vocabulary/link-type/dfr": [
        {
          "href": "https://sample-credential-store.example/credentials/dfr/ABC123456.json",
          "type": "application/vc+jwt",
          "title": "Facility Record",
          "hreflang": ["en"]
        }
      ],
      "https://test.uncefact.org/vocabulary/link-type/dcc": [
        {
          "href": "https://sample-credential-store.example/credentials/dcc/facility-ABC123456-iso14064.json",
          "type": "application/vc+jwt",
          "title": "Facility emissions conformity credential",
          "hreflang": ["en"]
        }
      ]
    }
  ]
}

• There is a single context whose anchor is the facility identifier URI (no item/serial qualifier path).
• The dfr link relation points to the Facility Record for that facility.
• Additional typed links (for example dcc) MAY appear on the same facility anchor when related conformity evidence exists.

Facility resolution therefore follows the product path as-is, omitting product-centric qualifier conventions that do not apply.

Linkset Format

The response to an IDR query is an IETF linkset which contains one or more contexts, each of which contain one or more targets.

• A context describes what the links are about using the anchor property. Often there is only one anchor that represents the requested identifier. But as described in the resolver workflow, a resolver may return links about related entities. For example, a query about a specific serialized item may return some links about the item, and some links about the product class, and even some links about the manufacturer or brand that sells the product.
• A target describes a specific link identified with the href property together with other properties that provide useful meta-data about the link.

A typical response to the sample query https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset might be as shown below:

• There are two contexts: one at serialized item level "anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234" and one at product class level "anchor": "https://resolver.sample-register.example/products/ABCD9876"
• The first context has two targets, both of which have a linkType "dpp" (UNTP digital product passports) and MIME type application/vc+jwt but one is rendered in German and the other in English
• The second context is at product level and has one target which points to the manufacturer's product information web page. This highlights that link resolvers can return all kinds of relevant links, only some of which point to UNTP credentials

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234",
      "dpp": [
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "type": "application/vc+jwt",
          "title": "Digital Product Passport",
          "hreflang": ["en"]
        },
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869311.json",
          "title": "Digitaler Produktpass",
          "hreflang": ["de"],
          "type": "application/vc+jwt"
        }
      ]
    },
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876",
      "pip": [
        {
          "href": "https://sample-company.example/productInformation/ABCD9876",
          "type": "text/html",
          "title": "Product Information"
        }
      ]
    }
  ]
}

Linksets MUST use IANA-registered link relation types, UNTP-defined link relation types, or link types that, as defined in RFC 8288, can be expressed as URLs; and IANA Media Types to describe the semantics and formats of linked resources.

Link type (e.g., dpp) and media type (e.g., application/vc+jwt) indicate the intended content. However, due to domain sovereignty principles, actual content can only be verified by dereferencing and validating.

Linkset Response Patterns

This section covers specific linkset use cases that SHOULD be supported by conforming link resolvers. The general approach to solving linkset specific needs is:

• Where possible, always use IETF linkset standard properties and IANA standard link types.
• Where necessary, use custom link types and linkset properties but always define them in a public vocabulary and reference them using a profile link type.

Defaults

Default link types allow a resolver to return just the target URL of the default link - which means that client applications (including just a camera on a mobile phone) need not have any knowledge of link resolvers and how they work.

Link resolver services SHOULD define DEFAULT link type for each anchor which defines the href target to which a client will be redirected when no linkType is specified in the matching query URL. In the previous IDR example, calling the resolver URL without a linkType parameter:

https://resolver.sample-register.example/products/ABCD9876/items/1234

Would redirect the client directly to the target href of the default link type:

https://sample-credential-store.example/credentials/dpp-90664869327.json

Automatically Returning The Right Language

HTTP headers often contain accept header properties that can be useful hints for link resolver behaviour. For example, browsers normally include an Accept-Language header that matches the user's configured preference. A resolver can use it to choose the most appropriate redirect target when several links of the requested type are available. It does not filter a full linkset, which continues to contain every language variant. For example, consider an IDR that:

• defines a default link type as dpp
• maintains DPP links in a dozen languages
• and receives the following HTTP query URL

GET /products/123456789 HTTP/1.1
Host: resolver.sample-company.example
Accept-Language: de

Even though there are a dozen DPP links maintained by the IDR service, only one of them is in German and so the IDR can again redirect the client to the specific target URL of the German language DPP:

https://sample-credential-store.example/credentials/dpp-90664869311.json

Secondary Resolvers

There are some cases where an identifier scheme owner manages identifiers at a coarse granularity by issuing globally unique prefixes but allows the subject to manage more fine grained identifiers themselves. For example:

• A product register maintains product identifiers in a single global register but management of serialised items is left to the owner of the GTIN.
• IATA issues 3 character carrier identifiers but allows each carrier to add the 7 digit suffix for each cargo consignment to make a globally unique 11 digit consignment number.
• Australian government manages 8 alpha-numeric character farm identifications codes such as QDBH0132 and allows each farmer to add a unique suffix to identify each unique livestock animal born on the farm.

and many more examples exist.

The result is that a client may construct an IDR query to the genuine scheme operator's IDR service but that service may not hold information at the requested granularity. In such cases, a conformant IDR SHOULD return links relevant to the more coarse grained item and, if available, a link to a secondary resolver service (eg hosted by the serialised product manufacturer) that can return more fine grained information. For example the following query to a link resolver about a serialised item:

https://resolver.sample-register.example/products/ABCD9876/items/1234

May return a link to a secondary resolver that maintains data at serialised item level as well as a link to a DPP at product class level.

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234",
      "linkset": [
        {
          "href": "https://resolver.sample-company.example/products/ABCD9876/items/1234",
          "title": "Secondary Identity Resolver",
          "hreflang": ["en"],
          "type": "application/linkset+json"
        }
      ]
    },
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876",
      "dpp": [
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang": ["en"],
          "type": "application/vc+jwt"
        }
      ]
    }
  ]
}

Versioned Targets

In some cases, a publisher may wish to maintain multiple versions of a credential as available links in a linkset. The recommended method is to add the relevant IANA version link relation to the rel value array as shown in the example below. In this case there are two links for the same anchor, both include dpp as a link relation value but one also has the IANA link relation predecessor-version:

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876",
      "dpp": [
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang": ["en"],
          "type": "application/vc+jwt"
        },
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869111.json",
          "rel": ["predecessor-version"],
          "title": "Digital Product Passport",
          "hreflang": ["en"],
          "type": "application/vc+jwt"
        }
      ]
    }
  ]
}

Creating New Links

In some cases, an identity resolver service may wish to accept updates such as creation of new links from appropriately authorised users. For example, adding a maintenance event to a battery passport record after the battery has been sold into the market. An identity resolver SHOULD accommodate this possibility by including a link in the linkset for the given product that specifies how to POST an event to the resolver. In the example below, an anchor representing product https://resolver.sample-register.example/products/ABCD9876 has two links. The first is a simple link to a DPP describing the product. The second describes a method to create a new maintenance event.

• The standard IANA link relation edit indicates that the target resource is used to edit the link's context.
• The UN/CEFACT link type dte (https://test.uncefact.org/vocabulary/link-type/dte) indicates that the target expects a digital traceability event.
• The custom property method indicates that the HTTP header requires a POST method and a secret key in the X-API-Key HTTP header property.

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876",
      "dpp": [
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang": ["en"],
          "type": "application/vc+jwt"
        }
      ],
      "https://test.uncefact.org/vocabulary/link-type/dte": [
        {
          "href": "https://sample-credential-store.example/credentials/dte",
          "rel": ["edit"],
          "title": "Create Maintenance Event",
          "method": ["POST", "X-API-Key"],
          "type": "application/vc+jwt"
        }
      ]
    }
  ]
}

Secure Targets

In some cases the target of a link contains sensitive data that is not generally accessible to the public. In such cases, as described by the decentralised access control specification, the target of the link is encrypted and requires a decryption key or proof of authorised role to decrypt. The corresponding link in the resolver linkset SHOULD specify the encryption method and allowed list of access roles.

accessRole on a link describes who the publisher intends to disclose that target to. It is metadata for the client, not a query parameter: the resolver returns every link, and the client uses accessRole to tell which targets, or which document variant, are meant for it. It does not authenticate anyone and protects nothing by itself; non-public targets are protected by encryption or by access control at the storage location. Issuing a separate signed variant limits the claims it contains but does not restrict retrieval. See Disclosing the Data.

Each accessRole value MUST be an absolute URI. UNTP does not define a fixed role list: a publisher may use URIs for registrar-recognised capacities or for relationships established under its own access policy. Full URIs are required because an RFC 9264 linkset is plain JSON and does not provide JSON-LD prefix expansion. See Confidential data discovery for matching and authorisation guidance.

{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.example/products/ABCD9876",
      "https://test.uncefact.org/vocabulary/link-type/dte": [
        {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Product Traceability",
          "encryptionMethod": "AES-128",
          "accessRole": ["https://roles.example/owner"],
          "hreflang": ["en"],
          "type": "application/vc+jwt"
        }
      ]
    }
  ]
}

Resolver Workflow

The internal workflow of an identity resolver service is not defined by this specification. However, there are some common conditions that a link resolver service SHOULD manage consistently. For example

• When a query URL is not valid
• When there is no data for the requested entity ID.
• When there is no data for an item level ID but there are available links for product class level ID
• When a requested link type does not exist.

These cases are shown in the example resolver workflow diagram below.

When the requested link type is not available at any level, the example returns 404 Not Found rather than falling back to the default link. This matches the GS1-Conformant Resolver Standard, which made the same change from earlier versions of GS1 Digital Link. A client that asked for dpp and silently received a marketing page would have no way to tell.

Creating the IDR Query URL

There are several forms in which an identifier might be discovered (e.g., as a data carrier on a physical product or as a URI in a structured document). The identifier representation format is often not an IDR query URL and so may need to be translated into an IDR URL query format. The generalized process to derive an IDR query URL has two steps:

1. Map the native format found in a data carrier to a consistent global URI as described in the Identifier Representation section
2. Map the global URI to an IDR query string as described in the following paragraphs

This mapping architecture is designed to ensure that UNTP can accommodate any new or existing identifier scheme and any data carrier and still maintain linked data consistency (i.e., consistent URI representation) as well as resolvability and verifiability of identifiers.

From a URN to IDR linkset:

The UN global trust register will include resolver templates for each scheme and so the UNTP requirement that identifiers be resolvable is met by substituting the URN {identifier-value} into the {id} placeholder in the resolver template related to the matching {identifier-scheme}. For example:

• Given a URN ID of urn:gtr:example.com:ABC123, the {identifier-scheme} is example.com
• And a resolver template of https://resolver.example/{id} is registered for scheme example.com
• Then the resolver URL would be https://resolver.example.com/ABC123 which would return an IDR LinkSet

From a URL to IDR linkset:

As described in IDR URLs as identifiers, URL identifiers SHOULD already be Identity Resolver URLs that conform to the ISO/IEC 18975 structured path syntax without parameters. Client applications may of course add parameters to the URL before calling the resolver service to get more specific link sets.

Verification

Once an identifier has been discovered and resolved to a linkset, the next step is verifying the information linked from that identifier. This stage is common to both registry-managed and self-issued identifiers.

The Identity Resolver itself does not perform verification of credentials or content. Its role is to:

• Provide a consistent, machine-readable linkset for any supported identifier.
• Use typed links (e.g. dpp, dcc) and media type declarations (e.g. application/vc+ld+json) to clearly signal when a linked resource is expected to be a verifiable credential.
• Enable client systems and verifiers to retrieve and independently verify the linked resources.

Trust Models

Although the verification step is external to the resolver, the underlying trust anchors differ:

• Registry-managed identifiers: verifiers may rely on the registry's governance (identifier issuance rules, who is authorised to publish linksets) as part of their trust decision.
• Self-issued identifiers (DIDs): verifiers rely on cryptographic proof of control (DID method rules, signatures) to ensure the identifier holder really controls the linked resources.

Claimed and unclaimed identifiers

A register may mint and maintain identifiers for subjects that have never interacted with it. An open facility register can list a mine from satellite imagery and public filings; a product-data aggregator can mint identifiers for products it has observed in the market. Those identifiers are useful and resolvable, but nobody has asserted control of them. An identifier is claimed once its subject — the facility operator, the product's producer, the organisation itself — takes responsibility for the record it identifies, and unclaimed until then.

The distinction is a property of identifier schemes and their resolution, not of any one credential type. It applies to any register that mints identifiers for subjects which have not asked it to — facilities, products, organisations, assets — and it changes what a verifier may infer from resolving the identifier:

• Resolving an unclaimed identifier establishes only that the register maintains it. The linkset and any directory information are the register's own assertions, made on whatever evidence the register holds. Resolution alone does not imply that the subject accepts the record, or is even aware of it.
• Resolving a claimed identifier additionally establishes that a known subject has taken responsibility for the record. Content the subject publishes against the identifier is the subject's own voice; the register's role narrows to maintaining the identifier and recording the claim.

A conformant UNTP implementation:

• MAY maintain and resolve as many identifiers as it wishes, claimed or unclaimed, and MAY publish directory information about them.
• MUST NOT issue a credential that speaks for a subject — a facility record, a corporate record — against an identifier its subject has not claimed, if the issuer is the register that minted that identifier. A register maintains identifiers; it does not speak for the parties behind them.
• MUST NOT create a decentralised identifier on behalf of a subject that has not claimed the corresponding identifier.
• MUST NOT, as a verifier, treat the resolvability of an identifier as evidence that its subject stands behind the record it resolves to.

Claiming is ultimately an assertion of control, and the Digital Identity Anchor is the general mechanism for recording one: the subject proves control of a decentralised identifier under the register's rules, and the register binds the claimed identifier to that DID for a stated period, so a verifier can check subject-voiced content against the binding that was current when it was published. Once an identifier is claimed, the subject is the source of truth for the record content, and the register remains the issuer of the identifier. The register may also act as the subject's software provider, including operating a decentralised identifier on their behalf — see identifier control and key custody.

The credential specifications apply this rule to their own subjects: the Digital Facility Record to facility identifiers, the Digital Corporate Record to legal entities, and the Digital Identity Anchor to register members.

Relationship to UNTP Credential Verification

Linked resources such as Digital Product Passports (DPPs) or Digital Conformity Credentials (DCCs) are expected to be expressed as W3C Verifiable Credentials. These credentials can be verified independently using the mechanisms defined in the UNTP Verifiable Credential Profile. Implementations that traverse linked credentials SHOULD verify each resolved credential as described in Verification during traversal before incorporating it into derived conclusions or query results.

By separating resolution from verification, the Identity Resolver stays lightweight and interoperable, while implementers remain free to apply the appropriate trust model and verification rules for their sector or geography.

The Identity Resolver is a discovery service, not an archive. A link-set MAY include links to durable copies of a credential and of the verification material that credential depends on (DID documents, status-list credentials, JSON-LD contexts), as described in Durable Storage. Clients retrieve and verify those resources. The resolver does not cache them on the client's behalf and does not define a mirror or witness-proof protocol.

When a resolver or credential host is no longer reachable, cached copies, content-addressable URIs, and downstream preservation packages are patterns described in Durable Storage. This specification does not define additional link types or a durability property for that case.

Domain Sovereignty

This specification acknowledges the fundamental principle of domain sovereignty as codified in IETF Best Current Practice 190 (BCP 190): domain owners have complete authority over their URI space and can define any URL structure they choose.

Important: Domain Sovereignty

While this specification describes how identifiers should resolve and what link types should indicate, domain owners have complete authority over their URI space (IETF BCP 190). URL patterns, link types, and media types are hints about intended content—not guarantees. Clients must always validate actual content after dereferencing.

Critical implications for implementers:

• A URL that appears to conform to ISO/IEC 18975 structure does not guarantee it resolves to an Identity Resolver service
• A link with type dpp does not guarantee it points to a UNTP-conformant Digital Product Passport
• A link with media type application/vc+jwt does not guarantee the content is a UNTP credential—it could be any verifiable credential format
• Even when link type, media type, and URL structure all match expectations, the actual content can only be determined by dereferencing the URL (performing an HTTP GET request)
• Different DPP implementations, standards, or formats may use the same link types and media types

Real-world scenarios:

Scenario 1: Same link type, different DPP standards

{
  "linkset": [
    {
      "anchor": "https://resolver.example.com/products/ABC123",
      "dpp": [
        {
          "href": "https://manufacturer-a.example/dpp/ABC123",
          "type": "application/vc+jwt",
          "title": "Digital Product Passport"
        },
        {
          "href": "https://manufacturer-b.example/dpp/XYZ789",
          "type": "application/vc+jwt",
          "title": "Digital Product Passport"
        }
      ]
    }
  ]
}

Both links use dpp and application/vc+jwt, but one could be UNTP-conformant while the other implements a different DPP standard entirely. Only dereferencing and validating reveals the truth.

Scenario 2: ISO/IEC 18975-like URL without IDR service

The URL https://example.com/01/09520123456788 appears to follow ISO/IEC 18975 Digital Link structure, but:

• Without a Resolver Description File at https://example.com/.well-known/resolver (or /.well-known/gs1resolver for a GS1-Conformant Resolver), there's no declaration this is an IDR
• The domain owner (per IETF BCP 190) could use this URL pattern for any purpose: a product catalog, an internal tracking system, or even unrelated content

Scenario 3: Link rot and URL reuse

Even if a URL currently points to a UNTP DPP, domains may:

• Restructure their website, breaking the link
• Repurpose the URL for different content
• Change ownership, with new owners using the same URL structure differently

Verification approach for clients:

1. ISO/IEC 18975 provides the /.well-known/ method (RFC 8615) for domains to declare resolver services
2. Before assuming a domain hosts an IDR service, clients SHOULD verify that {domain}/.well-known/resolver exists and contains a valid Resolver Description File. GS1-Conformant Resolvers publish theirs at {domain}/.well-known/gs1resolver, and clients SHOULD accept that as an equivalent declaration
3. Services expecting specific URL patterns SHOULD process them optimistically while being prepared for:
   • Non-conformant responses
   • Different standards using similar link types
   • URLs that appear conformant but return unexpected content
4. Always validate the actual content after dereferencing—do not rely solely on URL patterns, link types, or media types
5. Implement robust error handling for cases where responses do not match expectations

Best practices:

• For resolver operators: Publish a Resolver Description File at /.well-known/resolver to declare your service per ISO/IEC 18975
• For clients: Treat link type and media type as hints about intended content, not guarantees. Validation occurs after retrieval.

Implementation Guidance: Registry-Managed Identifiers

This section is for operators of centralised identifier registries (e.g., GS1, national business registers, sector schemes). Registry-managed identifiers are issued or recognized by an authoritative register, which defines the rules for identifier issuance and for authorizing who may add links against the identifier.

The diagram below illustrates identifier schemas across three entity types: businesses, locations, and products. It demonstrates how existing identification systems can be made interoperable through the UNTP Identity Resolver.

Data Carriers

UNTP supports any standard data carrier. Recommended are those defined in ISO/IEC JTC 1/SC 31, such as linear barcodes, Data Matrix, QR Codes, and RFID.

• Carriers differ in scanning needs: RFID requires specialist readers; barcodes require optical scanners with software able to interpret identifiers.
• Smartphones can read most barcodes and NFC tags, with QR Codes carrying URLs the most broadly accessible. Risks (e.g. link rot) are mitigated by encoding identifiers that are globally unique online and offline within URLs as defined in ISO/IEC 18975 Information technology — Automatic identification and data capture techniques — Encoding and resolving identifiers over HTTP.

Offline use cases

Some use cases require identifiers to work offline. A common example is retail, where QR codes (or other data carriers) encode GS1 application identifiers such as expiration dates; scanning may happen without network access. Implementers should consider both online resolution and offline interpretation of encoded data where applicable.

QR Code Size Optimization

QR code physical size is determined by the number of modules (cells), which depends on both data length and the character set used. QR encoders use Numeric mode (digits only), Alphanumeric mode (uppercase + digits + 9 symbols), or Byte mode (any character, least efficient). Because the URL scheme (https) and host are case-insensitive (RFC 3986 §3.1, RFC 4343), implementers encoding resolver URLs in QR codes SHOULD use uppercase for the scheme and host components (e.g., HTTPS://ID.EXAMPLE.COM/...) to allow the QR encoder to use the more compact Alphanumeric mode, resulting in a smaller QR code at no cost to interoperability.

Where identifier path and query values are also uppercase (e.g., GS1 Application Identifier syntax), the entire URL can be encoded in Alphanumeric mode. Scheme-specific compression algorithms (such as GS1 Digital Link compression) may provide further size reductions when many query parameters are present, but are outside the scope of this specification; implementers should follow the relevant scheme standard.

In Automatic Identification and Data Capture (AIDC), the ISO/IEC 15459 series establishes a registry for short codes in data carriers. Organizations issuing barcode and RFID identifiers receive a unique Issuing Agency Code to prevent conflicts. ISO/IEC 15418 defines Data Identifiers (DIs) and Application Identifiers (AIs), which qualify identifiers, ensuring globally unique encoding in optical and RFID data carriers.

For example:

• DI 2B identifies gas cylinders per U.S. D.O.T. standards.
• AI 01 represents a Global Trade Item Number (GTIN).

Examples of carrier encodings

The same identifier may appear in multiple carrier forms but must normalize to a consistent URI:

• 2D Matrix barcode: 0107332402265910211234567890…
• RFID (EPC tag URI): urn:epc:tag:sgtin-96:1.7332402.026591.1234567890
• QR Code (with ISO/IEC 18975-compliant payload): https://brand.example/01/07332402265910/21/1234567890

All three carry GTIN 07332402265910 with serial 1234567890, and all three normalise to https://id.gs1.org/01/07332402265910/21/1234567890.

Scanners are expected to apply scheme-specific logic to normalize these carrier data forms into UNTP URNs/URIs that align with identifiers used in credentials (e.g., DPPs). For detailed identifier representation conventions, see Identifier Representation.

Mapping Carriers to URIs

A key challenge is to ensure that all these different data carrier representations are mapped to a consistent globally unique identifier when building value chain transparency graphs.

• A 2D Matrix code might yield the string 0107332402265910211234567890240+A01=442.001-UP001T91456498765498765465432132168753 where 07332402265910 is the GTIN (Application Identifier 01) and 1234567890 is the serial number (Application Identifier 21)
• An RFID Tag for the same product might yield a string like urn:epc:tag:sgtin-96:1.7332402.026591.1234567890 where 7332402 is the company prefix, 026591 the indicator digit and item reference (together with a calculated check digit they make up the same GTIN), and 1234567890 is the serial number.
• A QR code may yield https://brand.example/01/07332402265910/21/1234567890, a GS1 Digital Link URI on the brand's own domain carrying the same GTIN and serial number.

Existing data carrier schemes are very varied but usually well documented. Therefore it is reasonable to expect that scanners will be aware of the context and will include scheme specific logic to read the data carriers and construct UNTP standard URNs or URIs to match against identifiers used in credentials such as digital product passports.

For new identifier schemes or existing schemes that have not already defined data carrier specifications, UNTP implementers SHOULD

• directly encode the UNTP URN structure into 2D matrix codes and RFID tags.
• directly encode the UNTP URL structure into QR codes.

Registry Resolver Configuration

Resolution for registry-managed identifiers is typically achieved by dereferencing a URI template defined by the identifier scheme (which SHOULD be conformant with ISO/IEC 18975).

• Domains SHOULD declare their resolver service via a Resolver Description File at {domain}/.well-known/resolver per ISO/IEC 18975 and RFC 8615.
• When available and conformant, the resolver returns an IETF linkset as a JSON document containing typed links from the identifier to other resources.

Composing with GS1 Digital Link

Most consumer goods already carry a GS1 barcode, and as point-of-sale scanning moves to 2D, brands are printing QR codes that encode a GS1 Digital Link URI. That QR code can serve as the UNTP carrier. Implementers SHOULD NOT add a second, UNTP-specific code beside it: two codes on one pack is the confusion requirement 02 exists to avoid, and the cost of redesigning packaging falls hardest on small producers.

This works because the GS1-Conformant Resolver Standard (version 1.2.1) and this specification are built on the same two standards, ISO/IEC 18975 for the URI path and RFC 9264 for the linkset. A GS1-Conformant Resolver already returns a linkset for linkType=linkset or an Accept: application/linkset+json header, redirects to a requested link type, and includes links inherited from less granular levels (a serialised item inherits its GTIN's links). Once the brand's resolver holds a link to the passport, UNTP clients can find it.

Worked example

A food producer prints this QR code on a batch of jars:

https://brand.example/01/09506000134352/10/LOT2026A?17=271231

01 is the GTIN, 10 the batch or lot number, and 17 the expiry date. The expiry date sits in the query string because it is a data attribute of the item and not part of its identity. A till can read it without going online.

A phone camera with no special app follows the default link, which in retail is normally the consumer product page. A UNTP-aware app, or a buyer's receiving system, asks the same resolver for the linkset:

GET /01/09506000134352/10/LOT2026A?linkType=linkset HTTP/1.1
Host: brand.example
Accept: application/linkset+json

{
  "linkset": [
    {
      "anchor": "https://brand.example/01/09506000134352/10/LOT2026A",
      "https://ref.gs1.org/voc/dpp": [
        {
          "href": "https://credentials.brand.example/dpp/09506000134352-LOT2026A.json",
          "title": "Digital Product Passport",
          "type": "application/vc+jwt",
          "hreflang": ["en"]
        }
      ]
    },
    {
      "anchor": "https://brand.example/01/09506000134352",
      "https://ref.gs1.org/voc/pip": [
        {
          "href": "https://brand.example/products/strawberry-jam",
          "title": "Strawberry jam 340 g",
          "type": "text/html",
          "hreflang": ["en"]
        }
      ],
      "https://ref.gs1.org/voc/defaultLink": [
        {
          "href": "https://brand.example/products/strawberry-jam",
          "title": "Strawberry jam 340 g"
        }
      ],
      "https://test.uncefact.org/vocabulary/link-type/dcc": [
        {
          "href": "https://certifier.example/credentials/organic-09506000134352.json",
          "title": "Organic certification",
          "type": "application/vc+jwt",
          "hreflang": ["en"]
        }
      ]
    }
  ]
}

The batch-level passport and the product-level conformity credential come back in one response, next to the consumer page. Nothing on the pack changed.

Where the two line up, and where they differ

Passport link type. A GS1-Conformant Resolver types the passport link gs1:dpp (https://ref.gs1.org/voc/dpp), and the GS1 standard says link types defined elsewhere shall not duplicate GS1 ones. UNTP linksets use the IANA-registered dpp. Clients looking for a passport SHOULD treat dpp and https://ref.gs1.org/voc/dpp as the same link type. To be redirected straight to the passport by a GS1 resolver, request linkType=gs1:dpp. UNTP link types that GS1 has no equivalent for, such as dcc, dte and dfr, are valid RFC 8288 extension relation types represented by their UN/CEFACT URIs. The linkset schema required by GS1-Conformant Resolver 1.2.1 excludes hyphens from URI relation keys, so it rejects the link-type segment in those URIs. A linkset containing these UN/CEFACT relation types therefore cannot conform to that version of the GS1 standard. Implementers combining the two standards should check that the applicable GS1 schema accepts the UN/CEFACT relation URIs. gs1:certificationInfo is not a substitute for dcc, since it can point at any certification information, including a PDF.

Default link. In retail the default (gs1:defaultLink) is almost always the consumer product page, while several examples on this page make the passport the default. Neither specification requires either choice. On a consumer pack, keep the consumer page as the default and let UNTP clients ask for what they need. Clients SHOULD NOT rely on the default link being a passport.

Missing link types. Both now answer 404 Not Found when a requested link type does not exist at any level (see Resolver Workflow). Clients should handle a 404 and can read any linkset returned with it.

The domain on the pack and the identifier in credentials. GS1 Digital Link lets a brand use its own domain, so the same jar might be scanned as https://brand.example/... today and through a retailer's or GS1's domain tomorrow. Credentials need one stable form so that a passport, a conformity credential and a traceability event about the same item match (see Identifier Representation). For GS1 identifiers, UNTP credentials SHOULD start with the canonical GS1 Digital Link URI defined in the URI Syntax standard (https, host id.gs1.org, GTIN padded to 14 digits) and then remove its query component. This last step is a UNTP rule: GS1's canonical form retains query parameters whose keys are GS1 Application Identifiers, including data attributes such as the expiry date 17, but UNTP removes them because they do not form part of the product, batch or item identity. The canonical GS1 URI for the jar above is https://id.gs1.org/01/09506000134352/10/LOT2026A?17=271231; its UNTP credential identifier is https://id.gs1.org/01/09506000134352/10/LOT2026A. A scanner derives the credential identifier by keeping the identity path, replacing the host and removing the query component. The brand-domain URI on the pack keeps working for resolution.

Granularity. The deepest key qualifier on the pack sets the finest granularity a scan can reach: GTIN alone for a model, 10 for a batch, 21 for a serialised item. A passport issued at a coarser level is still found, because the resolver returns inherited links. The passport's idGranularity and id should match the level it was issued at, not the level of the code that was scanned.

Resolver description file. GS1-Conformant Resolvers publish theirs at /.well-known/gs1resolver. The ISO/IEC 18975 location is /.well-known/resolver. Clients SHOULD accept either (see Domain Sovereignty).

Requesting the full linkset. A GS1-Conformant Resolver supports both forms required in Requesting the full linkset, so a UNTP client needs nothing GS1-specific here. The note in that section covers the older value all.

Compression. GS1 resolvers must decompress EPC binary strings and may support the wider GS1 Digital Link compression. Credentials should always carry the uncompressed URI, which is also what a GS1 resolver uses as the linkset anchor.

A GS1 resolver only handles GS1 keys. Products identified under other schemes, and identifiers issued as DIDs, use the rest of this page in the same way, which is why the examples here are not GS1-only.

End-to-End Example: Product

1. Items in an inbound shipment are barcoded using an existing, well-known scheme (no UNTP-specific barcode). For GS1 barcodes and Digital Link QR codes, see Composing with GS1 Digital Link.
2. A scanner captures an item ID (e.g., 1234567) and either constructs a URL directly (per ISO/IEC 18975) or looks up the scheme in the UN global register of schemes.
   • Example template: https://resolver.example/{id} → https://resolver.example/1234567.
3. Calling the URL https://resolver.example/1234567 returns an IETF link-set listing typed links to resources.
   • Link types might include a safety data sheet, instruction manual, brand homepage, Product Passport, or Conformity Credential.
   • Each link declares both its type and media format (e.g., HTML, PDF, JSON), using IANA-registered Media Types.
4. A link typed of dpp with a format declaration of application/vc indicates a verifiable Product Passport credential.
   • The Product Passport may include sustainability claims (e.g., product emissions footprint).
   • Following a dcc link yields a credential from a third-party certifier (e.g., carbon intensity attestation).

In this model, the scheme register defines how IDs resolve and who is authorized to add links.

End-to-End Example: Facility

1. A national mining cadastre (or similar facility register) issues facility identifiers such as ABC123456. The register publishes an Identity Resolver for those identifiers; serial/batch qualifiers are not used.
2. A verifier obtains the facility identifier from a Facility Record reference, a Conformity Credential, a signage QR code, or a register lookup, and constructs the IDR query URL using the scheme's resolver template.
   • Example template: https://resolver.facilities-register.example/facility/{id} → https://resolver.facilities-register.example/facility/ABC123456.
3. Calling https://resolver.facilities-register.example/facility/ABC123456?linkType=linkset returns an IETF linkset for that facility anchor.
   • Link types typically include dfr (Facility Record) and MAY include dcc (facility-level Conformity Credentials) or other register-published documents.
4. A link typed dfr with media type application/vc+jwt (or equivalent VC media type) indicates a verifiable Facility Record.
   • Following the dfr href retrieves and verifies the Facility Record independently of the resolver.
   • Following a related dcc link yields third-party assessment evidence about the same facility identifier.

Facility-only resolvers therefore implement the same Discover–Resolve–Verify path as product resolvers; only the identifier class and default link relation (dfr rather than dpp) differ.

Implementation Guidance: Self-Issued Identifiers (DIDs)

This section is for organisations using W3C Decentralized Identifiers. Self-issued identifiers are created and controlled directly by an entity, without relying on a central registry. For details on which DID methods are acknowledged for use in UNTP implementations, see the DID Methods specification.

info

Note on DID Method Examples: Throughout this section, did:method is used as a placeholder in examples to represent any acknowledged DID method. The specific syntax, resolution mechanisms, and implementation requirements vary by method. For details on which DID methods are acknowledged by UNTP and their specific characteristics, see the DID Methods specification.

DID Discovery

• A DID string (e.g., did:method:123456789abcdefghi) can be carried in QR codes, RFID tags, or embedded in structured documents.
• Unlike registry-managed identifiers, there is no external register to provide discovery templates. Instead, the DID itself is the discovery key.
• Scanning a carrier or parsing a document yields the DID, which can then be resolved via its DID method.

Examples of carriers:

• QR Code containing a DID string: did:method:mycompany.example (see DID Methods for acknowledged methods).
• NFC tag with an embedded DID.
• Invoice document with a DID for the issuing organization in its metadata.

DID Documents as Resolvers

Resolution is performed according to the DID method specification (see DID Methods for acknowledged methods and implementation requirements). The result of resolution is a DID Document, which describes:

• Public keys and verification methods.
• Service endpoints, including resolvers for linksets.
• Supported key material and cryptographic suites.

From DID service endpoints, clients may retrieve linksets in the same IETF format used for registry-managed identifiers.

By design, all DIDs resolve to a URL that addresses a DID document. The way in which a DID resolves to a DID document is specific to the DID method (see DID Methods for acknowledged methods and implementation details).

Important Note on DID Path Structure

The path components shown in these examples (such as :products:123456789) are illustrative and demonstrate one possible organizational approach. DID-based identifiers do NOT require any specific path structure. Organizations are free to structure their DIDs in any way that suits their needs, or use simple flat structures without paths (e.g., did:method:sample-company.example:ABCD1234). The critical requirement is that each DID must be globally unique and resolvable according to its DID method specification (see DID Methods).

• DID with path structure: did:method:sample-company.example:products:123456789 is an example of a product identifier using an acknowledged DID method (see DID Methods) with an organizational path component
  • URL: https://sample-company.example/products/123456789/did.json would be the URL of the DID document according to the DID method specification (see DID Methods for resolution endpoints)
• DID without path structure: did:method:sample-company.example:ABCD1234 is an alternative example using a flat structure
  • URL: https://sample-company.example/ABCD1234/did.json would be the corresponding DID document URL according to the DID method specification

The DID document did.json has a standard data model defined by the W3C DID recommendation core properties. It is primarily designed to define the cryptographic methods by which control of a DID can be verified, including associated public keys. The DID service property can be used to reference further information such as UNTP credentials like a digital product passport. The UNTP approach to using a DID document as a resolver service combines conformant use of DID service properties with maximum alignment with IETF linksets.

• The DID document service.id property is the same as the linkset anchor property with the optional #fragment suffix to ensure that service.id is unique
• The DID document service.type property is the same as the linkset linkType value
• The DID document service.serviceEndpoint property is exactly the same as the linkset target object

{
  "id": "did:method:sample-company.example:products:123456789",
  "..other did document properties ..",
  "service": [{
    "id":"did:method:sample-company.example:products:123456789#dpp",
    "type": "dpp",
    "serviceEndpoint": {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang":["en"],
          "type": "application/vc+jwt"
     }
  }, {
    "id":"did:method:sample-company.example:products:123456789#linkset",
    "type": "linkset",
    "serviceEndpoint": {
          "href": "https://resolver.sample-company.example/products/123456789",
          "title": "Identity Resolver Service",
          "type": "application/linkset+json"
     }
  }]
}

Note: The DID in this example uses a path structure (:products:123456789), but organizations may choose any structure that ensures global uniqueness. For example, did:web:sample-company.example:ABCD1234 would be equally valid.

The example above shows two ways of using the DID document serviceEndpoint as an identity resolver service:

• The first target references a UNTP DPP credential directly
• The second target references a resolver service endpoint which itself would return a linkset

In this way, simple scenarios can be achieved simply by placing link targets directly in the DID document whilst richer and more dynamic link resolver services can also be delivered by including a DID document service which is itself a link resolver.

DID Deep Link Example

Decentralised Identifiers (DIDs) are a type of URI that are resolvable and verifiable by design. They are self-issued by any party and do not depend on any central register or issuing authority. The general structure of a DID is defined by the W3C Decentralised Identifiers recommendation.

This section shows how acknowledged DID methods can be used to define a globally unique product, company or facility DID and a discoverable deep link to the data associated with that DID. Every DID is associated with a DID Document. The digital product passport use case is used to show how to resolve from the globally unique product DID to the digital product passport data.

The DID method defines how the DID document is located, resolved, and how CRUD (create, read, update, delete) operations are performed. For details on acknowledged methods and their resolution mechanisms, see DID Methods.

To resolve the DID to the digital product passport, it needs to be combined with a DID resolver domain, the globally unique product DID, and optionally a service endpoint:

• resolver domain: The DID resolver implements the DID method and returns the DID document to the requestor. A free DID resolver is e.g. the Universal Resolver. The DID resolver can be freely chosen by the economic operator or can be built in-house.
• product DID: The product DID - when using acknowledged DID methods - is constructed according to the method's identifier syntax (see DID Methods for specific syntax details). It typically combines: 1. The DID method (e.g., did:web), 2. the Economic Operator domain that places the product on the market and where the DID document can be found, 3. the product identifier unique to that domain. The identifier portion may include organizational path components (e.g., :products:123456789) or use a flat structure (e.g., :ABCD1234) - the choice is entirely up to the organization, as long as the DID remains globally unique.
• service endpoint: The service endpoint can lead to different information e.g. a human readable DPP, a service API, or a DPP credential store.

The resulting URL including the resolver domain combined with product DID and service endpoint leads to the deep link of the digital product passport.

The table below shows the ingredients of a DID based DPP deep link URL:

Component	Description	Value
Resolver	DID resolver domain used to resolve the DID	https://resolver.example
DID Method	Method part of the DID – defined CRUD rules	did:method
Economic Operator domain	Domain that is under the control of the economic operator and that hosts the DID document	example.com
ID	Identifier that is unique to the product in the economic operator domain	model4TR
Product DID	This is the globally unique product identifier in form of a decentralised identifier (DID)	did:method:example.com:model4TR
Service Endpoint	Optional service endpoint parameter specifying what information to retrieve from the DID	?service=item-dpp

The deep link URL to the digital product passport is accordingly: https://resolver.example/did:method:example.com:model4TR/?service=item-dpp

It can be then put to different data carriers, such as QR codes, RAIN tags, or NFC tags. Below please find a QR code example carrying the DPP deep link (not resolvable!):

The figure below shows the information flow of accessing a digital product passport:

• The DPP deep link is scanned from the QR code, then
• the DID resolver is called and finds the DID document of the product DID.
• The DID document includes the human readable Battery Passport website URL under the provided service endpoint which is given back to the user who scanned the QR code.
• The user can explore the battery passport website.

End-to-End Example

1. A facility issues a DID for a machine it operates:
   • Example: did:method:abc123 (see DID Methods for acknowledged methods).
2. The DID string is resolved using the method's resolution rules (as specified in the DID Core specification).
   • Resolution yields a DID Document that describes key material, service endpoints, and supported link types.
3. The DID Document may include service endpoints that point to linksets or resources.
   • For example, a service endpoint could advertise a resolver URL returning an IETF linkset.
   • These linksets are structured identically to those in the registry-managed example, declaring typed links (DPP, DCC, manuals, etc.) and media formats using IANA Media Types.
4. A link of type dpp with format application/vc signals a verifiable credential.
   • The holder of the DID signs and publishes the DPP, which can be verified against keys in the DID Document.
   • A dcc link type may point to an attestation issued by an independent certifier, also verifiable via signatures.

In this model, the DID controller has direct responsibility for defining resolution endpoints and ensuring data availability. Governance is enforced cryptographically through key control rather than by a central register.

Roadmap

Future versions of this specification will

• Explore authenticated endpoints for fetching linksets — for example, a resolver that returns an extended linkset to a requestor who proves a role or identity via decentralised authentication — as a complement to, not a replacement for, the anonymous public resolution required by this version.