Digital Product Passport Data Model in 2026: GS1 Digital Link vs AAS vs Custom JSON-LD

Every manufacturer selling into the EU is about to inherit a data problem that looks deceptively like a QR-code problem. The regulation says “put a data carrier on the product and make the information accessible.” The engineering reality is that behind that carrier sits a digital product passport data model — a decision about how you identify the product, how you resolve that identifier to data, how you type and structure the attributes, and how you prove those attributes are authentic. Get the sticker right and the model wrong, and you will re-platform twice before 2030.

This is not a hypothetical. The battery passport carries a hard deadline, textiles and steel are queued behind it, and the three credible modelling approaches — GS1 Digital Link, the Asset Administration Shell, and custom JSON-LD with Verifiable Credentials — solve different halves of the problem and were never designed to be substitutes. Choosing well means understanding what each one actually standardises.

What this covers: the ESPR drivers and DPP data requirements, a head-to-head of the three data-model families, a deeper look at identifiers, resolvers, submodels and access control, a decision matrix, the failure modes that sink real projects, and concrete recommendations by product group and maturity.

Context and Background

The forcing function is the EU Ecodesign for Sustainable Products Regulation (ESPR), which entered into force on 18 July 2024 and reaches its central-registry milestone in 2026. ESPR replaces the old Ecodesign Directive and, crucially, empowers the Commission to require a Digital Product Passport for almost any physical product placed on the EU market through product-specific delegated acts. The first working priorities in the 2025–2027 window are iron and steel, textiles and apparel, tyres, and aluminium, with furniture behind them and an ambition that essentially all regulated product groups carry a passport by 2030. The legal detail — exact attributes, transition periods, who bears the obligation — lives in each delegated act, not in the parent regulation, which is why “what does a DPP need to contain” has no single answer yet.

The one deadline that is already binding comes from a different instrument: the EU Battery Regulation 2023/1542. From 18 February 2027 every industrial battery above 2 kWh, every EV battery, and every light-means-of-transport battery placed on the EU market must carry a QR code that links to a digital battery passport. A battery without one cannot legally be sold. That makes batteries the pilot that everyone else is watching, and it is why any serious conversation about a digital product passport data model starts with the battery template even for non-battery products.

Strip away the compliance language and a DPP has to represent four things: identity (a globally unique, resolvable identifier for the item, batch, or model), materials and composition (substances, recycled content, substances of concern), provenance (who made it, where, when, from what), and circularity (repair instructions, spare-part availability, disassembly, end-of-life routing). ESPR Article 9 adds the qualifiers that make this hard: the data must be structured, machine-readable, searchable, and — the killer phrase — based on open, interoperable standards. A PDF behind a QR code is not a passport. Neither is a proprietary database only your dealer network can read. The interoperability requirement is where the modelling choice stops being cosmetic: a recycler in 2032 scanning a product you shipped in 2027 must be able to parse your data with tools that were never built against your schema. For the architecture context around this, see our digital product passport architecture guide; the canonical legal text lives on EUR-Lex.

The data-model decision: GS1 Digital Link vs AAS vs custom

If you want the short version: no single standard covers the whole digital product passport data model. GS1 Digital Link standardises the carrier and identifier and how to resolve it; the Asset Administration Shell (AAS) standardises the semantic model — typed, machine-interpretable attributes with an API; and custom JSON-LD plus W3C Verifiable Credentials standardises portable, cryptographically signed claims. The realistic 2026 answer for most product groups is a layered stack that borrows one element from each, not a winner-takes-all pick. The diagram below shows those layers.

Figure 1 — The digital product passport data model as a layered stack: a physical carrier resolves an identifier, the identifier resolves to endpoints, those endpoints serve a typed semantic model, and signed credentials sit on top with role-based access control gating what each consumer sees. Long description: a top-to-bottom flow from physical product and data carrier, through carrier, identifier, resolver, semantic-model and credential layers, branching to an access-control node and finally to consumers such as authorities, recyclers and users.

The reason the layers matter is that each standard was born in a different community with a different centre of gravity. GS1 comes from retail and supply-chain identification — its whole life is about GTINs, barcodes, and getting a scan to the right web page. The AAS comes from German Industrie 4.0 and factory automation — its life is about machine-readable digital twins of industrial assets. JSON-LD and Verifiable Credentials come from the web and decentralised-identity communities — their life is about linked data and portable proofs. A DPP touches all three worlds, so the pragmatic architect treats them as complementary layers rather than rival platforms.

