A mandatory GTIN forecloses four of the five UPI schemes EN 18219 admits — and locks out operators without GS1 membership

[LKSNDRTMLKV]

Every product-group payload declares pub gtin: Gtin — not Option<Gtin>. A GTIN is structurally mandatory to create a passport in this workspace.

EN 18219:2026 — Digital product passport: Unique identifiers, one of the six standards cited by Commission Implementing Decision (EU) 2026/1736, and a presumption route under ESPR Art. 41(2) — does not require anything of the kind.

What the standard actually admits

Its clause 5.1 requires a unique product identifier to satisfy the general principles in its Clause 4 and comply with one of the ID schemes in Clause 5. They are alternatives. There are five:

#	Basis	External dependency
1	Web-enabled structured-path/query — GS1 Digital Link or ASC MH10.8.2 Data Identifiers	a registered Issuing Agency Code
2	Identification Link (IL), EN IEC 61406-1/-2, URL format	none — self-issuing
3	Decentralized Identifiers — did:web, did:ethr, did:ebsi	none — self-issuing
4	Limited-capacity carriers: RAIN RFID (ISO/IEC 18000-63) and 2D codes, resolver-based	an Issuing Agency Code
5	DOI (ISO 26324)	an issuing agency

We implement the GS1 branch of scheme 1, and the domain type makes it the only possibility.

🚨 A GTIN requires GS1 membership, which is a recurring commercial subscription. Schemes 2 and 3 are described by the standard as self-issuing systems without external dependencies. So the model forecloses four of five admissible routes, and the one it keeps is the only one with a paid third-party dependency.

Why this is a product question, not a tidiness question

An operator who cannot obtain a GTIN cannot create a passport here at all — not a degraded one, not one with a warning. The type system refuses.

That is a real segment. A small manufacturer, or a non-EU manufacturer placing product on the EU market under its own brand, carries the DPP duty and is among the least likely to hold GS1 membership. EN 18219 says such an operator can have a fully conformant unique product identifier. We say they cannot have a passport.

The cheapest route in is one we already ship

dpp-vc already produces did:web documents, and dpp-crypto already does Ed25519 and JWS.

Scheme 3 requires conformance with W3C Decentralized Identifiers v1.0:2022, and names did:web as the lightweight non-DLT option. It also records that a DID can represent any granularity — model, batch or item, which is the same flexibility scheme 1 gets from AI qualifiers.

So the distance from what is built to a second admissible scheme is smaller than it looks, and it runs through a crate that exists for another reason.

⚠️ One property of scheme 3 worth noting for transfer of responsibility: the standard records that DLT-backed DID methods enable dynamic updates of the deep link to the passport, explicitly including the case where the economic operator responsible for the passport changes. Scheme 1 has no equivalent mechanism. That is a surface this workspace already models.

What this issue asks for

A decision, taken deliberately, on whether gtin stays mandatory.

It is a persisted-shape change, so docs/architecture/PERSISTED-SHAPES.md governs it: a non-additive change to ProductGroupData makes already-written documents undeserialisable at runtime. That cost is zero today and rises monotonically. The project's own record is that breaking changes are free precisely while nothing depends on them, and that the window closes on the first real operator.

Three shapes, for whoever takes it:

1. Leave it. Defensible if GS1 is the deliberate target market. Should then be written down as a market choice rather than left as a type-level accident.
2. Option<Gtin> plus a scheme discriminant. The identifier becomes "which scheme, and its value", with GTIN one variant. Mirrors what LegalEntityIdentifier already does for EUID-or-other in the unsold-goods payload — the pattern exists in this crate.
3. Full identifier enum covering schemes 1–3. More work, and it is what conformance across schemes eventually needs.

I would take 2. It is the smallest change that stops foreclosing the other schemes, it reuses a pattern already in the crate, and it leaves 3 reachable without another persisted-shape break.

Not in scope here

Scheme 4 (RFID) and scheme 5 (DOI) — no pull for either, and scheme 4's territory belongs to EN 18220 (data carriers), which is a separate standard.

Also related but separate: #256, the unpinned GS1 Digital Link version. EN 18219 clause 6.3.2 names it as 1.6.0:2022.

[LKSNDRTMLKV]

The standard's own comparison table settles the cost argument

EN 18219's informative Annex B, Table B.4 (issuing process and prerequisites), compares the schemes side by side. Paraphrasing its rows:

Prerequisite for web-enabled access to the passport — every scheme requires a registered web domain, encoded directly or discovered via a resolution service. Scheme 3 is no different.

Process of issuing a product identifier:

Scheme	Steps
1 (ours)	1. obtain a CIN from an ISO/IEC 15459 issuing agency · 2. issue the product ID within the assigned number band
2	1. issue an ID based on the web domain
3 (did:web)	1. use a web domain · 2. create a DID · 3. publish the DID document
4	same as scheme 1 — CIN first

