Verifiable Credential Status Over Time

Superceded

This document was constrained to a solution space given by the UNTP Specification 0.7

A revised consideration of how best to solve this design challenge has been developed, here

Introduction

The aim of this document is to explore how the elements defined in the UNTP specification1 can be used to satisfy both current and historical questions about issued credentials.

The origin of this document was a discussion on life cycle management for accreditation credentials issued by accreditation bodies to testing facilities (e.g. labs). This discussion gave rise to the general observation and the belief that the design principles presented here can be applied to other types of credentials and other contexts.

Of particular interest are how might we use the UNTP specification (which contains specifications for verifiable credential data structures as well as use case models for their use, discovery, resolution, and verification) to answer questions like:

  • “was product X tested to standards Y by a lab accredited to test them, in year Z?”
  • “was organisation X registered by an authoritative registrar of country Y in year Z?”

Example

Taking our lab based example, we can build a supply chain use case as follows:

  1. In Year-01, An Accreditation Body (AB) accredits a testing facility (TF). TF is a lab that performs steel testing. The accreditation has a unique reference, “AC1”.
    In UNTP terms, the accreditation is issued as a Digital Identity Anchor (DIA)

  2. In Year-02, A Steel Manufacturer (SM) makes a green steel product, GREEN001, and gets a batch tested by the Testing Facility (TF). The Testing Facility issues a (positive) conformity assessment (CA1) for GREEN001 against criteria that they are accredited to test against and that are applicable for GREEN001’s intended use as a reinforced steel used in building.
    In UNTP terms, the conformity assessment is issued as a Digital Conformity Credential (DCC).

  3. In Year-03, the Steel Manufacturer sells a batch of the tested GREEN001 steel product to a customer, a prime contractor (PC) that uses it to build an office block (B1).
    In UNTP terms, a Digital Product Passport (DPP) would be issued and would be referenced in the delivery documentation and (possibly) through on-product labelling (e.g. QR code).

  4. In Year-10 the Testing Facility changes business models and switches away from testing this type of steel. Its AC1 accreditation is withdrawn voluntarily and it applies, successfully, for new accreditation, AC2, in Year-11.
    This is the step we want to explore in this document in terms of UNTP use patterns.

  5. In Year-14, a new building inspector wants to know whether the building (B1) can genuinely claim its “green” status. They want to know: “Was the steel used in this building a certified green steel. If so, who certified it, to what standards, and were they accredited for that certification by a recognised accreditation body 11 YEARS AGO.
    This is the query that we want to be able to answer using the approach we define in the previous step.

If we consider these two accreditation certificates to be “AC1” and “AC2”, and we make Year-01 equal “2012”, we might draw a timeline as shown below:


gantt
    title Accreditation Credentials Timeline
    dateFormat YYYY-MM-DD
    AC1 Active:ac1a, 2011-01-01, 2021-12-31
    AC1 Withdrawn: ac1w, after ac1a, 2026-12-31 
    Assessment: as1, after ac1a, 60d
    AC2 Active:ac2a, after as1, 2026-12-31
    Steel Tested :milestone, 2012-01-01, 0d
    Steel Sold : milestone, 2013-01-01, 0d
    Office Block Completed : milestone, 2015-01-01, 0d 
    TF Changes Model : milestone, 2022-01-01,0d
    Building Inspection: milestone, 2026-01-01,0d

This use case is reasonably common in the building sector. Changes to regulations and/or sales and transfer of ownership can mean that a building inspector needs to know what materials used and how the building was constructed. If the building records are uncertain or incomplete when changes in regulations occur (say), then the current practice is to explore these questions through a human expert led and supported initiative. Authoritative institutions and people are asked questions and evidence in the form of paper documents is gathered.

There are many other such instances of historical query. For example, the forensic analysis of product failures after they have been in the market and in use for a period of time would demand knowing who produced the product(s) with what materials and who performed the tests and to what standards.

