info

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

Durable Storage

Overview

Two questions come up again and again from UNTP implementers and policymakers.

The first is asked by publishers:

"What happens to a Digital Product Passport or conformity credential when the organisation that issued it goes out of business?"

The second is asked by receivers, the businesses further down the supply chain:

"My upstream suppliers have no legal obligation to keep their credentials available for decades. I do. How do I keep the evidence I relied on, and how do I show later that it was valid when I relied on it?"

This page answers each question from that party's side:

• Part 1: If you publish credentials covers keeping your own credentials available after you, or your hosting provider, have gone.
• Part 2: If you receive upstream credentials covers keeping copies of the upstream credentials and graphs you relied on.
• Limits of copies explains what a copy can and cannot prove. These limits apply to both parts.

The guidance applies to all UNTP credential types:

• Digital Product Passports (DPP)
• Digital Conformity Credentials (DCC)
• Digital Traceability Events (DTE)
• Digital Facility Records (DFR)
• Digital Identity Anchors (DIA)

---

Why durable storage is hard

UNTP credentials carry sustainability, traceability, and conformity claims that may need to stay verifiable for the life of a product, facility, or business. That can be decades. The organisations that issue them have ordinary business lifecycles: they restructure, are acquired, become insolvent, or close. Their hosting providers can be discontinued or change hands too.

There are three separate concerns:

1. Availability: will the credential still be retrievable after the issuer is gone?
2. Integrity: can a verifier tell that the content at an address has not been altered or replaced?
3. Economic sustainability: who pays for storage once the original publisher no longer exists?

A credential is also only verifiable alongside the material it depends on: the issuer's DID document, the status list, and the JSON-LD contexts. These often live on different hosts from the credential itself. Keeping the credential but losing its DID document leaves bytes that can no longer be checked in the usual way. See Verification dependency closure.

No technical approach guarantees indefinite longevity. Every option, including blockchains and decentralised storage networks, ultimately runs on computers that someone can switch off. The practical answer is redundancy: more than one copy, held by more than one party, with enough information to check each copy independently.

---

Part 1: If you publish credentials

This part is for issuers: manufacturers, certifiers, conformity assessment bodies, registrars, and anyone else whose signature is on a UNTP credential.

Plan for your own closure

The most effective durability measure is a plan made while the business is still operating:

• Contract for retention, not just hosting. Hosting agreements typically end when payments stop. Where credentials need to outlive the business, agree a retention term in advance, or choose storage that is paid up front (see Storage maturity levels).
• Name a successor. Decide who takes over your credentials, domain, and keys if you are acquired or close. That might be an acquirer, an industry body, a scheme owner, or a regulator. Record the arrangement somewhere it will be found.
• Follow any applicable register obligations. Some jurisdictions require a copy of passports or certificates to be lodged with a central or backup register. Where that applies, the register's rules govern. See Guidance for policymakers and regulators for designs that keep such a register from becoming the only copy.
• Treat online assets as transferable. A domain dedicated to a brand or product line can be sold with that brand. If your DIDs and Identity Resolver live on that domain, they survive the sale, and the credentials issued under them stay resolvable for the new owner.

Keep your verification material available

A credential that is still online but whose DID document has gone cannot be verified in the usual way. When you plan durable storage, plan it for:

• the credential itself, as the exact signed bytes;
• the DID document versions, or did:webvh log, used to sign it;
• the Bitstring Status List credential it references;
• the JSON-LD @context files used at issuance.

The Verifiable Credentials profile already asks issuers of long-lived credentials to keep this material retrievable for the credential's intended lifetime. This page describes ways to do that. It does not add to that requirement.

Choose identifiers that survive change

The Verifiable Credentials profile recommends did:web and did:webvh. Both resolve over DNS and HTTPS, so both are affected when a domain lapses. They differ in what survives:

• A did:web document is not signed. Its authority comes entirely from the domain it is served from. If the domain lapses and is registered by someone else, the new owner can publish different keys under the same DID.
• A did:webvh log can be checked independently of the domain. Each entry is signed by a key authorised in the previous entry, and the DID itself contains a hash of the first entry. A new domain owner cannot extend the log without the update keys. The log can also move to a new domain without becoming a new identifier.

For issuers whose credentials need to last, did:webvh on a domain you expect to keep (or transfer) is the more durable choice. See Copies do not make an unreachable DID trustworthy for what each method means for a receiver holding a copy.