🚨 So scheme 3's prerequisites are a strict subset of scheme 1's. Both need a registered domain; scheme 1 additionally needs a Company Identification Number from an issuing agency — for the GS1 branch, that is the GS1 membership. Scheme 3 removes a dependency and adds none.

Any operator who can run a passport at all already has the domain. The CIN is the only thing standing between them and a conformant identifier, and it is the only part that costs money annually.

Sovereignty over the identifier's data, same table: scheme 1 — the economic operator controls the ID elements; scheme 2 — controls self-issued elements; scheme 3 — full control, verifiable via cryptography. Scheme 3 is the strongest position the standard describes.

What this does to the three options

It makes option 1 (leave it) harder to defend as anything other than a deliberate market choice, because the technical argument for requiring a GTIN is now explicitly weaker than the alternative — and the alternative runs on a primitive already in the workspace, since dpp-vc produces did:web documents today.

Option 2 still looks right, and this sharpens why: Option<Gtin> plus a scheme discriminant costs one persisted-shape change now and opens the scheme with the fewest prerequisites and the strongest sovereignty story.

⚠️ One caution from the same table — under changes in technology that would affect the scheme, it names changes to ISO/IEC standards or RFC 3986. Every scheme here is URL-shaped and inherits that exposure; scheme 3 is not more fragile than scheme 1 on that axis, but it is not less either.

(Reposted — an earlier version of this comment was mangled by shell quoting and has been deleted.)

[LKSNDRTMLKV]

🔒 Decided — option 3, the full identifier enum

Taken by the founder on 2026-09-12. Recording it here so the question is closed rather than re-opened.

gtin stops being mandatory. The product identifier becomes an enum covering EN 18219 schemes 1–3:

Scheme	Basis	External dependency
1	Web-enabled structured path/query — GS1 Digital Link or ASC MH10.8.2 Data Identifiers	a registered Issuing Agency Code
2	Identification Link — EN IEC 61406-1/-2, URL format	none — self-issuing
3	Decentralized Identifiers — did:web, did:ethr, did:ebsi	none — self-issuing

This is not what the issue recommended. The text above proposed option 2 — Option<Gtin> plus a scheme discriminant — as the smallest change that stops foreclosing the other schemes. Option 3 was chosen deliberately: it is what cross-scheme conformance eventually needs, and taking it now avoids a second persisted-shape break to get there.

Noting that explicitly so nobody later reads the recommendation, implements option 2, and believes they are following the plan.

Target: 0.21.0, not 0.20.0

Four dpp-engine issues sit behind the 0.20.0 publish, and option 3 is substantial work across every product-group payload, its schema versions and the persisted shapes. Holding that chain for this is the wrong trade.

✅ Nothing is lost by waiting. Breaking changes are free while nothing depends on them, and the window closes on the first real operator — not on the next release. That is still true the day after 0.20.0 ships.

The cost of a second release is one more engine repin, and 0.21.0's would be narrow — one shape change — where 0.20.0's is 37 sites.

Scope notes for whoever implements it

• dpp-vc already produces did:web documents, and dpp-crypto already does Ed25519 and JWS. Scheme 3 is nearer than the issue text suggests.
• LegalEntityIdentifier already models EUID-or-other in the unsold-goods payload. Follow that pattern rather than inventing a second one.
• Persisted shapes govern. docs/architecture/PERSISTED-SHAPES.md: a non-additive change to ProductGroupData makes already-written documents undeserialisable at runtime. Plan the migration, do not discover it.
• dpp-digital-link pins no GS1 Digital Link URI Syntax version — EN 18219 scheme 1 requires a named one #256 ships first, in 0.20.0. It pins GS1 Digital Link URI Syntax to 1.6.0:2022 — scheme 1 needs to be well-specified before it becomes one variant among three.
• Schemes 4 and 5 stay out, as the issue already records: no pull for either, and scheme 4's territory belongs to EN 18220, which nobody holds.

Still open in this issue

The implementation. This comment closes the decision, not the work — the issue stays open and its type/decision label should become type/defect or an enhancement when someone picks it up for 0.21.0.

[LKSNDRTMLKV]

First half open as #295: ProductIdentifier covering schemes 1–3, as decided above (option 3, not the body's option 2).

It adds the type only — nothing consumes it yet, so it is additive. The payload swap is held back deliberately and #295 enumerates what it costs: 11 payload structs, 29 schema files, a new frozen fixture per (product group, version), and ~32 call sites.

🚨 The finding worth carrying into that second PR: a lens makes it safe. Passport::from_stored already takes a LensRegistry, and PERSISTED-SHAPES.md records that the lens escape hatch covers productGroupData and never the envelope — which is where this field lives. So {"gtin": "…"} can be read forward into {"productIdentifier": {"scheme": "gs1", "gtin": "…"}} without breaking a frozen fixture. schema_compat.rs opens by naming the incident this avoids: TextileData.gtin becoming required cost 244 of 276 passports.

Staying open until the swap lands.