Disclosure doesn't cost you the signature

Disclosure doesn't cost you the signature

Anyone shown protected fields usually has to trust the platform. We sign each field on its own, so those fields carry their own proof.

A Digital Product Passport does not show everyone the same thing. A shopper sees the public data. A repairer or a refurbisher sees more. A market-surveillance authority sees everything. That much is settled, and the European standards now spell it out.

The interesting question is quieter: when a reader is shown protected fields on top of the public data, can they prove that those particular fields are genuine? Or do they just have to trust that the platform picked them correctly and passed them on unchanged?

Picture a notary who certifies each paragraph separately rather than the letter as a whole. Everyone receives the public letter. Anyone entitled to more receives the additional paragraphs too, each still carrying the same notary’s seal. That is how we built our platform. For most platforms, the honest answer to the question above is trust. For ours it is proof, for every field that arrives through disclosure. This article explains why that distinction matters, and why we took the harder road to get it.

Everyone meets the access rule the same way

EN 18239, the European standard for access-rights management, security and confidentiality in a DPP, says access has to be controlled per field: each field has a rule for who may see it. It is the right requirement, and it is not hard to satisfy. What status these standards actually carry, we broke down in our piece on harmonised standards.

The common way to satisfy it is a filter on the server. The server knows who is asking, looks up what they are allowed to see, and returns exactly that subset. The standard asks for nothing more. There is one catch the standard does not concern itself with: the subset arrives without a seal. The reader has to take it on faith that the server selected honestly and changed nothing on the way out. For a public leaflet, fine. For a number a refurbisher is about to price a used battery on, that is a lot of faith.

The obvious fix is to sign the data. For the two ends of the range, a plain signature works well: sign the public view, sign the full record. How that works in detail is in signatures and certificates in the DPP. The middle is where it breaks. A whole-document signature covers exactly the fields that were there when it was signed. Disclose one protected field to an entitled reader and that field sits outside the signed set, arriving uncovered. Nobody signs every possible combination of who-sees-what in advance; the number of combinations explodes. They fall back to the filter without a seal, and the middle tier goes back to running on trust.

Signing each field on its own

There is a better construction, and it is the one we are building the platform on. Instead of signing the finished document as one block, the manufacturer commits to each field independently in a single pass (for the standards-minded, the W3C method ecdsa-sd-2023).

Every view now starts from the same public fields. Whatever a reader gets beyond them is added field by field, and each of those fields still checks back to the manufacturer’s public key, offline, with no re-signing and no trust in whoever assembled the view. The fields they are not entitled to are simply absent. Not blacked out, just not there, and nothing about them leaks.

A walk-through: the repair shop

A repair shop has registered a legitimate interest in a battery, one of the access tiers the EU Batteries Regulation explicitly provides for. Its workshop system signs in to our interface with its key and requests the passport. The response is the same public passport any buyer sees, richer by exactly one field: the dismantling instructions, disclosed only to entitled readers. No second document, no special edition.

Before the shop relies on that field, its software checks the seal that came with the response against the manufacturer’s public key. If the check passes, and it covers the additional field too, the shop knows: these instructions are character for character what the manufacturer wrote, and nobody along the way has changed a thing. If it fails, the shop sets the whole view aside. That the shop receives exactly the fields it is entitled to remains the job of our access control. What is new is the step after: whether what arrived is genuine, the shop verifies itself, without asking us.

Why “unbroken” is the whole point

An intact seal does not say the content is true. It says: this is exactly what the manufacturer wrote, and not one character has changed since. That takes everyone who merely passed the document along out of the trust question: the cache, the network, the archive, us. Who handed you the passport stops mattering.

And a seal is binary. It holds or it does not; there is no half-broken seal. So it is not a difference of degree whether the additional fields reach you with their seal or without it. Without one they are not slightly weaker evidence, they are no evidence at all.

Both methods, side by side

You can check all of this yourself. The Transpareo Time Machine is our open-source viewer for product passports: it leafs through a passport’s version history and recomputes every signature in the reader’s own browser, without asking a server of ours. The passport of a t-shirt carries a whole-document signature; the passport of a battery carries per-field disclosure.

Both are open W3C standards, and anyone can implement them. The whole-document signature is considerably cheaper to build and to run, and for a passport carrying only public data it is enough. That the Time Machine handles both is deliberate: the passport remains an ordinary standard format that any fitting tool can check, not only ours.

Who this serves, and what the standard asks

Who is actually shown anything beyond the public data? Not the casual shopper. It is the refurbisher deciding what a used pack is worth, the insurer pricing a risk, the recycler sorting chemistries, the authority building a case. Readers making decisions with money or safety attached. And under the common approach exactly the readers who get no seal for the fields their decision rests on. We think a verification badge should mean the same thing for all of them: every field shown came from the manufacturer and has not been touched since. A seal that only covers the public fields is half a seal.

