Guidance on handling 'late arriving' data in the UNTP model

[zachzeus]

There are a couple of scenarios that have been brought up in early trials and discussions where data will be arriving after a DPP hsa been issued. We need to provide implementers guidance on handling and managing these situations.

Examples:

1. A product has a 2nd party conformity assessment done on it (ie a meat processor validating CL score)
2. A product has the customer record the traceability event (ie the timber yard records the arrival of the logs as opposed to the logistics / logging provider)
3. Long - lived product has regular maintenance on it (ie car battery, or vehicle)

There are really 2 options to resolve this:

1. The receiving entity continues to issue new DPP's with the additional data appended to it.
2. The additional data is added to the Identity Resolution endpoint (ie new DPP, DTE, or DCE's ) added to the product identity.

[onthebreeze]

Adding a new DPP does not tell the holder of the older DPP that a new one exists. I think the most scalable solution to this is to consider a "DPP" as a set of credentials that are discoverable from the link resolver end point. Two cases to cater for

1. The new data (eg an updated DPP or a related DCC) is published by the owner of the product ID. So this is just re-using an existing authority to add more data to a link resolver.
2. The new data is from post-sale entities such as a repair centre or a recycling plant. This requires authorisation to update the link resolver. The solution to this one is the job of the UNTP Decentralised Access Control (DAC) specification but, in short, the update either presents a credential proving their authoiresed role or a credential proving they are holding the specific serialised instance of the product.

[onthebreeze]

like did:tdw, we can have the idea of a DPP and a log of changes. This reveals another way to find the list of related post-issue DPP events. One solution is to add multiple records under the same ID in a link resolver. Another is to use a log attached to the DID of the product?

@zachzeus - volunteers to address this- and viginia suggests to deal with it by dealing with a scenario at a time and start with the simplest - eg

• manufacturer issues a post issue event. Easy one because it's their product and they are authorised.
• offical / accredited party makes some repair (use IDA?)
• smallholder delegation to the next (bigger) actor in the value chain to act on their behalf (eg to issue DPP as a proxy)
• Third party repository records post sale events (like the car record thing phil mentioned)
• secret key in the box allows any user who has the key to make certain controlled types of updates.

@philarcher offerred to assist with Zach. Harley keen to assist

https://www.w3.org/TR/did-core/#capability-delegation - may have some relevance? maybe not for the smallholder - because they are delgating due to lack of tech in the first place.

[philarcher]

This is a knotty problem. AIUI the EU regulation will not expect an original DPP to be updated and I'm very sure that, in any jurisdiction, manufacturers won't allow anyone to add to or modify their data directly. Which leads us, yes, to having multiple links in the resolver. But that immediately begs the question: who has the rights to add links to the resolver? If it's operated by the manufacturer the same blockage exists. I can imagine some brands may talk about 'registered repairers' or some such, who would have the right to add data. And Steve points to the secret key on the product itself as a way to prove ownership.

But... in the EU case, the ESPR calls for a backup plan. This is primarily to ensure that the DPP remains available even if the original manufacturer is no longer around. So the plan is that all products placed on the market that require a DPP (over time this will be everything other than food and healthcare) register the identifier in a central registry or network of such (perhaps one per member state). That registry can take a snapshot of the DPP and the latest snapshot becomes the primary DPP if and only if the original company goes out of business.

But it also provides a neutral point in which new/additional DPPs can be registered.

Imagine a washing machine ID of washingmachine.example/01/01234567890123/21/ABC (GTIN + serial). The URI resolves to the original DPP. The GTIN and serial no. are registered in the central system.

The machine is repaired by a third party who is completely unknown to the OEM. They publish data that describes the repair which can be discovered by resolving repair.example/01/01234567890123/21/ABC. But they also notify the centralised register that they have carried out the repair.

If there is literally one central register (boo!) then that's the discovery route. But I think it safer to assume that there will be multiple registers under a variety of jurisdictional regimes.

So another way to achieve "gimme the full DPP for this thing" is to, yes, scan the original and get the original DPP. But... that original DPP includes an attribute of untp:registeredAt which points to the relevant central registry. Now I can get the original DPP and, either manually or through the action of software, discover all the registered additions.

You can see something a bit like this in https://www.carfax.eu. Scroll down and look at the example. None of those garages know each other, there are no business relationships. However, based on the vehicle's ID, that centralised system can find the decentralised data.

WDYT?

[harleyjackthomas]

@philarcher building on that, the paths for resolving all required data are:

The repairer relabels the physical product:

e.g. acme-repairer.com/01/01234567890123/21/ABC

A new QR code label could be applied to the physical product, and scanning this resolves you to a new DPP issued by the repairer.

This DPP references traceability events stipulating the repair, with the ability to resolve the original DPP issued by the OEM. The scanner gets to see repair data and the original manufacturing data.

If the repairer has the physical product to apply the new physical QR code, then no secret key is required, because they physically possess the product.

This doesn't account for "authorized repairers", but they had the product, did the repair, the information is discoverable, and the "scanner" can choose to trust it or not.

The repairer cannot relabel the physical product:

• The repairer is an authorized repairer by the manufacturer, the manufacturer can update the original DPP with the repair information via some B2B communication.
• The repairer submits the repair information to one or more central registries for discovery via the untp:registeredAt attribute. (Does this mean the repairer has to be certified with these registries, how is spam prevented?)
• The repairer has access to some secret key on the physical product, allowing them to publish the repair information to some resolver (really just two options above via another mechanism)

Repairer identifiers support resolving the new DPP:

Product identifiers remain unchanged, and no central registry is updated, but the "scanner" knows some business context information about the repairer that I can go to their resolver and query the GTIN+Lot to find their DPP.

This is applicable for Australian Livestock, if I receive cattle, I would know the PIC (property identification code) of who I received the cattle from (or sent it to!) and can use that to find a resolver for that party, and query the animal ID to get that parties DPP for that animal.

DPPs reference traceability events, which reference other parties PICs, and the "scanner" just repeats the process up and down the supply chain.

Phil, on these proposed central registries, will we not just see a convergence of semi-centralisation? If all DPPs are snapshotted on these registries, as the "scanner" why bother jumping hoops to do the different resolution steps above -I would just go to the registry because I know the data is there?

And would implementers not bother with the hassle of storing DPPs, just push them straight to these registries? Seems like the path of least resistance. Or would it be that these snapshots are only taken at the time the manufacturer went out of business?