Revisiting our question we can use more general terms: we want to explore whether, using UNTP, we can enable a trustworthy, transparent, verifiable history. We want the UNTP verifiable credentials to provide the same or greater confidence as the human expert response based on archival records. We want the result to be supported by cryptographically protected records issued by the authoritative body and, to the extent possible, the results be algorithmically determinable.

Prior work - Conformity Exchange

Section 4.2 of the UN/CEFACT white paper on conformity exchange2 “Management of conformity lifecycle” proposes that “Digitalising status information in the context of conformity attestations warrants further investigation”. It further proposes that

Regardless, one important principle when dealing with management of conformity data lifecycle is that the issuer of the attestation be recognised as retaining authority over the attestation, in order to provide certainty over the state (e.g., withdrawal, amendment, expiry) of an attestation over its valid lifetime.

Section 6.5.6 of the UN/CEFACT Business Requirements Specification (BRS) “Digital Product Conformity Certificate Exchange”3 discusses Attestation Status. However this section does not discuss how to manage changes and present historic time-based values.

Annex 5 of the BRS contains a life cycle diagram as a state transition diagram. The diagram is reproduced below showing each state and the transitions between them:

---
config:
   layout: elk
title: State Transition Diagram for Accreditations
---
stateDiagram-v2
  direction TB
  %% define states
  C: Current
  S: Suspended
  X: Expired
  W: Withdrawn

  %% transitions
  [*] --> C:Accreditation requirements met
  C --> C : Periodic recheck
  C --> S : Requirements</br>not met
  C --> W : No longer valid (e.g. replacement version issued)
  C --> X : For time-limited attestations only
  S --> C : Requirements</br>met
  S --> W : Failure to resolve suspension
  X --> W : Based on CAB policies or <br/>if otherwise rendered historically invalid
  W --> [*]

If we consider that we are in the year 2026, and we take our example use case, the AC1 credential issued 11 years ago goes from Current to Withdrawn 4 years ago when the certificate became no longer valid as the lab no longer performs the same tests on steel. However, at no time (in our example) is the certificate in a Suspended state.

We have two types of problem to solve:

  1. Current only Presentation: The operating practice of Accreditation Bodies is to display the current state of credentials. So in 2026, the status of AC1 would be withdrawn and AC2 would be current. Further, the information presented may be limited to just the current state, the date on which that state was registered, and the original issued date. This presentation would mean that it is not possible to determine when any previous state changes ocurred and for how long the accreditation was in that state.

  2. Limited Records Kept: Issuers of records may not keep a full record of all things they have ever issued. For example, accreditation bodies do not display, nor be legally obliged to keep, the full history of all accreditations ever issued. An issuer might only store the statutory (legally) specified range of history (7 years say), and may choose to only present a subset of this history, the last 5 years (say) for searches.

UNTP Elements

This conversation focuses on the Digital Identity Anchor from the UNTP specification, but can be generalised to all UNTP credentials (and possibly all VCs).

The UNTP credential identified for use as an Accreditation Credential is the Digital Identity Anchor4. This can be used in the following way: a national accreditation body recognises (“accredits”) an organisation that passes required tests (demonstrated required capabilities) as a Conformity Assessment Body (CAB) by issuing a DIA. The recognised (accredited) Conformity Assessment Body (CAB) would then issue UNTP Conformancy Credentials5 to those organisations who meet the required conformity standards for the credential to be issued.

The Digital Identity Anchor and Conformity Credential contain the same key elements needed for this discussion:

  • validFrom
  • validUntil
  • credentialStatus

The validFrom and validUntil fields are date fields. UNTP does not require either field to contain a value (they are not mandatory). The use of these fields is defined by the Issuer’s standard operating practice on issuing a Credential.

A common use pattern is that the value of the validFrom field is set to the date on which accreditation is recognised, and the validUntil field is left blank (or “null”) as the recognition does not have a preset expiry date.