Identification and data carrier: GS1 Digital Link plus resolver

The first job of any digital product passport data model is to turn a physical item into something a machine can look up. GS1 Digital Link is the standard purpose-built for this. Instead of encoding an opaque number in a barcode, Digital Link encodes a web URI that embeds GS1 identifiers in a structured path — for example https://id.example.com/01/09506000134352/21/XYZ, where 01 is the GTIN application identifier and 21 is the serial number. That single URI is simultaneously a valid product identifier and a resolvable web address, which is exactly what ESPR’s “unique product identifier plus data carrier” language asks for.

The clever part is the resolver. A scan does not go straight to data; it goes to a GS1 Digital Link resolver, which looks up the identifier and, using the linkType query parameter, redirects the caller to the appropriate resource — a product information page for a consumer, a safety data sheet for a regulator, a repair manual for a technician. The standard defines linkType values from the GS1 web vocabulary (for example gs1:pip for a product information page) and specifies a 307 redirect to the matching target. The January 2026 revision of the standard tightened the URI syntax and resolver conformance criteria. What GS1 deliberately does not standardise is the content of the passport itself — it gets you to the door, not around the house. That is the seam where AAS or JSON-LD takes over.

Semantic model: Asset Administration Shell submodels

Once you have resolved to an endpoint, you need the payload to be typed, self-describing, and interpretable without a human reading prose. That is the Asset Administration Shell (AAS) — standardised as IEC 63278 and maintained through the Industrial Digital Twin Association (IDTA). An AAS is a digital twin container built from submodels, each describing one aspect of the asset: a Nameplate submodel for identity, a Technical Data submodel for specifications, a Handover Documentation submodel for manuals, a Carbon Footprint submodel, and a dedicated Digital Product Passport submodel that IDTA is standardising under its DPP4.0 work. Every element inside a submodel carries a semantic ID — an ECLASS or IRDI reference — so a machine can determine that a given property means “recycled content fraction” regardless of language or vendor. The AAS also defines a REST API, so a passport is not just a file but a queryable service. If your product already lives inside a factory digital twin, the asset administration shell submodels guide covers this modelling in depth.

Custom JSON-LD and Verifiable Credentials

The third family drops the industrial framing entirely and models the passport as linked data using JSON-LD, optionally wrapped in W3C Verifiable Credentials (VC). JSON-LD lets you attach a machine-readable @context to plain JSON so that "recycledContent" maps to a shared vocabulary IRI — you get semantic interoperability without adopting the full AAS metamodel. Wrapping the passport, or slices of it, in Verifiable Credentials adds cryptographic signatures and issuer identity: a recycler can verify that a “50% recycled aluminium” claim was actually signed by the smelter, not edited in transit. This is the direction the EU-funded CIRPASS-2 project and the UN Transparency Protocol have converged on — CIRPASS-2 recommends JSON-LD as the default DPP exchange format and Verifiable Credentials for authenticated identities and records. It is the most flexible option and the least prescriptive, which is both its strength for cross-actor supply chains and its risk for teams that under-model.

Deeper analysis: identifiers, resolvers, submodels, and access control

The three families diverge most sharply on four mechanisms that decide whether your passport survives a decade: how identifiers are minted, how resolution works, how attributes are typed, and how access is controlled. Understanding these mechanics is what separates a defensible digital product passport data model from a schema you will abandon.

Identifier schemes. GS1 gives you a globally governed identifier space — GTINs, GS1 serialised identifiers, GIAI for individual assets — issued through GS1 member organisations, so uniqueness is guaranteed by an existing global registry that retail and logistics already trust. AAS mints its own globally unique AAS and submodel identifiers (IRIs or IRDIs) but leaves the asset identifier to you, which is more flexible but shifts the uniqueness burden onto your governance. Custom JSON-LD lets you use any IRI, including W3C Decentralised Identifiers (DIDs), which decouples identity from any central registry — powerful for multi-party chains, but you now own the hard problem of making sure two smelters do not mint colliding IDs. For a consumer product with a retail barcode, fighting GS1 is pointless; for a bespoke industrial asset, GS1 identifiers may be overkill.

