Open Standards vs Proprietary Passport Formats

Every vendor in this category will tell you they support open standards. Most do, partially, and the interesting question is what happens to your data at the boundaries where they do not.

The comparison is worth making honestly, because proprietary approaches have real advantages and pretending otherwise makes the argument for standards less credible rather than more.

What is actually being compared?

Not usually the whole system. Almost every implementation mixes both: a standards-based identifier with a proprietary data model, or a standard event format inside a closed platform. The question is which layers are open.

The last row is the one that decides portability in practice. If the identifier only resolves through one company’s service, everything above it is effectively proprietary regardless of the formats used internally.

Where proprietary genuinely wins

1. Speed to first passport, because there is no standards mapping to do.
2. Features ahead of standardisation, since committees are slower than products.
3. Internal use cases, where nobody outside the organisation reads the data.

The second is a real and recurring advantage. Standards lag practice by design, and a vendor solving a problem today will do it in their own model because there is nothing to conform to yet. Refusing anything non-standard means waiting.

Where open standards win

Wherever someone outside your commercial relationships has to read the data, which for a passport is the entire point. A recycler, a market surveillance authority, a second-hand buyer and a customer’s customer all read passports and none of them will integrate with your vendor.

They also win on duration. A passport for a building product or an industrial machine must resolve in twenty years, and the probability that a given software company still operates a given endpoint over that horizon is not high enough to design around.

What the regulation pushes toward

Regulation (EU) 2024/1781 requires interoperability and open standards for the passport, and the CEN-CENELEC work exists to specify what that means technically. That reduces the question from a preference to a compliance matter over time.

It does not resolve it immediately, because the standards are unfinished. In the interim the defensible position is to use the underlying standards that clearly will be composed — GS1 identity, EPCIS events, W3C credentials — and to treat anything above them as replaceable.

The test question for a vendor

Ask whether your identifiers resolve under your own domain, and whether a third party can retrieve a passport without a relationship with the vendor. Those two questions separate real portability from claimed portability faster than any feature comparison.

A vendor whose answer is yes to both has made the architectural choices that let you leave. One whose answer is no has built something that works well and holds your product identity, which is a considerably larger commitment than a software subscription.

What about cost?

Standards-based implementations are usually more expensive to start and cheaper to change. Proprietary implementations invert that, and the crossover point depends on how long the product lives and how many external parties read the record.

For a fast-moving consumer product with a two-year life and no external readers, proprietary may genuinely be the right economic answer. For anything with a service life measured in decades, it almost never is.

What happens when a vendor is acquired?

This is not a hypothetical in a young software category. Consolidation is normal, and an acquisition changes roadmaps, pricing and sometimes the continued existence of a product. None of that is a problem for a tool you can replace.

It is a serious problem for a resolution service. If your product identifiers resolve through a domain the acquirer now controls, every code printed on every product you have ever shipped depends on a commercial relationship you no longer chose. Renegotiating from that position is not a negotiation.

Resolving under your own domain removes the exposure entirely, and it is a decision that costs almost nothing at the start and cannot be retrofitted to product already in the field.

How does this affect suppliers and customers?

A passport programme reaches beyond your own systems. Suppliers submit evidence into it and customers consume data out of it, and both are affected by the format choice even though neither made it.

A supplier asked to submit into three customers’ proprietary portals will do it badly, because each is a separate integration with a separate model. The same supplier asked for a signed credential in a standard format can produce one artefact that satisfies all three, which materially changes response rates.

That is a practical argument rather than an ideological one. The reason standards improve supplier data quality is not that they are open; it is that they let a supplier do the work once.

What does migration actually involve?

Moving between platforms is straightforward for records and hard for identity. Product data can be exported, transformed and loaded, which is a project with a known shape and a known cost.

Identity cannot be moved the same way. Codes are printed on products in warehouses, in retail and in customers’ hands, and they point wherever they were made to point. If they point at a vendor domain, migration means either persuading that vendor to redirect indefinitely or accepting that everything already shipped is stranded.

This asymmetry is the single most useful thing to understand before choosing. Data portability is a feature you can evaluate; identity portability is an architectural property you either have from the first printed code or never have at all.

A pragmatic position

• Insist on open identity and resolution, because these are the hardest to change later.
• Accept proprietary tooling above them, since tools are replaceable and identity is not.
• Require that data export uses a standard model rather than a vendor schema.
• Check that events and claims are expressible in EPCIS and W3C formats even if stored otherwise.

This is the position most large programmes converge on. It concedes the vendor’s genuine advantage in tooling while keeping the two layers — identity and resolution — that determine whether the passport is yours or theirs.