The credentialStatus field uses the W3C VC bitStringStatus approach to managing credential status. We’ll explore that in the next section and then return to the validFrom and validUntil fields.

W3C VC status representation

The bitStringStatus field is a standard W3C Verifiable Credential Data Model construct6. The controlling specification for the use of the bitStringStatusList when this paper was written is “Bitstring Status List v1.0, Privacy-preserving status information for Verifiable Credentials” W3C Recommendation 15 May 2025: https://www.w3.org/TR/vc-bitstring-status-list/.

Most implementations of the W3C VC Data Model use a single-bit status allowing a binary value to be represented (on/off, valid/not valid, revoked/active etc.). The W3C standard allows for more than one bit to be used to represent the status of each issued credential by setting the statusSize value greater than 1. If the statusSize attribute is set to a value greater than 1 then the property credentialStatus.statusMessage MUST also be present and the number of status messages MUST equal the number of possible values. In other words, we can have more than a binary value for status, but if we do, we must define what each value means.

For example, if we set statusSize to 2 bits for the status we get 4 possible states. So, we could have:

Binary (2 bits) Hex Value Accreditation State and example cause
00 0x0 Active (The initially awarded state)
01 0x1 Suspended (Temporarily invalid)
10 0x2 Withdrawn (Lab chose to end accreditation)
11 0x3 Cancelled (NATA forcibly removed accreditation)

This could be represented by a credentialStatus.statusMessage array as shown below (ignoring the explanation for each state provided above):

[
  {
    "status": "0x0",
    "message": "Active"
  },
  {
    "status": "0x1",
    "message": "Suspended"
  },
  {
    "status": "0x2",
    "message": "Withdrawn"
  },
  {
    "status": "0x3",
    "message": "Cancelled"
  }
]

The bitStringStatus is designed to enable revocation by the issuer without altering the content of the VC. A typical instance given of its use is the temporary suspension of something like a driving licence which might in a future date be reinstated. With a driving licence we are usually interested in whether the driver of a car is licenced to drive the car they are driving now - not whether they were licenced last month.

This means that the bitStringStatus is designed to solve a “now” query - what is the status of this credential now? It is not intended to answer the question: “what was the status of this credential at a point in time?”

The bitStringStatus cannot answer this question since changing its value to reflect current status does not automatically leave a trail of evidence for historical queries.

We could use the bitStringStatus for two main purposes:

  1. As a temporary status change for the current version of a credential where we expect the status might toggle and we need an immediate response to a change of status.
  2. As a permanent whole of lifetime change for an historically issued credential that has been deemed to be wrongly issued after the fact.

This can be useful applications, but we need to explore other methods to achieve our verifiable history.

Validity Periods: from and until

Returning to our use pattern for the validFrom and validUntil fields we might be tempted to update the validUntil field to specify a time bound limit for a credential that we have previously issued and that we now know has a specific end date. This is technically possible because, in the UNTP model, the “issuer” retains control of the VC (keeps the record within their own controlled space rather than sending (issuing) it a remote “Holder” wallet outside of their control). Changing and re-signing is technically possible, but it is not recommended.

The expected practice and use of verifiable credentials is that they are immutable records once issued. This reflects their usual use pattern where they are issued to a wallet under the control of the holder and the issuer has control over the wallet content.

Changing the content of a VC and resigning it breaks the W3C VC expectation that VCs are immutable records and means that the signature value, while valid for the new content and the key used, has changed. Such changes could impact cached records and cause red-flags for observant verifiers. As a side note, editing the verifiable credential also makes the digital experience differ from the existing physical experience when a physical (or PDF) copy of an accreditation credential would be sent to a Facility with the issue date and no expiry date. This would then be stored by the Facility and becomes, to an extent, an immutable record.

Basically, if we issued the credential with a blank validUntil field, it should stay blank.

The good news is that we don’t need to edit and re-sign previously issued credentials, there are better design patterns to use. In fact the UNTP specification has something that we can use that will provide the capability we want and adhere to the best practice of W3C VC use and mirror the existing physical world pattern.

