Identity Resolver

info

Please note that this content is under development and is not ready for implementation. This status message will be updated as content development progresses.

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.

Below is a table that compares both classes of identifiers:

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
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. A summary of formal requirements is provided at the end.

Common Requirements

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-Resolver-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 Linked Data Needs for identifier representation conventions.
• Discoverable — retrievable as structured data in documents, or machine-readable (barcode, QR, RFID). See Discoverable sections for Registry-Managed and Self-Issued implementations.
• Resolvable — dereferencing an identifier to obtain structured data. See Resolvable sections for Registry-Managed and Self-Issued implementations.
• Verifiable — claims made by the identifier's controller can be distinguished from third-party statements. See Verifiable (shared) for verification processes.

Registry-Managed Identifiers

Registry-managed identifiers are issued or recognized by an authoritative register (e.g., national business registry, product catalogue, or sector-specific scheme).

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.

The register defines the rules for identifier issuance and for authorizing who may add links against the identifier. Implementations can therefore treat the register itself as the source of truth for discovery and verification.

Discoverable

For registry-managed identifiers, discoverability is the first step: moving from an identifier encoded in a data carrier to a consistent URI representation. This process is detailed below, while the Self-Issued Identifiers section covers DID-based discovery.

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 ISO/IEC 18975 Digital Link, which encodes structured identifiers in URL paths.

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 (Digital Link URL): https://id.sample-resolver.example/01/733240226591/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 Linked Data Needs.

Mapping to consistent 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 733240226591 is the product ID (with company prefix) and 1234567890 is the serial number
• An RFID Tag for the same product might yield a string like urn:epc:tag:sgtin-96:1.7332402.026591.1234567890 where 7332402.026591 is the product ID and 1234567890 is the serial number.
• A QR code may yield https://id.sample-resolver.example/01/733240226591/21/1234567890 where 733240226591 is the product ID (with company prefix) and 1234567890 is the 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.

Outcomes

From varied carrier inputs, discovery yields a consistent, resolvable URI, enabling the next stage: resolution.

Resolvable

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 registry-managed resolution; see Self-Issued Identifiers - Resolvable for DID-based resolution.

Resolution mechanism

• Resolution is typically achieved by dereferencing a URL template defined by the identifier scheme (e.g., ISO/IEC 18975 Digital Link).
• The resolver returns an IETF linkset, a JSON-LD or JSON document containing typed links from the identifier to other resources.
• Linksets MUST use registered link relation types (IANA or UNTP-defined) and IANA Media Types to clearly describe the semantics and formats of linked resources.

Identity Resolver Services

This UNTP Identity Resolver (IDR) specification builds upon existing standards by defining specific constraints that improve interoperability and meet UNTP requirements.

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 and may include qualifiers (e.g., products/ABCD9876/items/1234)
• query contains a list of URL parameters that are used to filter the response (e.g., linkType=untp:dpp&language=en)

A typical IDR query might be:

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

which is requesting:

• the complete link-set
• about a product class ABCD9876
• issued using an identifier scheme supported by sample-register.example
• with specific serial number 1234

To get a different response, the query might be modified as follows:

• https://resolver.sample-register.example/products/ABCD9876?linkType=linkset → get data about the product class only, not a specific serialized item
• https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=untp:dpp → get only the DPP for the item
• https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=all&language=de → get all links to German language targets
• https://resolver.sample-register.example/products/ABCD9876/items/1234 → get a redirect to the target of the default link

IDR LinkSet Response

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 "untp: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",
            "untp: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",
            "sample:pip": [
                {
                    "href": "https://sample-company.example/productInformation/ABCD9876",
                    "type": "text/html",
                    "title": "Product Information"
                 }
            ]
        }
    ]
} 

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. As shown in the conceptual model, 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 Linked Data Needs 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:nlis.com.au:QDBH0132XBS01234, the {identifier-scheme} is nlis.com.au
• And a resolver template of https://resolver.nlis.com.au/{id} is registered for scheme nlis.com.au
• Then the resolver URL would be https://resolver.nlis.com.au/QDBH0132XBS01234 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-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.

