Include link from DPP to a backup registry?

[philarcher]

We touched on the idea of a central registry, or registries, for DPPs during the call on 14-15 August. The idea of a regulator's registry is all about data persistence. There needs to be a copy of the DPP that is independent of the manufacturer who creates it. This also has positive implications for third party repairers who have no business relationship with the manufacturer but who nevertheless need to publish details of the repair/replacement that have carried out. They can register that they have relevant data in the same registry.

Both of those use cases might be addressed if the DPP includes a term that points to a registry (or possible registries) where the DPP is also located. In normal operation, an app can get the DPP from the manufacturer and check the registry to see if there's any more data about the item.

If the manufacturer goes out of business, it's possible to use a registry's Web app to scan the original QR Code but still find the DPP in the registry's archive.

I can offer a rough demo of this.

[harleyjackthomas]

@philarcher I left a comment here on another issue:

https://github.com/uncefact/spec-untp/issues/139#issuecomment-2303313213

Do you think this would converge to too much centralisation? As the scanner, why would I bother going to the manufacturer's resolver, and instead just go to the central registry for information. Similarly, would solution providers bother to store and make DPPs resolvable, and instead just rely on pushing to these central registries.

Happy to continue the discussion on this issue, or on #139

[onthebreeze]

I suspect that commercials might have a big impact here.

Who pays for the central/archive copy? If the manufacturer then the payment stops when the manufacturer goes out of business - which defeats the purpose of the archive copy. So there's probably no solution other than the regulator that demands it pays for it. I would expect that some rational thinking would lead to a conclusion that only very durable products (eg building materials) would need this kind of backup storage. Even then probably only a minimal mandatory subset of data would get pushed to central archives. Commercial industry that is not out of business will always be incentivised to have richer / better data on their own systems than on the central archive.

Whilst a backup archive for durable products makes some sense, I think that the other reason the EU wants a central register (for public search) will likely become practically and commercially infeasible. It'll be much more expensive to run search on top of an archive and the implementation will never be even close to being as good as commercial search engines. So a better solution to the search / discovery problem is just to make the archive metadata indexable by commercial search.

All this is to say that a link-type to an authoritative archive is probably pretty straightforward and is very unlikely to become the default user experience. Commercial incentives wont let that happen. The manufacturer will want to own the experience as much as possible and the archive service provider will want to minimise costs.

So this really leaves the question of how post-sale events get recorded. I agree with @philarcher that manufacturers are not going to let any unknown randoms update their product information except in very controlled (content-wise) circumstances. And I think @harleyjackthomas provides some reasonable scenarios in #139. I think there are three patterns

1. Delegated proxy.

This is where a producer essentially transfers rights to maintain DPP data to another party. Big brands wont do this but there could be many cases where smaller organisations do. For example the small-time cattle farmer transfers rights to maintain data about a cow when it is sold to a bigger farmer or a feedlot. This would require an out-of-bounds delegation of rights to update the authoritative register. In the AU cattle example that means a farmer that issued the ID of the cow (RFID tag in ear) grants authority to the feedlot that bought the cow the rights to update the national registry entry for that animal. The registry operator would then allow the feedlot to update the link register to point to anywhere the "new owner" wants.

2. Narrow rights.

In this case the producer maintains ownership of the registry entry and all link types but grants very specific narrow rights to third parties like repairers. For example, adding repair event link types to the register.

3. No rights.

In this case there are no circumstances in which any post-sale actor can update anything related to the identifier owned by the manufacturer. In this model, a repair event can only be recorded quite separately in a totally separate register like @philarcher's https://www.carfax.eu/ example. And for that information to be discoverable by the next repairer, most likely there would need to be an extra label attached to the item which would either be a QR that takes the user directly to the repair event, or a QR that takes the user to the third party register which then prompts the user to scan the original label.

In a UNTP specification sense, options 1, 2, and 3 above feel like just different permissions delegated - from everything to nothing and various options in between. Does this all boil down to how an identifier owner delegates authority to others to make updates to links in the default identity resolver?