Design of the DPP system

First considerations on possible

technical solutions
This presentation reflects DIGIT’s
experience in building decentralised,
federated and centralised systems

Joao Rodrigues Frade – HoS DIGIT.B3

Jose-Manuel Panizo – DIGIT.B3 June 2023
 Agenda

First User
Introduction Considerations Journey Step by Step DPP Storage

+ Getting to know the

team that produced
We need to keep
cost effectiveness
Let’s look into a
possible User
We will explain our
initial design thinking
Before closing let’s
discuss possible
this presentation considerations Journey to discuss around the steps of scenarios for storing
throughout the the design of the the journey the DPP +
presentation DPP
+
 Introduction
Getting to know the

+
team that produced
this presentation

+
+
 A few words about DIGIT.B3, building blocks
We promote the reuse of common solutions based on Open Standards

C2B and C2G ORIENTED Cross-sectorial and G2G B2G – B2B – G2G
IOSS-DR
(TAXUD)

CIXP
ESSPass eFTI
(Council)
(EMPL) (MOVE)
BRIS
(JUST)
EUDI
(CNECT) …
EESSI
(EMPL)
European Blockchain Once Only Technical ICS2
eHealth
Services Infrastructure System (OOTS) (SANTE) (TAXUD)
EUROPASS eBox
(EMPL) (EP)

EPREL
ePROC (ENER)
(GROW)

EU
Blockchain
eFTI
PCP
(MOVE)
Our approach to the creation of an ecosystem

Policy DGs such as DG GROW, DG CNECT and DG ENV focus on hard policy instruments
REGULATING
LEGALLY BINDING RULES

TEACHING DIGIT typically focuses on soft policy instruments (apart the Interoperability Act)
SERVICES

SHOWING a means of delivering value to customers

by facilitating outcomes customers want
HELPING / to achieve without the ownership of
NURTURING
specific costs and risks
Source: ITIL
NUDGING

DOING IT FOR
THEM

DRAGGING
Furthermore, DIGIT is also home to interoperable Europe
Contribution to the DPP with data models, code list & serialisation formats
 First
Considerations
We need to keep cost

+
effectiveness
considerations throughout
the presentation
+
+
 High-level cost-effectiveness considerations
Before going any further let’s keep this design constraints in mind

AFFORDABILITY RELIABILITY ACCOMODABILITY SCALABILITY

How much does the DPP Can it be created on Can it be fit for as many Can it be designed for use
cost, relative to how much demand in as large a sectors as possible by every European
SMEs can spend quantity as needed? consumer
Please keep in mind that this is just the beginning

Please see the next slides as an

opportunity for discussion, this
is work in progress and we will
change and improve most of what
will be shown here today. The
objective is to engage in a
discussion that helps us improve
our common understanding.
 User Step by Step
Journey
We will explain our
Let’s look into a initial design thinking
possible User Journey around the steps of
+ to discuss the design of
the DPP
the journey

+
+
We applied design thinking to a User journey

Basic Data

Even if offline,
a DPP reader Links to DPP
app can show
me
I’m in a shop Control Data
I’m interested I scan the DPP
in a product data carrier

As I’m online, I decide

to fetch the Public DPP

Welcome to the DPP Hosting Website

I’m satisfied and decide to I consult the Public DPP Download DPP
buy the product data on my phone
Let’s decompose the way we thought about the DPP Design
This is work in progress and should not be understood as complete or final

1st Principle. It is important to think about the DPP modularly

Premise. The DPP is not a monolithic dataset, it can easily be split into different datasets. Whereas online
data is easier and cheaper to update, having data offline will make the DPP more usable and easier to consult

This is why we decomposed the DPP in data available offline and data available online

Offline
PART.A.
Basic Data I don’t need to be online as data comes from

PART.B.
Links to DPP
Online
www.
PART.C. I have to be online to access this data
Control Data
Let’s continue to look at our User Story
work in progress, it should not be understood as complete or final

2nd Principle. It is essential to secure the authenticity of the DPP starting with the data carrier

Premise. The data carrier can include information about how to distinguish counterfeits and how to verify the
integrity of the data carrier

A. The Data Carrier can include a link to online resources about how to distinguish an original product from a
counterfeit. This link cannot be removed if the data carrier is copied from the original product.

B. To prevent counterfeiters, creating fake data carriers, a hash function can be used to ensure that the data
carrier is authentic
Hash function can be used to verify data carriers
This User Story will need more work but the basic idea is to use a hash function

