From Question to Published Passport: The Five Steps, and Who Does Each One
The five steps between deciding you need a product passport and having one that works: identifier, carrier, resolver, access and staying alive.
Jump around this page
- In 60 seconds
- Step 1. Allocate an identifier
- Step 2. Put the identifier on a carrier
- Step 3. Make the scan resolve
- Step 4. Decide who sees what
- Step 5. Keep it live, and leave a copy that outlives you
- Who does each step
- Where an independent service provider comes in
- What this page does not do
- Keep exploring
- Primary sources
In 60 seconds
Publishing a passport takes five steps: allocate an identifier, put it on a carrier, make the carrier resolve, decide who sees what and keep the record alive for the expected lifetime of the product. The operator stays responsible for all five, and a backup copy has to be held through an independent third-party DPP service provider.
- Article 10(4) of the Ecodesign for Sustainable Products Regulation requires the backup copy when the product is placed on the market. Hosting it yourself does not satisfy it.
- Identifiers cover products, economic operators and facilities, with product identity at model, batch or item level. The level is the hardest decision to reverse.
- A passport's possible content is bounded to a closed list of twelve elements. The delegated act for each product group decides who sees which.
- Hosting or backing up a passport does not move responsibility. The verified economic operator stays the controller of the data it submits.
- For most categories no delegated act exists yet. The page puts no date on any of the five steps.
They come in that order because each one rests on the one before it. An identifier with no carrier is a key in somebody's database. A carrier with no resolver is a printed square. A resolver with no access rules answers everybody the same way. A record that stops being reachable when the business holding it stops trading fails the one durability test the framework does set.
None of this is a compliance schedule. Whether a passport is required for your product, and from when, is a separate question, and the dates are on the DPP timeline.
For textile products, an incomplete starting record is not a reason to begin with a blank form. Build from the product data you already have, then follow the publication responsibilities set out below. The example does not replace the category-specific rules.
Step 1. Allocate an identifier
The European standard on unique identifiers for digital product passports establishes identifiers for products, for economic operators and for facilities. Product identification is available at model, batch or item level.
Three identifiers, answering three different questions, belonging to three different owners. Most catalogues hold one of the three. The level you allocate at is the hardest decision to reverse, because it is printed on goods that stay in circulation.
Who does it: the operator, using an issuing scheme. What it turns on: which level the applicable product rules require, which is decided by the product-specific act rather than by the framework.
Owned by the three identifiers.
Step 2. Put the identifier on a carrier
Six things have to still be working for a scan in five years to do anything, and the printed square is only one of them. The architecture with the best chance puts everything volatile at the far end and keeps the printed part small, stable and boring.
Which identifier goes inside the mark, and what allocating one commits you to, is the step above. This step is the mark and the chain behind it, and the usual way the identifier is written into it is a GS1 Digital Link.
Who does it: the operator, usually through whoever prints the label or the packaging. What it turns on: how long the goods stay in circulation, because the mark cannot be recalled.
Owned by choosing a carrier that still works.
Step 3. Make the scan resolve
Four things happen, in that order, every time somebody scans. A device reads the carrier. The carrier yields an address. A service matches the identifier inside that address against something it holds. It answers with a redirect to a target address that somebody chose in advance.
The address the carrier yields is usually a GS1 Digital Link, and only the last of those four steps is governed by a standard, which is a resolver standard rather than a passport standard. It says what the service must do when it is asked, what it must say when it holds nothing and what it must never do. It says very little about what sits at the target address.
Who does it: whoever runs the resolver, which may be the operator, a provider or a third party. What it turns on: who owns the domain those printed codes resolve to, which is a commercial question with a very long tail.
Owned by what happens when you scan.
Step 4. Decide who sees what
The framework is built for differentiated access. It names a long list of actors who reach a passport according to their respective access rights, it bounds what a passport may contain to a closed list of twelve elements, and it hands the question of who gets which of them, and who may write to the record, to the delegated act covering each product group.
The horizontal framework deliberately does not give one actor universal edit rights. Who may update a passport depends on which data is being changed, which actor is making the change and what the applicable product law allows that actor to do.
Who does it: the delegated act for the product group decides the rule, and the operator implements it. What it turns on: whether an act exists for the product group yet. For most categories it does not.
Owned by who sees what and who can update a DPP.
Step 5. Keep it live, and leave a copy that outlives you
The framework requires a passport to stay available for at least the expected lifetime of the product, and the requirement is written to hold after insolvency, liquidation or cessation of activity. Somebody drafting that sentence expected passports to outlive the businesses that made them.
It supplies exactly one mechanism for it. Article 10(4) of the Ecodesign for Sustainable Products Regulation requires the economic operator, when placing the product on the market, to make available a backup copy of the passport through a digital product passport service provider. That is not optional and it is not satisfied by hosting it yourself.
Who does it: an independent third-party service provider, authorised by the operator. What it turns on: the contract, because almost everything that decides whether the copy is usable later is contractual rather than statutory.
Owned by when the link dies.
Who does each step
| Step | Who decides the rule | Who does the work | Where it is written down |
|---|---|---|---|
| Identifier | The product-specific act, on level | The operator | The three identifiers |
| Carrier | The operator | The operator and its label or packaging supplier | Choosing a carrier |
| Resolver | A resolver standard, on behaviour | Whoever runs the resolver | What happens when you scan |
| Access rights | The delegated act for the product group | The operator | Who sees what |
| Backup copy and continuity | The framework, at Article 10(4) | An independent service provider | When the link dies |
Hosting or backing up a passport does not move responsibility: the verified economic operator is the controller of the data it submits, accuracy and completeness sit on that operator at registration and continuously afterwards, and a third party acting on your behalf does not become the responsible party.
Where an independent service provider comes in
Step 5 is not a make-or-buy decision. Independent DPP service providers exist because the framework requires one, and companies in this market do this work as a service: they hold or back up passport data, they can operate parts of the registration workflow where that is permitted, and some of them run the resolver as well.
Every item on this short list is answerable in a sentence by a provider that has thought about it.
- Who owns the domain the printed codes resolve to. If it is the provider, you are printing their address onto your goods for the life of those goods.
- What an export actually contains. Every value carrying its source, every absence typed rather than blank, and the evidence behind a value rather than only the value.
- Whether there is a clause constituting specific agreement under the framework's restriction on reusing your data, and if so what it permits.
- What verified status establishes, which is identity and establishment rather than the quality of the service.
What you can take with you and DPP service providers carry these in full. Neither compares providers, names any of them or scores anything, and nor does this page.
What this page does not do
It does not say a passport is required for your product. That depends on the product-specific act, and where one does not exist there is no passport duty to plan around yet.
It does not put a date on any of the five steps. Dates belong to instruments and they are kept on the DPP timeline.
It does not rank or recommend suppliers.
Keep exploring
The questions this page usually raises next.
- CompareNext questionProduct Passport Vendor Lock-In: What to AskNobody sells a guide to leaving a Digital Product Passport (DPP) provider.
- CompareNext questionDPP Service Providers: What the Law Actually RequiresThe DPP framework makes you keep a product passport backup with a service provider and limits what it may do with your data, unless…
- Related questionNext questionDigital Product Passport Timeline: What Applies When?Adopted, in force, applying or only planned: every Digital Product Passport date by category, and which of those four kinds of date…
Primary sources
-
EU law
Give the publication process a usable product record.
For textile products, start with the data and evidence you already hold. Then work through the identifier, access and publication responsibilities explained above.