Figure 2 — The GS1 Digital Link resolver flow. A scanner requests the Digital Link URI; the resolver looks up the GTIN and requested linkType in a link registry and returns a 307 redirect to the correct target, which then serves the DPP payload filtered by the caller’s role. Long description: a sequence diagram with a user scanner, resolver, link registry and data source exchanging lookup and redirect messages before the passport payload is returned.

Resolution and hosting. GS1’s resolver model is the most mature: a redirect service you host (or a GS1-operated one) that maps one identifier to many typed links. AAS resolution runs through registries and repositories defined by the IDTA API specifications — a discovery service finds the AAS, a repository serves the submodels. Custom JSON-LD has no prescribed resolver; you either invent one or borrow GS1’s, which is exactly why most real deployments end up layering GS1 Digital Link on the front of a JSON-LD or AAS payload. Hosting is a strategic decision, not a deployment detail: whoever hosts the resolver and the data controls availability for the product’s entire regulated life, which for a battery or a building product can be 15+ years.

A concrete mechanism most teams overlook is carrier capacity versus payload size, and it quietly shapes the whole digital product passport data model. A QR code is not a database — a standard Version 40 QR at the error-correction levels used for durable product marking holds only a few thousand bytes, and a GS1 Digital Link URI plus a short serial comfortably fits in well under 100 characters. That forces a clean split: the carrier holds an identifier, never the data. The data — which for a battery passport can run to dozens of typed attributes across cell chemistry, state-of-health telemetry, carbon footprint and due-diligence records — lives online and is fetched through the resolver. This is precisely why the resolver layer is load-bearing rather than optional: it is the only place the identifier-to-data mapping can scale, be re-pointed when a data host changes, and serve different payloads to different roles from the same scan. An architecture that tries to cram passport content into the carrier itself will not survive the first delegated act that expands the required attribute set, because the byte budget was fixed the day the label was printed.

Semantics and typing. This is where AAS is strongest and custom JSON-LD is most dangerous. AAS forces every property to carry a semantic reference into a dictionary (ECLASS, IEC CDD), so interpretation is unambiguous by construction. JSON-LD can achieve the same rigour through a well-governed @context, but nothing forces you to — it is entirely possible to ship syntactically valid JSON-LD that no external party can interpret because your context is private and undocumented. AAS structure for a DPP is shown below.

Figure 3 — An Asset Administration Shell structured for a DPP: the shell aggregates Nameplate, DPP, Technical Data, Handover Documentation and Carbon Footprint submodels, each built from typed SubmodelElements that reference external semantic IDs and are served through the AAS REST API. Long description: a flowchart from a central Asset Administration Shell node branching to five submodels, with the DPP submodel expanding into typed properties, semantic IDs and an API endpoint.

Access control and data sovereignty. A DPP is not a single public blob. Regulators, recyclers, repairers, customs, and consumers each get a different view, and commercially sensitive data (bill of materials, supplier identities) must stay gated. GS1’s linkType gives you coarse role routing at the resolver. AAS access control is handled at the API/registry layer and increasingly through dataspace connectors (Eclipse Dataspace Components, Catena-X patterns) that enforce usage policies. Verifiable Credentials give the finest-grained, most portable model — selective disclosure lets a holder prove one attribute without revealing the rest — but demand the most cryptographic plumbing. The following matrix summarises how the three families score across the criteria that actually drive the decision.

Criterion	GS1 Digital Link	Asset Administration Shell (AAS)	Custom JSON-LD / VC
Standardisation maturity	Very high; stable, retail-proven, Jan 2026 revision	High and rising; IEC 63278, IDTA DPP4.0 emerging	Medium; JSON-LD + VC stable, DPP profiles still forming
Identifier scheme	Global GS1 registry (GTIN, GIAI)	AAS/submodel IRIs; asset ID left to you	Any IRI incl. W3C DIDs; you govern uniqueness
Semantics / typing	Minimal; carrier + link only	Strong; every element carries a semantic ID	Optional; only as good as your `@context`
Resolver / hosting	Purpose-built resolver + linkType	Registry + repository via IDTA APIs	None prescribed; usually borrows GS1
Access control & sovereignty	Coarse, via linkType routing	API/registry + dataspace connectors	Finest-grained; VC selective disclosure
Tooling ecosystem	Mature scanners, resolvers, GS1 orgs	Growing; AASX Package Explorer, BaSyx	Broad web/DID tooling, few DPP-specific
ESPR / regulatory fit	Strong for carrier + identifier	Strong for structured industrial payload	Strong for cross-actor signed claims