Back up and hand over keys

Losing a signing key does not invalidate credentials already issued, but it stops you rotating keys or updating a did:webvh log. Keep an offline backup of your update and signing keys. Include key handover in the successor arrangement above. Private keys are never part of any published, mirrored, or archived copy of verification material.

Storage maturity levels

Implementers have different capabilities and risk tolerances. The following levels help publishers and policymakers compare approaches. They are not a conformance ladder.

Level 1 — Self-hosted (baseline)

The publisher hosts credentials on its own infrastructure (web server, cloud storage bucket, and so on).

Property	Assessment
Post-issuer availability	❌ Credentials will likely become unavailable when the publisher ceases operations
Post-provider availability	❌ Dependent on the publisher's infrastructure and payment continuity
Tamper-evident integrity	⚠️ Dependent on credential signature only; URL content can be silently replaced
Cost	Low
Complexity	Low

Adequate for pilots and short-lived credentials. A poor fit for production passports that need to stay available for a product's full lifetime.

Level 2 — Managed commercial storage

The publisher uses a commercial cloud or managed hosting service with contractual terms for a defined retention period.

Property	Assessment
Post-issuer availability	⚠️ Dependent on contract terms and continued payment; likely fails when issuer ceases operations
Post-provider availability	⚠️ Major providers are relatively durable but operate on recurring payment models — credentials will be deleted if fees are not paid
Tamper-evident integrity	⚠️ Dependent on credential signature only unless content-addressable hosting is used
Cost	Low–Medium
Complexity	Low

Major cloud providers do not currently offer a "pay once, store forever" model. Credentials are deleted when payment stops, which typically happens when a business closes.

Level 3 — Content-addressable durable storage (example)

The publisher stores credentials in a content-addressable store, such as Filecoin, Arweave, or an archive that indexes the same digests.

