How would I build a passport, and what New Zealand has built already

Nobody can build one to specification today. A delegated act sets the fields for a product group, and the European Commission has adopted none. So the data model you would build against does not exist yet.

The work that holds its value is different, and it is cheap. Find out where each piece of your product data lives today, and who inside your business owns it.

This site searched 104 New Zealand pages on 16 August 2026. Ten of them ask how a passport gets built, hosted or resolved, and none answers the question.

Three New Zealand systems exist, and none is a European passport

Warning: none of the three is a European digital product passport, and no adopted act recognises any of them.

Each one is a New Zealand traceability system built for a commercial reason. A buyer wants proof of origin, and these systems supply it. That is a real market, and it is not compliance.

The Farmers Weekly report on WoolPass makes the point without meaning to. It describes the platform in full and names no European regulation at all.

GS1 New Zealand did the most detailed New Zealand design work

GS1 New Zealand published a feasibility study in February 2026, written by Rebecca Berendt. It asks if a shared data hub could collect and share plastic packaging data in New Zealand retail.

The study proposes a federated data space. Data stays with the party that holds it, and it travels by agreement rather than by copying into one database.

That design is sound, and it answers a New Zealand question. It does not tell you what a European act will require, because no act exists to describe.

The study also states its own limit. It asks if New Zealand product master data already carries the attributes a passport needs. It answers that somebody must check.

The four parts a passport needs, whatever the act says

A passport has the same shape in every account this site has read.

1. An identifier for the item, the batch or the model, as the act requires.
2. A data carrier on the product, which is usually a QR code.
3. A resolver, which turns a scan into the right data for the reader.
4. The data itself, held somewhere that stays available.

The act decides three things about that shape. It sets the fields, it sets which reader sees which field, and it sets how long the data must survive.

Warning: build nothing against a guessed field list. A guess costs you the build twice.

See what is a resolver and the EU registry.

Access rights are the part that is still being written

Not every reader sees every field. A repairer, a recycler, a customs officer and a shopper each get a different view.

The standard for that part is prEN 18239, and it is still under approval. So the mechanism that decides who sees what is not settled yet.

That has one consequence for you today. A supplier that claims to implement access rights is implementing its own design. See prEN 18239.

The four cheap steps that survive any act

1. List the data fields your product already has, and name where each one lives.
2. Name the person inside your business who owns each field.
3. Give your products a unique identifier, if they do not have one.
4. Ask your European importer which fields it expects to need.

Step one is the one exporters skip, and it is the one that takes longest. Data about a merino jumper sits in a farm record, a scour record, a mill record and your own system.

Nothing in that list needs a passport system, a vendor or a subscription. See first steps for a New Zealand exporter.

The next open question is if New Zealand will make its own rule. See will New Zealand make its own rule.