Read the matrix as columns of strengths, not a scoreboard. GS1 wins the carrier and identifier row and loses the semantics row; AAS wins semantics and loses carrier; JSON-LD/VC wins sovereignty and loses maturity. That is precisely why the layered stack keeps reappearing in serious deployments.

Trade-offs, gotchas, and what goes wrong

The failures in real DPP programmes are rarely about the standard being wrong; they are about a mismatch between the standard’s assumptions and the organisation’s reality. The decision tree below is the sanity check I run before committing.

Figure 4 — A decision flow for choosing a digital product passport data model: retail-carrier products steer toward GS1 Digital Link, factory-twin assets toward AAS submodels, and cross-actor signed-claim needs toward JSON-LD with Verifiable Credentials, with a final layering step that combines them. Long description: a branching flowchart evaluating whether the item is a consumer retail product, an industrial asset in a factory twin, or needs signed cross-actor claims, converging on a payload-layering node.

Interoperability gaps are the number-one killer. Two teams can both claim “we use AAS” and still be unable to read each other’s passports because they chose different semantic dictionaries or different submodel templates for the same attribute. GS1 and AAS overlap awkwardly — both can express identity — and if you model identity in both without a single source of truth you get drift. The mitigation is to pick one authoritative layer per concern: GS1 for the identifier, AAS or JSON-LD for the payload, VC for proofs, and never let two layers both claim to own the same field.

Versioning is unglamorous and unavoidable. A passport must remain readable for the product’s full regulated life, which can exceed the lifetime of your schema, your resolver software, and possibly your company. If you embed a schema version and a stable @context URL that you commit to keeping resolvable for 15 years, you are fine; if your context lives at a URL that 404s after a reorg, every passport that references it silently loses its semantics. Treat context and schema URLs as permanent infrastructure with the same care as a domain you never let lapse.

Who hosts, and data sovereignty. The host of the resolver and data controls availability, and regulators expect the passport to survive even if you outsource it. Over-centralising on one vendor’s cloud creates a single point of failure and a lock-in; over-decentralising onto ad-hoc DID infrastructure creates an operational burden most manufacturers cannot staff. Dataspace patterns (Catena-X, Eclipse EDC) exist precisely to keep sovereignty with the data owner while enabling sharing — worth the complexity for high-value chains, overkill for a €5 consumer good.

Over- and under-modelling. Adopting the full AAS metamodel for a simple textile passport buries a small team in submodel tooling they do not need; shipping bare JSON with no @context for a complex industrial asset produces a passport no external party can interpret. Match the model’s weight to the product group’s actual data complexity and the sophistication of the parties who must read it.

The seam between standards is where integration cost hides. In practice the expensive engineering in a digital product passport data model is not adopting any single standard — it is the glue between them: mapping a GS1 GTIN to an AAS asset identifier, translating an AAS submodel property into a JSON-LD claim for a Verifiable Credential, keeping the resolver’s link registry in sync with the PLM system that owns the authoritative attribute values. Each of these mappings is a place where a field can be duplicated, mistranslated, or silently dropped. Budget for the glue explicitly, write conformance tests that round-trip a passport through every layer, and treat the mapping tables as first-class, version-controlled artefacts rather than throwaway integration scripts. Teams that skip this discover, usually during an audit, that their “compliant” passport disagrees with itself depending on which layer you read.

Practical recommendations

Start from the product group and the reader, not from the technology you already own. For consumer and retail goods (textiles, footwear, electronics, packaging), lead with GS1 Digital Link for the carrier and identifier — the barcode is already there, GS1 governance solves uniqueness, and the resolver gives you role-based routing cheaply. Layer a JSON-LD payload behind the resolver so the content stays interoperable, and reserve Verifiable Credentials for the specific claims (recycled content, substances of concern) that a third party must be able to verify.