Property	Assessment
Post-issuer availability	✅ Content remains accessible via any compatible gateway or archive copy, independent of the original publisher
Post-provider availability	✅ No single provider dependency when content is addressed by hash and served by more than one participant
Tamper-evident integrity	✅ The storage layer commits to a digest of the bytes, in addition to the VC's cryptographic signature
Cost	Varies (Arweave's one-time model is one option)
Complexity	Medium

A practical pattern for credentials that need to stay available for years or decades. It is not required for UNTP conformance.

Content-addressable storage

In a content-addressable store, the address of a credential is derived from a cryptographic hash of its content. A given address only ever refers to one specific document. Changing a single character produces a different address. Any party can serve the content, and anyone can check it against the address without trusting the server.

Conventional hosting is different. A URL like https://company.example/dpp/product-123.json is a pointer controlled by the domain owner, who can change or delete the content without anyone noticing.

Open protocols that illustrate the pattern include:

• IPFS: every object is identified by a content identifier (CID). Many independent pinning services and gateways exist, so content stays available if one goes offline, and publishers can change provider without changing the address. Content is reachable through ordinary HTTPS gateways.
• Filecoin: adds an economic incentive layer to IPFS. Storage providers are paid to prove they keep holding the data for a defined deal term. Deals are finite and need renewing or replicating, so Filecoin does not by itself provide permanent storage.
• Arweave: designed for permanent storage paid for once, up front, through an endowment model. Each transaction commits to a Merkle root of the data, so stored bytes can be checked. An Arweave transaction ID is not a content address in the IPFS sense: uploading the same bytes twice gives two different IDs.
• Other equivalent stores: a national archive, a regulator's register that indexes content-addressable identifiers, or a replicated object store with digest-addressed objects can serve the same role. The interoperable idea is the digest, not a particular network.

These are examples, not a closed list. Decentralised networks are not immune to failure either: they can lose participants, be abandoned, or become uneconomic.

Publishing steps (example)

A publisher following the Level 3 pattern might:

1. Issue the credential according to the relevant UNTP specification and sign it with the issuer's DID key.
2. Store the exact signed bytes in a content-addressable store or equivalent archive. Do not parse and re-serialise the credential: that changes the bytes and breaks the signature.
3. Record the identifier (CID, transaction ID, or digest) returned by the store.
4. Register the credential in the Identity Resolver link-set, with both an HTTPS gateway or archive URL and the native content-addressable URI (for example ipfs://<CID>), so verifiers can check integrity independently.
5. Store the verification material the same way: the DID document versions, the status list credential, and the @context files. Advertise their durable addresses in the same link-set using existing link relations such as the IANA related or describedby relations. This page does not define new ones.
6. Check retrievability through an independent gateway or archive copy before publishing the product identifier.

The Identity Resolver remains the discovery layer: it points to the current location and can be updated. The content-addressable URI is the fixed, tamper-evident reference to one version of the bytes. The resolver can disappear too; see Discovery when live resolution fails.

What to expect from a hosting platform

The technical guidance above assumes a hosting platform that behaves reasonably. That assumption is worth making explicit, both for publishers choosing a platform and for communities writing it into their own rules. A platform hosting UNTP credentials should:

• Publish its retention and termination terms, including what happens to hosted credentials when an account lapses, the platform changes hands, or the service is discontinued.
• Give reasonable notice before rendering hosted data inaccessible, for whatever reason — commercial, legal, or operational — so that publishers and downstream custodians can take copies.
• Support export of the exact signed bytes together with the verification material in this page's preservation package form, rather than a parsed or re-serialised rendering that breaks signatures.
• Never alter hosted credential bytes. Serving modified content from a registered URL is a conformance failure that the registrar agent will detect, not a presentation choice.

None of this transfers responsibility. Durability planning stays with the issuer — a hosting contract is one of the tools, not a substitute for the plan. Communities adopting UNTP can turn these expectations into binding terms at the level where they have teeth: membership rules, procurement conditions, or jurisdictional regulation.

Guidance for policymakers and regulators

Regulations modelled on the EU DPP often propose a centralised government backup register to cover publishers that close. Protocol-based or digest-indexed storage can be an alternative or a complement:

• Lower cost: no government infrastructure is needed to hold every credential body.
• Higher scalability: a register of identifiers scales without a single content bottleneck.
• Greater durability: no single operational or budget failure takes everything offline.
• Higher integrity: content-addressable storage is tamper-evident at the storage layer.
• Neutrality: no single government, company, or jurisdiction needs to control access to the stored data.

Where regulation requires a register, a useful design is an index of content-addressable identifiers pointing to credentials held in durable stores or archives, rather than a central store of credential content. The register gives a known inventory without being the only copy of the bytes.

UNTP does not expect every participant to preserve every upstream artefact. Jurisdictions and industry extensions can decide retention scope and who the authorised custodians are.

---

Part 2: If you receive upstream credentials

This part is for businesses that rely on credentials issued by others: brands, finished-product manufacturers, importers, and also regulators or archives acting on their behalf.

Why receivers keep their own copies

Consider a brand putting a pair of organic cotton jeans on the market. The organic claim on its passport depends on upstream evidence: an organic certificate for the cotton farm, traceability events from ginning through to weaving, and facility records along the way. The brand may be required to keep that evidence for the life of the product and to produce it in an audit years later.

The cotton farm and the ginnery may have no such obligation in their own jurisdictions. They may close, change systems, or simply stop paying for hosting. The obligation sits with the brand, so the brand cannot rely on upstream publishers to keep everything available.

The practical answer is for the receiver to keep its own copy of the upstream credentials it relied on, together with what is needed to check them later. In this role the receiver is a custodian: it preserves copies, but it does not become the issuer of the upstream claims.

Two points make this easier than it first appears:

• The credential that matters most is often issued by a party that lasts longer than the producer. The organic certificate is issued by a certification body, not by the farm. The farm closing does not, on its own, make the certificate unverifiable.
• Copies are cheap. A signed credential is a small file. The work is in keeping the right copies, with the right context, not in storage volume.

Downstream custodians

Keep four roles distinct:

Role	What it asserts
Original issuer claim	The signed credential as issued
Archived copy	The same signed bytes, possibly served from a new location
Custodian preservation	"I preserved these identified bytes" — not a new product claim
New downstream claim	A new credential the custodian issues about their own product or assessment

Preserve the exact signed representation. For the enveloping JOSE proof used by UNTP, that is the complete signed artefact (application/vc+jwt). Parsing and re-serialising does not preserve the original.

Byte-identical copies with the same digest are copies of the same artefact. No new credential is needed to prove their integrity. Where a record of custody matters, each custodian can sign a separate preservation package that refers to the objects and to any earlier manifest.

What to keep

For each upstream credential you rely on, keep:

• the credential, as the exact signed bytes;
• the material needed to verify it (see Verification dependency closure);
• a record of when and from where you retrieved each item;
• a record of the checks you ran on receipt and their results (see The receipt-time verification record).

Keep these for upstream evidence that a claim on your own passport depends on, not for every credential you have ever seen.

Verification dependency closure

A credential retrieved from a durable address still cannot be re-verified unless the rest of the verification material is also available. Depending on the methods in use, that closure may include:

• Linked UNTP credentials (DCC, DFR, DTE, DIA, further DPPs)
• DID documents and verifiable DID history (for example a did:webvh log)
• Identity Resolver linksets
• Credential status information (for example a Bitstring Status List credential)
• JSON-LD contexts, schemas, and vocabularies
• Trust-chain credentials (accreditation DIAs, scheme credentials)
• Detached proofs or other public verification material

Keeping this material makes later checks possible. It does not make them conclusive. A copied DID document and a copied status list each carry limits that are explained under Limits of copies.

Mirrors and caches of DID documents and status lists, with a recorded retrieval time, are a practical pattern when the original host is temporarily or permanently unavailable. They are not a substitute for a standardised timestamp or witness profile, which does not yet exist.

The receipt-time verification record

Live verification answers "does this credential verify now?". An audit asks a different question: "was it valid when you relied on it?". Only a record made at the time can help answer the second.

When you receive upstream evidence, consider keeping:

1. the exact signed credentials;
2. the DID documents or did:webvh logs as retrieved;
3. the status list credentials as retrieved;
4. the retrieval time and source of each;
5. the result of each check you ran: signature, status, validity period, and any graph rules you applied;
6. optionally, an independent timestamp over a digest of the whole record, for example an RFC 3161 timestamp token from a timestamp authority.

The timestamp is what turns "I say I had this" into "an independent party confirms these exact bytes existed no later than this time". See Copies do not prove status at a point in time for what the record can and cannot show even then.

This record belongs to the relying party. It is not a new UNTP credential type, and it is not written into the transparency graph.

Linking to your copy from your passport

A brand can link from its own passport to the archived copy of the upstream evidence, so a later verifier still has somewhere to go if the original host has gone. UNTP's existing Link structure is enough. Point linkURL at your archived copy, and set digestMultibase to the digest of the exact signed bytes:

"evidence": [
  {
    "linkURL": "https://archive.denim-brand.example/evidence/organic-cotton-certificate-2026.jwt",
    "linkName": "Organic cotton certificate (archived copy)",
    "linkType": "https://test.uncefact.org/vocabulary/link-type/dcc",
    "mediaType": "application/vc+jwt",
    "digestMultibase": "uEiD..."
  }
]

Linking to a copy does not make the brand the issuer of the certificate. The certificate is still signed by the certification body, and a verifier checks that signature as usual. The digest lets the verifier confirm that the file it received is the one the brand linked to. Where the original location is still live, linking to both the original and the copy gives verifiers a choice.

Legal authority to copy

Being able to copy an artefact does not give you the legal right to copy or disclose it. Confidential, personal, licensed, export-controlled, or trade-secret information may need consent, a statutory basis, contractual permission, or an approved archive. Agreeing evidence-access terms with suppliers before credentials are issued (who holds primary records, for how long, and who responds when a claim is challenged) avoids most of these questions later.

Encrypted artefacts can be kept without disclosing their plaintext. Packages contain only public verification material and never private signing keys.

Personal data and the right to erasure

Durability and erasure pull in opposite directions. Storage designed so that content "cannot be deleted or altered" cannot honour a later erasure request, and a content-addressable copy served by many independent parties cannot be recalled by the original publisher. Where a credential or its dependencies may contain personal data, assume that permanence is a commitment that cannot be withdrawn, and prefer:

• keeping personal data out of durably stored credentials in the first place;
• storing only encrypted payloads durably, so that destroying the key limits future access even where bytes persist; or
• using an archive with a defined retention and deletion policy instead of an irrevocable store.

How an indefinite retention obligation sits next to a statutory erasure right is for the applicable jurisdiction, and for a later profile or extension if UNTP needs a common rule.

Custody of decryption keys

Preserving bytes is not the same as preserving access. Under Decentralised Access Control, confidential payloads are encrypted with a unique key per item, and the data holder distributes the keys. If that data holder ceases to exist, preserved ciphertext is readable by nobody: the artefacts survive, but the ability to decrypt them does not.

Treat key survival as a governance arrangement for now, with a custodian, regulator, or escrow agent named in advance, rather than something the storage layer provides. Formal key custody, escrow, and post-issuer key release (including the Durability design requirement for confidential data) are on the roadmap.

Preservation package

This is an illustrative pattern, not a schema and not a UNTP requirement. A machine-readable manifest can list each artefact in a preserved graph so that another custodian or a verifier can check completeness.

Useful fields on a manifest:

• The custodian's identifier and a signature that covers only preservation of the listed bytes, not the truth of their contents
• Package scope (for example "upstream of this finished-product DPP")
• Completeness: complete, partial, or unknown
• For each artefact: media type, digest (digestSRI, as used by VCDM 2.0 relatedResource) and/or content-addressable identifier, original identifier and location when known, source, retrieval time, and role in the dependency closure
• An optional parent manifest, for copies made from another custodian's copy
• Dependencies the custodian could not obtain

A custodian may preserve a package received from another custodian. Detect cycles (do not follow a parent that is already in the chain), de-duplicate by digest, and set a traversal limit so that walking the graph always terminates.

A sketched instance is in manifest.json. In that sample each contentId is a CIDv1 whose embedded digest matches the sibling digestSRI, so the two identifiers can be checked against each other.

A verifier using a package typically:

1. Checks object digests against the manifest
2. Verifies original issuer signatures on the preserved bytes
3. Applies DID versions and status as far as the package allows, and reports gaps
4. Distinguishes original claim, archived copy, custodian assertion, and any new downstream claim
5. Reports whether the preserved graph is complete, partial, unknown, or invalid

Discovery when live resolution fails

While the original Identity Resolver is available, verifiers discover credentials from the product or facility identifier as usual. Content-addressable URIs in the link-set serve as integrity checks and alternate locations.

When that resolver or host is gone:

1. A verifier who already has a preservation package walks the artefacts listed in its manifest.
2. A downstream passport, or a resolver that is still operating, may publish ordinary links to archived copies or to a preservation package (see Linking to your copy from your passport). This page does not define new linkType values.
3. Cached or mirrored DID documents and status lists in the package stand in for live resolution, with the limits described under Limits of copies.

This addresses, informatively, the archival question that Accumulating Linked Data carries as an open roadmap item. It does not close that item.

---

Limits of copies

Keeping copies is necessary, but a copy cannot prove everything the live system could. Two limits matter most, and neither has a standard solution yet in UNTP or in the wider verifiable credentials ecosystem.

Copies do not make an unreachable DID trustworthy

Verifying a UNTP credential means checking its signature against a public key from the issuer's DID document. If you kept a copy of the DID document, you still have the key, and the signature will still check out years later. The cryptography is not the problem.

What a copy loses is the reason to believe that key belonged to the issuer. Normally that reason comes from resolving the DID live. Once the DID can no longer be resolved, the copy has to carry that trust on its own, and how well it can depends on the DID method.

did:web. A did:web document is not signed. Its authority comes entirely from being fetched over DNS and HTTPS from the issuer's domain at that moment. HTTPS does not leave behind any proof of what the server sent that you could show to someone else. A saved did.json is therefore a file the custodian says they downloaded. Anyone could produce one containing a key of their own choosing. A verifier relying on it is trusting the custodian, not the issuer.

There is a second risk. When a domain lapses, someone else can register it and publish a new did.json with different keys. Live resolution then returns the new owner's keys, and the old copy is more trustworthy than the live answer, yet neither can show on its own which is genuine.

did:webvh. A did:webvh log is much stronger as a copy. The DID contains a hash of the first log entry, and each later entry is signed by a key authorised in the entry before it. A saved log can be checked offline back to the DID itself, without the domain, and a later owner of the domain cannot extend it without the update keys. Two gaps remain:

• A copy cannot prove it is the latest version of the log. A later key rotation or deactivation may exist that the custodian never saw. The method's optional witnesses help with this, but they are live services too.
• Standard resolvers fetch DID documents from the network. Checking against a saved copy needs verifier software that is configured to use it.

For any DID method: keys compromised later. A signing key that was retired may later be compromised, for example when a closed company's servers are sold, or in future through advances in cryptanalysis. Whoever holds it can sign a new credential, backdate its dates, and it will verify against the saved DID document. Only independent evidence that you held those exact bytes before the compromise defends against this, which is why the receipt-time verification record includes an optional independent timestamp.

What this means in practice. A verifier checking against a preserved DID document, rather than a live one, should say so in its result. For example: "signature verified against a DID log preserved by custodian at time", rather than simply "verified". Prefer did:webvh copies to did:web copies, and keep an independent timestamp where the evidence matters.

Copies do not prove status at a point in time

The question a receiver usually needs to answer is: "When I received the cotton, the certificate was valid. It may have been revoked since, but it was valid then." A copied status list helps, but it cannot fully prove this, for three reasons.

1. A copy of a status list is authentic, but its time is weak. A Bitstring Status List credential is signed by the issuer, so a saved copy does prove that the issuer said "entry N is not revoked". But its validFrom date is the issuer's own claim, the field is optional, and issuers republish the list under the same identifier as entries change. A copy fetched long before the cotton arrived cannot be told apart from one fetched on the day it arrived. Nothing in the copy ties it to the moment of receipt.

2. A copy cannot prove it was the latest version. Even if you did fetch the list on the day, the issuer might already have published a revocation that you did not see, for example because of caching or the list's time-to-live.

3. Status lists do not record when or why. The Bitstring Status List has no revocation date and no reason. Revocation means "do not rely on this from now on". A later revocation does not tell you whether the certificate lapsed after you received the cotton, or was obtained fraudulently from the start, in which case it was never really valid.

What you can do today. The receipt-time verification record is the best available evidence. With an independent timestamp, it shows that by a given time you held an issuer-signed status list saying the certificate was not revoked. That is strong evidence, but it is not proof that the list was the latest one.

Timestamps also age. Timestamp authority certificates expire and algorithms weaken over time. The electronic signature community handles this by renewing timestamps periodically, for example with RFC 4998 evidence records. A future UNTP profile is likely to draw on that work rather than invent its own.

A useful framing. For most audits, the question is not "can you prove cryptographically that this was valid?" but "did you take reasonable steps at the time?". A receipt-time verification record is evidence of due diligence: it shows what you checked, when, and what the result was. That is what the record can honestly support, and it is what many due diligence regulations already ask for.

Authenticity vs independent existence

Digital signatures prove that a credential was issued by the controller of the issuer identifier, and that the bytes have not been altered since. They do not by themselves prove that the issuer's host still exists, that the verifier has seen every credential the issuer published, or that a backdated artefact could not have been produced with a key compromised later.

That distinction is also stated in the Verifiable Credentials profile. Content-addressable storage, independent timestamps, and transparency logs (inclusion proofs, append-only audit logs) are implementation patterns for availability and completeness. They are not required for UNTP conformance.

---

Summary

	Level 1	Level 2	Level 3 (example)
Storage	Self-hosted	Commercial cloud	Content-addressable store or archive
Survives issuer closure	❌	⚠️	✅, if copies remain reachable
Survives provider closure	❌	❌	✅, if more than one replica exists
Tamper-evident at storage layer	❌	❌	✅ (digest / CID)
One-time payment possible	N/A	❌	✅ (e.g. Arweave)
Typical use	Pilots	Short-lived credentials	Long-lived credentials

• Publishers plan for their own closure, keep their verification material available, and prefer identifiers and storage that survive a change of owner or provider.
• Receivers keep their own copies of the upstream evidence their claims depend on, with the material needed to check it and a record of what they checked on receipt.
• Everyone should be clear about the limits: a copy preserves the bytes and the keys, but not proof that a key was genuine or that a credential was not revoked at a given time.

---

Roadmap

Long-term preservation, historical status, and verifiable snapshots are recognised gaps in the wider verifiable credentials ecosystem, and are under discussion in the W3C credentials community. Later work, in UNTP or in standards it adopts, can take up:

Open item	Where it is discussed
A cache, mirror, or witness-proof protocol for DID documents and status lists	Verifiable Credentials roadmap
A timestamp profile binding independent proof of existence to signed artefacts	Copies do not prove status at a point in time
Historical status: showing that a credential was not revoked at a given time	Copies do not prove status at a point in time
Verifier reporting when checks use preserved rather than live material	Copies do not make an unreachable DID trustworthy
A preservation package schema, media type, and link relation	Preservation package (sketch only)
Zero-knowledge or summary proofs that checks were run, as an alternative to storing all raw evidence	Technical Working Group discussion
Custody and post-issuer release of decryption keys (Durability design requirement)	Custody of decryption keys
How durability sits next to a statutory right to erasure	Personal data and the right to erasure
Archival obligations for Identity Resolver operators	Accumulating Linked Data roadmap