We will be straight about this: the standard does not require any of it. EN 18239 asks for access to be controlled, and a filter on the server does that perfectly well. Making the disclosed fields verifiable is something we do on top, because the whole reason a passport is signed is so nobody has to trust the platform. Carving out the middle tier as an exception quietly puts back the trust the signature was there to remove.

The same design lets a field be forgotten

Committing to each field on its own buys a second property, and this one European law actually requires. The General Data Protection Regulation gives people the right to have personal data erased. A record signed as one block cannot honour that without shredding its own signature.

Because each field stands alone here, a single field can be removed while everything else still verifies. If personal data ever lands in a passport by mistake, it comes out cleanly and the passport stays valid: no re-issuing, no broken history. The fields the law tells us to keep stay put; anything erasable can be erased on request, even years later.

Why this is hard, and how we solved it

We did not invent the method; it is a public W3C standard. The hard part is not having the idea. The hard part is building it so that a passport still verifies in ten years. An ordinary signature computes over the bytes of a document. The per-field signature computes over its individual entries, and for that the passport is put into a fixed spelling before signing, in which every entry stands as its own sentence. That spelling has to come out again character for character ten years later, or no seal matches. Three inconspicuous things stand in the way, and we closed all three at the root.

Numbers lose their type. A value like 2.0 comes back as 2 after a round trip through an ordinary data format. The same thing to a human, a different sentence to the fixed spelling. With us every value is stored with its type, and publication aborts the moment a single number without a type turns up.

Names are not yet meanings. Every field name has to lead back to an unambiguous meaning in a dictionary, otherwise the field silently disappears in the conversion and the seal does not cover it. With us every dictionary is held locally and never fetched over the network; an unknown field name stops the signing instead of quietly yielding an empty result.

Entries need fixed names. Every entry in the document carries a fixed identifier with us, so the spelling stays the same on every run instead of handing out fresh placeholder names each time.

The most delicate part sits with the manufacturer’s own key. Each issuance needs an additional, short-lived key that signs the disclosable fields individually. The manufacturer generates and discards that key itself. If we held it, we could invent individual fields after the fact. Every passport carries two such seals, one from the manufacturer and one from Transpareo, for a single disclosed field too.

For us this effort lands in the right place. Every passport is signed on publish and chained to the version before it, and the immutable ten-year archive takes effect as soon as the passports are registered with the EU DPP register. Signing each field instead of the whole block is an extension of that core, not a bolt-on.

Where we stand

We picked the proof, for every reader, because a seal should mean one thing no matter who is looking. If you want to see it work: both example passports linked above verify right in your browser, without asking a server.

Questions on this article

Does any standard require per-field signatures?

No. EN 18239, the European standard for access rights in the DPP, asks for access to be controlled per field, and a filter on the server satisfies that completely. Making the disclosed fields verifiable on top of it is our decision, not a box the regulation makes anyone tick. We think the effort is justified because the whole point of a signed passport is that nobody has to trust the platform. What status these standards carry at all is in our piece on harmonised standards.

We only publish public data. Do we need this?

Probably not, and we will say so. A whole-document signature covers a passport whose fields are all public, and it is considerably cheaper to build and to run. Per-field disclosure earns its keep the moment a second audience appears, a repair network, a recycler or an authority, to whom you would otherwise hand extracts without a seal. Both methods are open W3C standards (ecdsa-sd-2023 for the per-field signature), any tool that speaks the standard can check them, and both run today in the Transpareo Time Machine, on a t-shirt passport and on a battery passport.

Can personal data be erased later without invalidating the passport?

Yes, and this part European law actually requires. The General Data Protection Regulation gives people the right to have personal data erased, and a record signed as one block cannot honour that without shredding its own signature. Because each field is committed to on its own here, a single field can be removed while everything else still verifies, with no re-issuing and no broken version history. The fields the law tells you to keep stay where they are.

Who holds the signing key?

Every passport carries two seals, and one of them can be yours. Each issuance additionally needs a short-lived key that signs the disclosable fields individually; the manufacturer generates and discards it itself, because if we held it we could invent individual fields after the fact. We check the returned seal against the registered public key before trusting it. Every passport therefore carries two seals from two independent parties, for a single disclosed field as much as for the whole record.

Will a passport still verify in ten years?

That is exactly where the effort sits. The per-field signature computes over the individual entries of a document rather than its bytes, so the same fixed spelling has to come out again character for character a decade later. Three things break that quietly, and we closed all three at the root. Every value is stored with its type, every dictionary is held by us and never fetched over the network, and every entry carries a fixed identifier. The immutable ten-year archive is in place and takes effect as soon as the passports are registered with the EU register. More on it in our analysis of the register regulation.

Updates on access tiers and proofs

Selective disclosure, signatures and how the DPP standards are moving - a compact monthly briefing to your inbox.