How to version the textile DPP: immutable Core vs Life-cycle Log with W3C VC 2.0

Why version the DPP — anatomy of the retroactive invalidation risk under the 2027 textile delegated act

The ESPR Regulation (EU) 2024/1781 establishes a fundamental change in the nature of product information. Article 9(1) imperatively requires that the data contained in the digital product passport "be accurate, complete and up-to-date". This provision transforms static labelling into a dynamic data flow. With the entry into force of the textile-specific delegated act, indicatively foreseen for 2027, the obligation to keep the information current collides directly with the traditional data architecture.

The main technical risk lies in the generation of monolithic JSON-LD documents. If a manufacturer issues a digital passport consolidating all the product attributes (composition, environmental footprint, reparability) in a single digitally signed file, any subsequent alteration compromises the integrity of the document. The cryptographic signature of a JSON-LD object seals the state of the information at the instant of its issuance. If, during the use phase, a repair workshop replaces a zip or alters the original composition, the direct update of the initial document would require the original manufacturer to revoke the previous signature and issue a new one. This monolithic architecture triggers a risk of retroactive invalidation: the original manufacturer would be forced to assume legal and technical responsibility for modifications carried out by third-party economic operators, contravening the principles of limited liability.

Article 9(2)(h) of the ESPR requires the delegated acts to define the "details for the entry or updating of the data". To resolve the friction between the immutability of the original declaration of conformity and the obligation to document the life cycle, the European Commission, through the JRC, discards the single-document model. The update of the DPP must not be understood as the rewriting of a centralised database, but as the concatenation of independent cryptographic evidence. Without a structured versioning system, the administrative burden and the litigation risk from alterations to the environmental footprint or the declared composition would make compliance operation unfeasible.

The decentralised versioning architecture mitigates this exposure. By isolating the original declaration from the post-sale event flow, the manufacturer seals its legal responsibility at the factory gate (or at the point of import). The subsequent iterations of the article fall on the digital signatures of the secondary market operators.

Core DPP vs Life-cycle Log — mandatory technical separation of Annex 9 of JRC 145830

The JRC 145830 document, in its Annex 9 (DOI 10.2760/4511279), establishes the "Governed Life-cycle Data Framework" as the canonical methodology for post-sale data management. This framework imposes a two-fronted architecture. On the one hand, data segregation is required. The text is categorical: "Data segregation: the 'Core DPP' and the 'Life-cycle Log'".

The Core DPP comprises the original data provided by the manufacturer at the moment of placing on the market. It includes the fundamental compliance information, the design specifications and the performance metrics declared under conformity assessment. The JRC rules that this core "must be treated as immutable or subject to extremely restricted editing rights, only by the original manufacturer". It acts as the digital birth certificate of the textile product, unalterable over the years.

In contrast to this static core, the Life-cycle Log is defined as an "append-only ledger linked to the Core DPP". The framework establishes that "all subsequent events in the value chain — repairs, software updates, ownership changes, refurbishment activities — are recorded here as new time-stamped entries". This sequential register preserves the integrity of the manufacturer's original data while allowing the product's history to be expanded through the contributions of other actors.

This separation directly impacts the resolution level of the DPP. Article 9(2)(d) of the ESPR allows the passport granularity to be set at "model, batch or item" level. The Core DPP is usually configured at model or batch level, since the fibre composition or the theoretical carbon footprint is identical for a production run. However, the Life-cycle Log inexorably gravitates towards the individual item level. The JRC notes that, if a repair event is documented, the passport acquires item specificity, since the physical intervention occurs on a single unit. To support this transition of granularity, the system must admit multilevel references, where the repair identifier points to the instance identifier, which in turn inherits the immutable metadata of the Core DPP at model level.

W3C VC 2.0 nesting + DataIntegrityProof — cryptographic signature of the Core and Selective Disclosure

Operationalising the separation between Core and Log requires a data exchange standard that supports distributed signatures and independent verifiability. The "Verifiable Credentials Data Model v2.0" (W3C VC 2.0) constitutes the chosen cryptographic infrastructure. Instead of using relational databases with centralised write permissions, the textile DPP is conceived as a graph of nested verifiable credentials.

The manufacturer issues the Core DPP as a primary credential. This credential uses the `DataIntegrityProof` mechanism. The W3C standard specifies that a data integrity proof secures the original credential by "decorating the original data with a digital signature through the proof property". This signature certifies that the set of technical attributes, such as the proportion of recycled cotton or the reparability score, was issued on a precise date by an entity with a specific public key.

When a life-cycle event occurs, a second credential is issued. This event credential does not modify the original JSON-LD, but references the unique product identifier (URI) established in the Core DPP. The stacking of these W3C credentials forms the product's auditable history.

Version 2.0 of the standard also introduces native support for advanced cryptography techniques, such as "Selective disclosure" and "Unlinkable disclosure". The W3C recommends the use of mechanisms such as the "Data Integrity BBS Cryptosuites v1.0". These BBS+ signatures allow the credential holder to generate derived proofs that reveal specific subsets of information without exposing the complete document. In the context of the ESPR, this resolves the conflict between public transparency and trade secrecy. A manufacturer can sign an exhaustive Core DPP that includes confidential supply chain data (Tier 4). Through selective disclosure, the resolution server presents a filtered view of the credential to the end consumer, hiding the identifiers of the spinning factories, but allows a Market Surveillance Authority to mathematically verify the integrity of the complete document using the same base cryptographic signature. The nesting and the filtering at source guarantee data sovereignty across the reading nodes.