Link-set Response Variations

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?linkType=linkset

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

https://sample-credential-store.com/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 will normally include a language accept header that matches the users configured preference. This can be used to return only those links that match the users language even if the IDR query string does not specify a preference. For example, consider an IDR that:

• defines a default link type as untp: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",
                    "rel": ["untp:idr", "ns1:handledBy"],
                    "title": "Secondary Identity Resolver",
                    "hreflang":["en"],
                    "type": "application/linkset+json"
                 }
            ]
        },
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "untp: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 untp: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",
            "untp: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 custom link relation untp: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",
            "untp:dpp": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Digital Product Passport",
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 }],
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "untp:dte": [
                {
                    "href": "https://sample-credential-store.com/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.

{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "untp:dte": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Product Traceability",
                    "encryptionMethod": "AES-128",
                    "accessRole":["untp:accessRole#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.

Outcome

Resolution transforms an identifier into a set of typed, machine-interpretable links, forming the foundation for subsequent verification of both the identifier itself and any linked claims.

Verifiable

Verifiability for registry-managed identifiers depends on governance rules defined by the registry. These rules determine who is authorised to publish linksets and associated credentials.

See Verifiable (shared) for how verification is performed across all identifier types.

Outcome

Verifiability ensures that information retrieved via an identifier is not only discoverable and resolvable, but also provably authentic—anchored either in registry authority or in cryptographic credentials that can be independently validated.

Example

1. Items in an inbound shipment are barcoded using an existing, well-known scheme (no UNTP-specific barcode).
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, Digital Product Passport (DPP), or Digital Conformity Credential (DCC).
   • Each link declares both its type and media format (e.g., HTML, PDF, JSON), using IANA-registed Media Types.
4. A link typed of dpp with a format declaration of application/vc indicates a verifiable DPP credential.
   • The DPP 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.

Self-issued identifiers follow the same D-R-V flow, but supply resolution data through the DID Document and method-specific process described in the Self-Issued Identifiers section.

Self-Issued Identifiers

Self-issued identifiers are created and controlled directly by an entity, without relying on a central registry. UNTP adopts the W3C Decentralized Identifier (DID) Core specification, which defines the syntax, resolution process, and governance model for DIDs.

Discoverable

• A DID string (e.g., did:example: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:web:mycompany.example.
• NFC tag with an embedded DID.
• Invoice document with a DID for the issuing organization in its metadata.

Outcome: Discovery provides the DID string, which is globally unique and method-specific.

Resolvable

• Resolution is performed according to the DID method specification (e.g., did:web, did:key, did:ion).
• 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.

From a DID to IDR linkset

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. In the case of did:web, the resolution works by replacing ":" with "/" and appending "did.json".

• DID: did:web:sample-company.example:products:123456789 is an example of a product identifier using the did:web scheme
• URL: https://sample-company.example/products/123456789/did.json would be the URL of the DID document according to did:web 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:web:sample-company.example:products:123456789",
  "..other did document properties ..",
  "service": [{
    "id":"did:web:sample-company.example:products:123456789#untp:dpp",
    "type": "untp:dpp", 
    "serviceEndpoint": {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang":["en"],
          "type": "application/vc+jwt"
     }
  }, {
    "id":"did:web:sample-company.example:products:123456789#untp:idr",
    "type": "linkset", 
    "serviceEndpoint": {
          "href": "https://resolver.sample-company.example/products/123456789",
          "title": "Identity Resolver Service",
          "type": "application/linkset+json"
     }
  }]
}

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.

Outcome: Resolution yields a DID Document plus service endpoints, enabling consistent retrieval of resources.

Decentralised Identifiers (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 the DID method did:web 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.

Apart from the CRUD operations, the DID method also defines the secure ledger where the DID document is stored and can be discovered. In did:web the DID Doc is stored on the web domain in the /.well-known folder.

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 did:web - is a combination of three elements: 1. The DID Method (here did:web), 2. the Economic Operator domain that places the product on the market and where the DID document can be found in the /.well-known folder of that domain, 3. the product identifier unique to that domain.
• 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.io
DID Method	Method part of the DID – defined CRUD rules	did:web
Economic Operator domain	Domain that is under the control of the economic operator and that hosts the DID document	abc.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:web:abc.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.io/did:web:abc.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.

Verifiable

Self-issued identifiers support verifiability through cryptographic proof of control. The DID Document expresses service endpoints and verification methods, enabling clients to assess whether linked resources are controlled by the DID controller.

See Verifiable (shared) for verification process details. This differs from registry-managed verification which relies on registry governance.

Examples:

• A farmer issues a DPP under did:web:farm.example. Verification ensures that the DPP is signed with a key published in the DID Document hosted on farm.example.
• A certifier issues a sustainability credential about the same DID subject. Verification ensures the credential is signed by the certifier’s DID.

Outcome: Verifiability comes from cryptographic control, with no dependence on a central registry.

Example

1. A facility issues a DID for a machine it operates:
   • Example: did:example:abc123.
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.

Registry-Managed and Self-Issued Example Comparison

Both identifier classes and example workflows demonstrate the same UNTP principle: given an identifier, verifiable data about the identified thing can be discovered, resolved, and trusted. The key difference lies in that registry-managed identifiers rely on institutional authority, while self-issued identifiers (such as DIDs) rely on cryptographic control by the identifier holder. In both cases, implementations must still meet the UNTP requirements of being Unique, Discoverable, Resolvable, and Verifiable.

Step	Registry-Managed Identifier	Self-Issued Identifier (DID)
1. Identifier assignment	Allocated/recognized by an authoritative register (e.g., business registry, product catalogue).	Created by the entity itself using a DID method (e.g., did:example:abc123).
2. Resolution start	Scanner/system maps ID → resolver URL using scheme rules (registry templates, ISO/IEC 18975).	DID string is resolved per DID method → returns DID Document.
3. Resource discovery	Resolver URL returns a linkset with typed links (DPP, DCC, manuals, etc.).	DID Document contains service endpoints → may return linksets with typed links.
4. Verification	Trust anchored in the registry (issuance + authorization rules).	Trust anchored in cryptographic keys inside the DID Document.
Responsibility	Registry defines issuance rules and authorizes link additions.	DID controller manages resolution endpoints and ensures data availability.

Verifiable (shared)

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. untp:dpp, untp: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.

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 validated independently using the mechanisms defined in the UNTP Verifiable Credential Profile. For identifier-specific verification processes, see the Verifiable sections for Registry-Managed and Self-Issued implementations.

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.

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
IDR-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.	Linked Data Needs
IDR-02	One carrier, many links	One data carrier on a physical product or asset MUST be able to reference any amount of linked data or documents so that user or system confusion from multiple carriers on products can be avoided	Identity resolver services
IDR-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.
IDR-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
IDR-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	The Conceptual model - either create a resolver query from an 1D barcode / 2D matrix or embed the query into a QR.
IDR-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	Identity resolver services
IDR-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
IDR-08	Responsive links	Resolvers SHOULD leverage available user information such as language preferences to return tailored link-sets and default links - so that user experience is optimised.	Defaults and Automatically returning the right language
IDR-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.
IDR-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
IDR-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
IDR-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.	Decentralised Identifiers and DID to IDR linkset
IDR-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.

Linked Data Needs

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://example.com/01/733240226591
  • https://example.com/01/733240226591/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.

Note: DIDs are covered in detail in the Self-Issued Identifiers section above, including specific DID methods, resolution processes, and implementation examples. For identifier representation conventions that apply to all identifier types, see the URN, URL, and UUID sections above.