For industrial and capital assets (machinery, batteries as industrial products, building components) that already participate in a digital twin or a Catena-X-style dataspace, lead with AAS submodels — you get typed semantics, an API, and alignment with the factory data you already maintain — and put a GS1 Digital Link or equivalent resolvable identifier on the front so a field technician’s phone can still reach it. For cross-actor supply chains where provenance must survive many hand-offs (critical raw materials, complex bills of materials), lean into JSON-LD plus Verifiable Credentials for portable, signed claims, again fronted by a resolver. Tie the whole approach into your broader digital thread and PLM architecture so the passport is a projection of authoritative PLM data, not a parallel silo. For the standards comparison underneath AAS, the AAS vs DTDL vs OPC UA information models analysis is the companion piece.

Selection checklist:

Retail barcode already on the product? GS1 Digital Link for carrier + identifier is non-negotiable.
Product lives in a factory/twin or dataspace? AAS submodels for the payload.
Claims must be verified by parties you do not control? JSON-LD + Verifiable Credentials.
One authoritative layer per concern — never model the same field in two standards.
Commit context/schema URLs for 15+ years and decide the resolver host deliberately.
Match model weight to data complexity — do not adopt full AAS for a simple textile tag.

Frequently Asked Questions

Is there one official EU digital product passport data model?

No. ESPR mandates that a DPP be based on open, interoperable, machine-readable standards, but it deliberately does not name a single technical standard in the parent regulation. The specific data content and, where relevant, the technical format are set per product group in delegated acts. The battery passport under Regulation 2023/1542 is the first binding case (18 February 2027). In practice the market is converging on a layered digital product passport data model that combines GS1 Digital Link, AAS, and JSON-LD/Verifiable Credentials rather than a single mandated schema.

Can I just use GS1 Digital Link for the whole passport?

Not by itself. GS1 Digital Link standardises the identifier, the data carrier, and the resolver — how a scan finds the right resource — but it does not standardise the content of the passport. You still need a semantic model behind the resolver, whether that is an AAS submodel, a JSON-LD document, or a Verifiable Credential. GS1 Digital Link is almost always the right front layer because it solves identification and routing cleanly, but it is one layer of the stack, not the whole thing.

When does the battery passport deadline actually hit?

18 February 2027. From that date, industrial batteries above 2 kWh, EV batteries, and light-means-of-transport batteries placed on the EU market must carry a QR code linking to a digital battery passport under EU Regulation 2023/1542. A non-compliant battery cannot legally be placed on the market. Because it is the first binding DPP-style requirement, the battery passport is the reference template that other product groups — steel, textiles, tyres — are watching as their own ESPR delegated acts are drafted.

How does the Asset Administration Shell relate to a DPP?

The AAS (IEC 63278) is a digital-twin container made of submodels, and a DPP can be expressed as a dedicated DPP submodel alongside Nameplate, Technical Data and Carbon Footprint submodels. Its advantage is strong, typed semantics — every property carries a semantic ID so machines interpret it unambiguously — plus a standard REST API. IDTA’s DPP4.0 work is standardising this. AAS is the natural payload choice when the product already lives in a factory digital twin or an industrial dataspace.

Where do JSON-LD and Verifiable Credentials fit?

JSON-LD gives your passport machine-readable semantics through a shared @context without adopting the full AAS metamodel, and W3C Verifiable Credentials wrap claims in cryptographic signatures tied to an issuer identity. This lets a downstream actor — a recycler, a customs officer — verify that a claim was genuinely signed by the party who made it. The EU-funded CIRPASS-2 project recommends JSON-LD as the default DPP exchange format and Verifiable Credentials for authenticated identities and records, so this family is central to cross-actor supply chains.

What is the biggest mistake teams make with a DPP data model?

Modelling the same concept in two standards at once and letting them drift, or shipping “interoperable” data whose semantics live in a private, undocumented context that no external party can resolve. The fix is discipline: choose one authoritative layer per concern (identifier, payload, proof), reference public and permanently hosted vocabularies, and commit to keeping your context and schema URLs resolvable for the product’s entire regulated life — which can exceed a decade.

Digital Product Passport Data Model (2026): GS1 vs AAS vs Custom