UNTP Identity Resolver

The “Identity Resolver” (IDR) is a part of the UNTP Specification7. An identity resolver is a web-based service that accepts a machine-readable identifier (like a barcode, QR code, URL, or decentralised identifier (DID)) and returns the data associated with it as a linked list of one or more records.

That means it “resolves” (or redirects) using the identifier value as an address to retrieve structured links to authoritative data sources. This enables mirrors existing systems, from handheld scanners to compliance platforms, to retrieve context-specific information for traceability, certification, regulatory reporting and more.

An identity resolver is not a registry or primary data store. It acts as a routing and resolution layer that connects identifiers to the systems or authorities that hold the relevant data.

The IDR enables the UNTP discover → resolve → verify workflow by returning verifiable data about the product, component, or facility associated with a given identifier. UNTP-aligned resolvers must support both:

  • Registry-managed identifiers (e.g. Accreditation References, GTINs or location codes etc. assigned by authorities)
  • Self-assigned identifiers, such as DIDs (Decentralised Identifiers) controlled by the entity itself

This is the enabling capability of the UNTP IDR specification: it supports version history8. We can see an example in the UNTP specification at version 0.7.0 which considers a Digital Product Passport, but the IDR approach will work for all UNTP credentials.

Returning to our use case above, this means that a query on the Accreditation held by the Testing Facility (TF) will return the current credential (AC2) and, if requested, the full linked history of previous credentials, including AC1.

Expanding on this logic further. In the context of Accreditations, “Suspended” or “Withdrawn” are explicit legal changes, and we must cryptographically sign any new statement. We cannot represent a suspension simply by deleting the old VC; we must issue a new record where the credentialSubject.status value equals suspended.

We can explore how this might work from an algorithmic test point of view.

When a verifier queries the Identity Resolver (IDR) for historical date T_query, the resolver must execute a “Latest-Before” optimization logic test as follows:

  1. Gather the complete collection of VCs issued by the Accreditation Body for the specific Facility identifier: completeSet

  2. Filter the collection to include only VCs that are issued before our query date, so
    filteredSet _= completeSet where completeSet.validFrom <= T_query_

  3. From that filtered subset, select the single VC that possesses the maximum validFrom timestamp:
    targetVC = max {filteredSet.validFrom}

The returned credential is the most recent one that was current at T_query, the time of interest for our query.

Conclusion - all states considered

The following is proposed:

  1. Use the credentialStatus as a single binary value with two possible states: active and revoked and only for the two use cases:
    1. Recommended: temporary current credential changes, and
    2. Optional: whole of life status value setting for historical corrections. This use would require governance and documentation

  2. Do not delete or edit issued credentials.

  3. Issue a new credential whenever a change of status occurs. Note that this logically will occur whenever the credentialStatus changes as well as if any other status change occurs. The credentialStatus allows for a rapid “valid now?” query but doesn’t support historical record management.

  4. Support verifiers who need to know past values by using the UNTP IDR to generate a linkset of previous credentials.

Appendix A - Possible future integration with TRQP?

This section considers the possibility of using “TRQP” with UNTP. Consider it a thought experiment…

TRQP is the “Trust Registry Query Protocol”9. It is a specification developed by the Trust Over IP project within the Linux Decentralized Trust Foundation1. Quoting from the TRQP introduction:

TRQP focuses on two query types:

  1. Authorization Queries: “Has Authority A authorized Entity B to take Action X on Resource Y?”
  2. Recognition Queries: “Does Authority X recognize Entity B as an authority to authorize taking Action X on Resource Y?”

Our question at the beginning of this document “was product X tested to standards Y by a lab accredited to test them in year Z?” can be seen to be very similar to the type of questions that TRQP seeks to address. TRQP as a concept can also be seen to have applicability to the UN/CEFACT GRID project, which focuses on Authoritative Registrars and their Registers. For now, we’ll stick with our credential status life cycle focus.