Role-based permissions — granular access control and DIDs of the intervening actors

Annex 9 of the JRC 145830 document underscores that the architecture must have "Authenticated and role-based write permissions". The right to add data to the Life-cycle Log must be strictly controlled. The standard specifies: "Each entry in the Life-cycle Log must be digitally signed or otherwise cryptographically linked to the actor that created it".

To establish this unavoidable attribution, each actor in the textile ecosystem must possess a Decentralized Identifier (DID). The "DID method did:web" is the most pragmatic for the industrial environment, since it links the cryptographic identity to the authority of an existing DNS domain (for example, `did:web:brand.com`), avoiding the friction of operating nodes on blockchain networks.

The operational model segments the authorisations into strata. The manufacturer assumes the role of root issuer (access Tier 1). It controls the domain that hosts the `did.json` document and safeguards the private key that seals the Core DPP. When the garment transits towards the after-market, the repair or refurbishment operators assume secondary roles (Tier 2). An independent repairer, previously authenticated or validated under a trust framework, uses its own identifier (e.g. `did:web:workshop.com`) to issue a repair credential.

This mechanism decentralises responsibility. The manufacturer does not act as notary of the workshop's actions. If a workshop replaces internal linings with non-conforming materials and documents it in the Log, the digital signature directly points to the identifier `did:web:workshop.com`. Article 11(f) of the ESPR requires the system to define "the rights to enter, modify or update data in the digital product passport". Through the use of nested VCs and independent DIDs, a Policy Decision Point (PDP) instantly evaluates the signatures in the read request. If the consumer scans the QR code, the resolver retrieves the Core DPP (signed by the brand) and the repair credential (signed by the workshop), assembling the complete information graph and presenting traceability injected with cryptographic trust where the authorship of each attribute is indisputable.

Versioned JSON-LD snippets — a repair event in the life cycle

To materialise this architecture, we analyse the operational code of a post-sale event. JRC 145830 (Annex 9, p. 114) defines the structure required for an intervention: "A standardised 'Repair Event' entry". This credential acts as the second link of the graph, linking to the item identifier defined in the Core DPP.

Below is the JSON-LD fragment corresponding to the addition to the Life-cycle Log of a zip repair on a recycled polyester jacket.

```json { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://w3id.org/traceability/v1", "https://purl.org/espr/textile/v1" ], "id": "urn:uuid:8b3e5a7d-912b-4d3c-a7f4-6e1c2d9a5b3f", "type": ["VerifiableCredential", "RepairEvent"], "issuer": "did:web:reparaciones-textiles-certificadas.eu", "validFrom": "2028-10-14T09:30:00Z", "credentialSubject": { "id": "urn:epc:id:sgtin:0614141.112345.6789", "activityType": "ComponentReplacement", "replacedComponent": "ZipperAssembly", "addedMaterial": { "type": "MaterialComponent", "name": "Recycled PET Zipper", "identifier": "batch-zpr-445" }, "repairFacility": "did:web:reparaciones-textiles-certificadas.eu", "warrantyExtensionDays": 180 }, "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-rdfc-2022", "created": "2028-10-14T09:31:12Z", "verificationMethod": "did:web:reparaciones-textiles-certificadas.eu#key-1", "proofPurpose": "assertionMethod", "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz" } } ```

In this canonical code block, the semantics operate in three dimensions. First, the `@context` links the document to the standardised vocabularies of the ESPR and of traceability. Second, the `credentialSubject` object does not describe the product itself, but the temporal event. The key property is `"id": "urn:epc:id:sgtin:0614141.112345.6789"`. This exact SGTIN identifier corresponds to the individual item instantiated in the original Core DPP. The injection of the `activityType` and `addedMaterial` fields complies with the ESPR requirements for the traceability of substances and components for end-of-life. Third, the `proof` node applies the W3C standard. The `verificationMethod` property exposes the workshop's public key hosted in its DID document, enabling any verifier (recycling software or customs application) to calculate the hash of the canonicalised JSON under RDFC-1.0 and mathematically validate the EdDSA signature (`eddsa-rdfc-2022`). The original manufacturer of the jacket is exonerated; the workshop assumes the traceability of the newly inserted component.

Operationalising the versioning

The implementation of the Governed Life-cycle Data Framework and the management of nested cryptographic signatures drastically raises the technical barrier for compliance with Regulation 2024/1781. Operating JSON-LD credential graphs and ensuring the resolution of decentralised identifiers requires engineering deployments alien to the core business of design and manufacturing.

For textile brands that need to version the DPP operationally with Core/Log separation + W3C VC 2.0 without building their own cryptographic infrastructure: DPP Readiness — TraceWeave's module that pre-loads the Annex 9 [JRC 145830](/recursos/glosario/jrc-145830-metodologia-dpp) schema + automates the DataIntegrityProof signature + manages the DIDs of [Tier 1](/recursos/glosario/tier-1-2-3)-N actors. → Discover DPP Readiness