Central
Registry
All product unique identifiers

The information that allows the

verification of the authenticity of ✔
the DPP
Hash Function

I visit the online

verification Service I scan the Data Carrier Online Verification Service
calculates hash
The result shows on my
phone
Brands publish information about counterfeit products
If I have the link to it, I can check it

15
 Summary of our design thinking so far

Offline dataset Online dataset Control dataset

Central
Registry
DPP
All data carriers

Scan All product unique identifiers

DPP Public data
Basic Data Elements The information that allows the
verification of the authenticity of
the DPP
Links to DPP data

Control Data Elements Hash Function

Restricted data

Online
counterfeiting
info

Data Carrier
What is the DPP basic data shown in step 2?
Work in progress, it should not be understood as complete or final

3rd Principle. We advocate for accommodative and legacy friendly design

Premise. The DPP should consider the diversity of identifiers and other information already used by economic
operators and accommodate them as much as possible

We suggest using contextual prefixes in every data element of the data carrier to secure interoperability
without the need for harmonisation

The data carrier reader app can ensure a User-friendly display of the data
Example of the data on the Data Carrier itself
PART.A. Basic Data Elements Example based on an urn-like approach Additional Information
Prefix = dpp:<identifierType>
Suffix = identifier
DPP Owner - identifier of the entity that created the DPP 1:1 dpp:did:ebsi:zwC56DZdiJh8kSxbgg4fMCu Possible accepted identifiers for this
field:
EORI, VAT, Company Identifier, DID
Registry Product ID – maximum 70 characters 1:1 dpp:gtin:3234567890126 Possible accepted identifiers for this field:
// identifier of the product registered in the DPP Central Registry (unique GTIN, ISBN, DID, hash of the data carrier
product identifier)
Additional Product ID 0:n dpp:gtin:3234567890134 Possible accepted identifiers for this field:
// additional identifiers associated to the product GTIN, ISBN, DID, hash of the data carrier
Manufacturer: unique operator identifier - identifier of the (main) 1:1 dpp:vat:1234567890 Possible accepted identifiers for this field:
manufacturer GTIN, ISBN, DID, hash of the data carrier
Manufacturing Facility Location : unique facility identifier 1:1 dpp:ISO3166-2:BE Possible accepted identifiers for this field:
// identifier of the location where the product was manufactured ISO 3166-2, NUTS
Product Typology 1:n dpp:CPV:45000000 Possible accepted identifiers for this field:
// information about the type of product CPV

PART.B. Links to DPP Example Additional Information

Link to Public DPP 1:1 www. Persistent URL/ URI
Link to Restricted DPP 1:1 www. Persistent URL/ URI

PARRT.C. Control Data Elements Example Additional Information

Link to information about how to identify counterfeiting 0:1 www. Persistent URL/ URI
Hash of DPP (e.g. Part A of Data Carrier) also registered in the DPP 0:1 f“P$Hv8rpLanTSUSA/2bP1xN.S6Mdk32.55 Standardised hash function
Central Registry
We advocate the use of an URN prefix
Because it enables a modular and legacy-friendly design

DPP is a multi-domain project DPP is a multi-framework project

Legal Entity Product Counterfeit and

identifier information validity

Fashion
Product Ingredients
EORI Counterfeit
Pharmacy identifier (ingredient
information
(GTIN, ISBN, declaration
DID, hash, …) standards)
Medicine
Automotive VAT
Validity
Components Chemicals (revoked or
Appliances (component (chemicals valid)
DID declaration declaration
standards) standard)
Batteries
other
other
Lifecycle Typology
(CPV)
Let’s look into the URN prefix in more detail
We like it because it enables a modular and legacy-friendly design

 URN prefix enables us to support identifiers and claims from different domains and standards
 URNs can be applied to products, economic operators or any other identifier

dpp : type : Identifier

Type prefix could include:

• did : decentralized identifiers
• eori : economic operator identification and registration number
• vat: value added tax
• hash: output of a cryptographic function to digital information
• gtin: global trade item number
• isbn : international standard book number
What about the links to the DPP itself in step 3?
Work in progress, it should not be understood as complete or final

4th Principle. We advocate for comparing different approaches to the DPP links

Premise. There are a spectrum of options when it comes to the design of the links which will lead to the
download of the DPP

We suggest comparing at least 3 approaches to the management of the links and eventually to test them
before choosing
Let’s decompose the DPP resolution
To better understand it

Our main design objectives