So might we consider using the Trust over IP (ToIP) Trust Registry Query Protocol (TRQP / TQRP) v2.010 with UNTP? Would that be a good addition?

TRQP describes itself as the “DNS for digital trust,”. It is designed as a lightweight, read-only query protocol that enables queries across heterogeneous governance models using a standard protocol.

Bringing TRQP into the UNTP landscape can add value to our temporal discovery challenge.

TRQP v2.0 includes an Extensibility Context Object. The specification states that if a context object needs to express a time-based condition, it MUST use a standardized time parameter formatted to RFC 3339.

This means that instead of a bespoke processing on the IDR response, a time-based query routed via TRQP looks like this:

{
  "query_type": "authorization",
  "authority_id": "did:example:national-registrar",
  "entity_id": "did:example:enterprise-x",
  "action": "transact",
  "resource": "eu-border-clearance",
  "context": {
    "time": "2016-07-17T11:26:25Z"
  }
}

The TRQP endpoint processes the query, evaluates the historical states (interacting with the UNTP IDR log layer), and returns a standardized trust status (authorized, not_authorized, say) for the requested moment in time.

How UNTP IDR and TRQP Might Coexist

TRQP would not replace the UNTP Identity Resolver (IDR) or the core Digital Identity Anchor (DIA) structures; rather, it would act as an API interoperability surface wrapped around them.

The diagram below shows how the flow could work.

---
config:
  layout: elk
title: UNTP IDR and TRQP
---
flowchart TD
    A["Int'l Verifier"] -->|"1. Sends TRQP Query<br/>(e.g., 'Authorized at T_query?')"| B["Local TRQP Endpoint (NATA)"]
    
    subgraph Translation ["Local TRQP Translation Engine"]
        B --> C["2. Parses Custom History<br/>('Latest-Before' Logic)"]
        C --> D["3. Evaluates VC terms based on local legal logic"]
        D --> E{"State active & valid<br/>at T_query?"}
    end
    
    E -->|"Yes (e.g., 'Active')"| F["Map to: 'authorized'"]
    E -->|"No (e.g., 'Voluntary Pause', 'Suspended')"| G["Map to: 'not_authorized'"]

    F -->|"4a. Returns Status: 'authorized'"| A
    G -->|"4b. Returns Status: 'not_authorized'"| A

Architectural Alignment

By implementing a UNTP Profile for TRQP, we can achieve additional benefits for UNTP users. TRQP can act as an alternative query path. External software platforms (like corporate ERPs, banks, and customs systems) do not need to understand the internal mechanics of the UNTP IDR or parse complex JSON schemas natively. They use a standard, read-only TRQP query to the registry surface. The registry uses its internal UNTP IDR routing infrastructure to evaluate immutable, issuer-controlled VCs over a historical graph timeline - returning a simple, safe, and cryptographically sound response.

  1. https://untp.unece.org/ ↩ ↩2

  2. https://unece.org/trade/documents/2024/07/session-documents/brs-digital-product-conformity-certificate-exchange-high ↩

  3. https://unece.org/sites/default/files/2024-07/BRS-DigitalProductConformityCertificateExchange.pdf ↩

  4. https://untp.unece.org/docs/specification/DigitalIdentityAnchor ↩

  5. https://untp.unece.org/docs/specification/ConformityCredential ↩

  6. https://www.w3.org/TR/vc-data-model-2.0/ ↩

  7. https://untp.unece.org/docs/specification/IdentityResolver, see also https://kb.pyx.io/docs/Development/idresolver/ ↩

  8. https://untp.unece.org/docs/specification/IdentityResolver#versioned-targets ↩

  9. https://trustoverip.org/ ↩

  10. https://trustoverip.github.io/tswg-trust-registry-protocol/approved/ ↩

This site uses Just the Docs, a documentation theme for Jekyll.