• Avoid broken links (URLs or domains that stop working)
• Adaptable to current / potential standards, industry rules and business models
• Ensure business continuity : availability of DPP even if companies terminate

Link to DPP => dpp : type : Identifier

QR Code Product Identifier Resolution DPP

Defined by the type

(URN)
Now, let’s look into the resolution of a DPP

There are at least 3 approaches

OPTION A: Flat URL, pointing directly to the DPP

• Potential broken links
• Can be self-hosted or provided by third parties

OPTION B: Identifier specific resolution : GS1, ISBN or DID

• A list of resolvers should be managed and maintained
• Can only be provided by third parties

OPTION C: Content Addressable Storage Resolution via e.g. IPFS

• A single resolver is needed to be maintained
• Can be self-hosted or provided by third parties
What do we need to resolve an identifier?
Several components are required to resolve an identifier

Identifier - URN Identifier resolver Resource

A Uniform Resource Name (URN)
is a unique sequence of characters
that identifies a logical or physical
resource used by web
technologies. URIs may be used to
identify anything.
Examples: URL, DID, CID
Identifier resolvers are responsible
for identifying services responsible
for the identifier.
For example, DNS resolver identifies
the domain servers responsible for
the domain.
Resource is the content to
which the identifier is resolved.
For example, URL is resolved
by DNS resolver to the
webpage resource.

URI Resolver Content

EBSI.EU DNS Resolver Website (HTML)

did:ebsi DID Resolver DID Document

 Let’s look into some examples
To understand how different resolutions would work in practice

Flat Link Product HTTP URL DPP

https://dalgiardino.com/risotto-rice-with-mushrooms/

Product DID DID Resolver DPP

Identifier- Product GTIN GTIN Resolver DPP

specific resolution
9506000134352 https://id.gs1.org/01/9506000134352 https://dalgiardino.com/risotto-rice-with-
mushrooms/

Product ISBN ISBN resolver DPP

Content Addressable Product Content ID CID resolver DPP

Storage
Resolution
 DPP Storage
Before closing let’s
discuss possible
scenarios for storing

+
the DPP

+
+
Let’s look into the DPP storage and management

Data Storage
Centralised hosting Federated hosting Decentralised hosting
vs.
DPP data Management

Centralised service

Federated services/
Based on Service Providers

Decentralised services/
Self-Sovereign

(*) DPPaaS: DPP as a service / DPP service via a Service Provider

Design thinking around different scenarios
Discarded Not discarded

Data Storage
Centralised hosting Federated hosting Decentralised hosting
vs.
DPP data Management

Option A
Centralised service All DPP data in the
Central Registry

Option D
Accredited
Federated services/ Option B
National Authorities
Private
Platforms
Based on Service Providers provide DPP service
provide DPP
service

Option C
Decentralised services/ Economic Operators self-
manage and self-host their
Self-Sovereign DPPs

(*) DPPaaS: DPP as a service / DPP service via a Service Provider

Taking it to the next level by mixing scenarios
Discarded Not discarded

Data Storage
Centralised hosting Federated hosting Decentralised hosting
vs.
DPP data Management

Option A
Centralised service All DPP data in the
Central Registry

Option E (hybrid)
Option D
Like Option C&D. Self-hosted
Accredited
Federated services/ Option B
National Authorities
Private
DPPs must be registered into
Federated DPPaaS* providers
Platforms
Based on Service Providers provide DPP service
provide DPP
for validation and redundancy.
DPP Resolution through
service
DPPaaS link for versioning

Option C
Decentralised services/ Economic Operators self-
manage and self-host their
Self-Sovereign DPPs

(*) DPPaaS: DPP as a service / DPP service via a Service Provider

 Example of Option E – Self-hosted DPP & Federated verification

DPP issuer DPPaaS - Federated User

1 Onboard

2 Enrol and share access credentials

2 1
Get latest Scan QR
1 create DPP URI
1 validate

DC and DPP Trusted versioned Data carrier

DPP 3 register validator list of DPPs (DC)
Data carrier
Public (DC) DC and
data DPP URI
Accept
3 and store store for 3
Download
Restricted 2 redundancy
DPP
data

Federated Storage
medium
2 store
Self-host data

Decentralised and distributed storage layer

Decentralised storage client Decentralised storage client Decentralised storage gateway

Thank you!
Contact us

Joao Rodrigues Frade

European Commission, Directorate-General for Informatics

© European Union, 2023. All rights reserved. Certain parts are licensed under
conditions to the EU.
Reproduction is authorized provided the source is acknowledged.