The webinar present topics that are part of the "Disruptive Tech and Trends" track where participants will discover about how FIWARE is positioned with regards to relevant technological areas: How to build Data Spaces, as decentralized data ecosystems, using commonly agreed building blocks ensuring Data interoperability, Data Sovereignty & Trust and Data Value Creation. How Digital Twins and cloud-to-edge continuum can be implemented with FIWARE components, using the NGSI-LD standard, and present real Digital Twin use cases How to integrate robotics and automation systems in FIWARE based digital twins How data works on your business using Artificial Intelligence and Machine Learning (AI/ML) with FIWARE and data engineering tools and techniques, such as ML-OPS.

1. FIWARE: Marketplace and Data Publication functions
Juanjo Hierro
CTO
FIWARE Foundation
juanjose.hierro@fiware.org, @FIWARE

2. Data Services Marketplace and Data Publication functions
▪ Generic Enablers (and baseline standards):
• BAE/Marketplace: TM Forum APIs
• Idra: DCAT, DCAT-AP
▪ Foreseen activities:
• Alignment with latest version of DCAT/DCAT-AP and TM Forum specs
• Evolution of marketplace functions in line DSBA Technology Convergence
• Alignment with some Gaia-X specs (e.g., service descriptions based on VC)
• Support to Marketplace federation based on shared catalogue of products and
product offerings (DOME)
• Integration with Trust Anchor and Decentralized IAM
• Integration of Data Publication and Data Service Marketplaces functions
▪ Related projects/initiatives:
• Data Spaces Support Center and other DS CSAs under DEP
• DOME project
• Data Spaces Business Alliance (DSBA) Technology Convergence
• TM Forum
• Living-in.EU / OASC (evolution of MIM-3)
1

3. Marketplace functions: basic concepts
2

4. TM Forum APIs for Marketplaces - Model (more details here)
3
Service
Candidate
Product
Resource Service
Service
Inventory
Resource
Inventory
Product
Inventory
Resource
Candidate
Resource
Catalog
Resource
Specification
Service
Catalog
Product
Offering
Product
Catalog
Product
Order
Party
Service
Specification
Product
Specification
1 … *
1 … *
1 … *
includes
includes
includes
includes
includes includes
refers to
1 … *
appears in 0 … *
issues
0 … *
performs
0 … *
1 … *
1 … *
comprises comprises
is realized by
1
1 … *
1
made available through
1
1 made available through
1
1
is realized by
1 … *
1 … * 1 … *
is implented by
0 … *
is implented by is implented by
when completed leads to creation of
1 … *
offers
0 … *
Provider
Consumer
provides provides
1 … *
1 … *
1
refers to
1
1 … * 1 … *
Usage
1 … *
1 … * 1 … *
1
1
1
Resource
Order
Service
Order
1 … * 1 … *
1 … *

5. TM Forum APIs for Marketplaces - Model (Simplification)
4
Product /
Contract
Resource Service
Resource
Specification
Product
Offering
Product
Catalog
Product
Order
Party
Service
Specification
Product
Specification
1 … *
includes
refers to
1 … *
appears in 0 … *
issues
0 … *
performs
0 … *
1 … *
1 … *
comprises comprises
is realized by
1 … *
1
is realized by
1 … *
is implemented by
0 … *
when completed leads to creation of
1 … *
offers
0 … *
Provider
Consumer
provides provides
1 … *
1 … *
1
refers to
1
1 … * 1 … *
Usage
1 … *
1 … * 1 … *
1
1
1
is implemented by is implemented by
1

6. Main entities/concepts
▪ A Product Catalog is a collection of Product Offerings intended for a set of specific Distribution
Channels and Market Segments.
▪ A Product is created in the Product Inventory when a Product Offering is procured by a Party
(customer or other interested party). This means that a Product Order has been issued and
successfully completed.
▪ A Product is realized as a combination of Services and/or Resources which get instantiated in a
Service Inventory and a Resource Inventory, respectively. Resource Orders and Service
Orders are derived from a Product Order for that purpose.
▪ A Product Offering comprises:
• the Product Specification, including characteristics of the derived products
• the Agreement that governs usage of derived products,
• the associated Product Offering Price,
• etc
▪ Note that a Product is what is generated when a Product Offering is procured for a specific
customer, that is, a Product is the instantiation of a Product Specification but in connection to a
specific agreement, price, etc for the customer
5

7. Main entities/concepts
▪ A Product Specification includes references to a series of Service Specifications
and/or Resource Specifications required to realize the Products linked to the
Product Specification:
• each Service Specification is made available through a Service Candidate in the
Service Catalog
• each Resource Specification is made available through a Resource Candidate in a
Resource Catalog
▪ Note that here may be one or more Product Offerings around the same Product
Specification (e.g., associated with different prices or targeted to different market
segments).
▪ Each time a Product, Resource or Service is used, a Usage entity is created, which
typically is used to calculate how much can be charged to consumers and paid to
providers.
6

8. Federated marketplaces: the DOME project
7

9. DOME technical vision
▪ DOME will take the form of a shared digital
catalogue of cloud and edge services made
available through:
• the global DOME portal; or
• federated marketplaces
▪ A federated marketplace can be a:
• Marketplace connected to an IaaS provider,
which comprises a catalogue of cloud and edge
data/app services which customers can pick
and then easily deploy on top of the provided
infrastructure
• Marketplace connected to a Platform
provider which comprises a catalogue of cloud
and edge data/app services which customers
can pick, easily activate and run integrated with
the rest of data/app services already running
integrated with the provided Platform.
• Independent Marketplace, which comprises a
catalogue of cloud and edge data/app services
not tied to an IaaS or Platform provider
8

10. Alignment with TM Forum Open APIs and Gaia-X
▪ DOME relies on a subset of TM Forum Open API
recommendations with regards to the definition of its underlying
information model as well as APIs supporting:
• storage of information about products (= services and supporting
resources instantiated for a particular customer), product specifications
and product offerings
• storage of logs along during procurement and usage of products
▪ Product specifications and product offering descriptions are made
available as Verifiable Presentations (= set of Verifiable
Credentials) defined according to Gaia-X specifications
• VCs issued by certification agencies describing compliance with
certain regulations/recommendations (e.g., GDPR, low carbon)
• VCs issued by certification agencies on compliance with certain
standards (e.g., NGSI-LD, support of standard data models)
• VCs describing roles (claims) that are meaningful to assign to service
users and policy rules that are defined on roles and other environment
attributes
• etc
9

11. Verifiable Credentials
▪ W3C Verifiable Credentials is an open standard
for digital credentials
• can represent information found in physical
credentials as well as new things that have no
physical equivalent, such as ownership of a
bank account.
• work as “badges” in the physical world
▪ Cryptographically secure, tamper-resistant and
instantaneously verifiable
• uses digital signatures
▪ Privacy respecting
• can be sent and received peer-to-peer
▪ Machine-verifiable
• uses JSON-LD data format
10
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "0892f680-6aeb-11eb-9bcf-f10d8993fde7",
"type": [
"VerifiableCredential",
"ComplianceCredential"
],
"issuer": {
"id": "did:elsi:VATBE-0762747721",
"name": "DOME Trusted Entity"
},
"issuanceDate": "2023-05-11T23:09:06.803Z",
"credentialSubject": {
"id": "did:elsi:VATDE-309937516",
"NGSI-LD": {
"type": "EndpointCompliance",
"name": "Endpoint is compliant with NGSI-LD "
}
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2023-05-17T15:25:26Z",
"jws": "eyJhbGciOiJFZERTQYjY0Il19..nlcAA",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://pathToIssuerPublicKey"
}
}

12. Verifiable Credentials
▪ W3C Verifiable Credentials is an open
standard for digital credentials
• can represent information found in physical
credentials as well as new things that have no
physical equivalent, such as ownership of a
bank account.
• work as “badges” in the physical world
▪ Cryptographically secure, tamper-resistant
and instantaneously verifiable
• uses digital signatures
▪ Privacy respecting
• can be sent and received peer-to-peer
▪ Machine-verifiable
• uses JSON-LD data format
11
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "0892f680-6aeb-11eb-9bcf-f10d8993fde7",
"type": [
"VerifiableCredential",
"ComplianceCredential"
],
"issuer": {
"id": "did:elsi:VATES-3782747521",
"name": "ACME GDPR Certification Body"
},
"issuanceDate": "2023-05-11T23:09:06.803Z",
"credentialSubject": {
"id": "did:elsi:VATDE-309937516",
"DataService01": {
"type": "ServiceGDPRCompliance",
"name": "Compliance of a specific service with GDPR"
}
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2023-05-17T15:25:26Z",
"jws": "eyJhbGciOiJFZERTQYjY0Il19..nlcAA",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://pathToIssuerPublicKey"
}
}

13. Federated marketplaces: How they would work
12

14. Marketplaces federation + Shared Catalogue (Architecture)
13
The DOME Distributed Persistent Layer manages
storage of, and access to, information associated with:
● the Shared Catalogue of Product Specifications
(including the specifications of associated services
and supporting resources) and Product Offerings
defined by service providers
● Product Orders and Product (instances of Product
Specifications) along their lifecycle, as well as
information about actual Usage of Products
The DOME Distributed Persistent Layer will be
implemented on top of a number of
interconnected national blockchains (starting
with Alastria and HashNet) compatible with the
European Blockchain Service Infrastructure
(EBSI) when not directly EBSI

15. Registration of product specification
14
● registration of product specifications translates into
creation of product specifications entities according to
the DOME information model (TM Forum compliant)
● operations can be performed through APIs exported
by DPL access nodes or the DOME portal (which in
turn rely on its corresponding DPL access node)

16. Registration of product specification (cont.)
15
● VPs linked to product specification descriptions
following Gaia-X specifications are also generated and
stored on the blockchain
● Some VCs in the VP linked to product specification
descriptions should be issued by trusted issuers that
DOME has listed. Registration of a product
specification may be rejected if a certain VC is not
present or cannot be verified

17. Creation of Product Offering
16
● registration of product offerings translates into creation
of product specifications entities according to the
DOME information model (TM Forum compliant)
● operations can be performed through APIs exported
by DPL access nodes or the DOME portal (which in
turn rely on its corresponding DPL access node)
● VPs linked to product specification descriptions
following Gaia-X specifications are also generated and
stored on the blockchain

18. Creation of Product Offering (cont.)
17
● the service provider establishes as part of a given
product offering description conditions linked to
visibility through federated marketplaces
● its up to a marketplace provider to decide whether to
incorporate a given product offering: they may also
require verification of certain VCs (e.g., compliance
with concrete standards required by platform provider)
beyond those that are mandatory for DOME

19. Product offering discovery
18
● customers can discover product offerings through a
federated marketplaces or the DOME portal
● in some cases, despite discovery can take place
through the DOME portal, the data/app service
provider may establish that procurement has to be
performed through marketplaces of its choice - in
that case, DOME will facilitate navigation of the
customer to the corresponding portal

20. Product acquisition (through federated marketplace)
19
● acquisition of products can be performed through the
DOME portal or the portal of some of the federated
marketplaces
● in both cases, creation of a product order entity is
issued into the DPL layer using TMForum APIs

21. Product activation (product becomes available for use)
20
● procurement can be a relative complex process,
overall if it requires activation of resources (e.g.,
deployment of IoT devices) - a workflow will be
typically implemented
● once the procurement order is successfully completed
a product (instance of the product specification for the
demanding customer) is created and this is notified to
the generating marketplace (federated or DOME)

22. Product usage
21
● once everything is ready, client applications of the
customer can start using the service
● from time to time, the data/app service provider
generate usage logs (another entity in DOME
information model) using TMForum APIs
● billing may be generated relying on DOME

23. Decentralized DOME Persistence Layer
22

24. Service Provider
Marketplace
Storage
Backend
Connector
TMForum -
API
Connector
TMForum -
API
Storage
Backend
Storage
Backend
Connector
Access Nodes - Technical Overview
23
TMForum APIs will serve as
standardized entry points for
the access nodes
The connector listens for
relevant changes in the
storage backend
Connector writes relevant changes
as events to the blockchain
Blockchain replicates the
events through all nodes
Connector subscribes to
change events
Connector retrieves the actual
data through standardized
API from the storage backend
Connector creates/updates
data in the storage backend

25. Access Node
Connector
TMForum -
API
NGSI-LD
API
Access Nodes - Service Provider
▪ Service Providers connect to the Federated
Marketplace through the Access Node
▪ Access Node offers TMForum-APIs to manage
Services/Product/Offerings
▪ APIs can be used through (non-standardized)
provider specific components
▪ the Storage Backend offers the stored entities
through a standardized API
▪ the Storage Backend notifies the connector on
relevant changes
▪ the Connector creates an Event from the change,
persists it to a Blockchain Node
24
Storage
Backend
Application Layer
Security Layer
Blockchain
Node

26. Service
Provider
Access Node
Connector
TMForum -
API
Access Nodes - Marketplace
▪ Subscribes to Events on the Blockchain Node, filters for
Events of interest
▪ retrieves the actual Entity connected to the Event from the
Service Provider
▪ validates the Entity, stores it in the Storage Backend
▪ Services/Products/Offerings are made available through
the TMForum APIs, can be accessed through provider
specific components
Joining the Federated Marketplace:
▪ Blockchain Node contains the complete (immutable) Event
History
▪ Connector processes the complete history, retrieving the
last Event for each Entity
▪ Connector retrieves and stores the Entities from the
Service Provider
25
Storage
Backend
Application Layer
Security Layer
Blockchain
Node

27. Access Nodes - The Event
▪ Event as the central object for replicating information through the
Federated Marketplace
▪ follows the “minimal event”-pattern:
• just contains the event-type, timestamp and data location + filter
relevant meta-data
• reduces data stored on the blockchain to lower transaction costs and
storage consumption
• reduces publicly visible data - allows to apply additional security
measures
▪ the concrete meta-data to be applied needs to be specified,
probably included:
• hash of the entity - allows the marketplace to validate consistency,
allows auditing
• type of the entity - supports filtering on the Marketplace side
▪ potential to batch multiple events on the Service Provider side -
further reduces transaction costs
▪ Event Model needs to be carefully designed, will be the central
information-exchange schema
26
Service Provider
Marketplace
Storage
Backend
Connector
TMForum -
API
Connector
TMForum -
API
Storage
Backend
Storage
Backend
Connector

28. Security Layer
Access Nodes - Security considerations
Data Integrity
▪ every transaction on the Blockchain is signed by the
Service Provider - Eventsource can be verified
▪ the Events contain a Hash of the corresponding entity -
integrity of the entity can be verified by the Marketplace
after retrieval from the Service Provider
Information Leakage
▪ Events do not contain the actual data - limited information
visible through the Blockchain
▪ actual Data will be retrieved from the Service Provider - an
additional Security Framework can be applied, if necessary
Auditing
▪ Blockchain as immutable store of Entity-Hashes allows to
audit the Entity-History
27
Service
Provider
Blockchain
Node
Market-
place
Service Provider
Marketplace
<GET Entity>
<GET Entity>
Event: <...,Entity-Hash,..>

29. Access Nodes - Security considerations
Policy Distribution
▪ Policies can be seen as a specific kind of data - can
be distributed through the same mechanisms
▪ Events corresponding to Policies will be published
to the Blockchain, concrete Policy gets retrieved
from the Storage Backend
▪ Policies can be applied on the Marketplace’ Access
Control Layer
28
Marketplace
Service Provider
Blockchain
Node
<GET Policy>
Access Node
Connector
Storage
Backend
Policy
Registry
Access
Control
Layer
TMForum
API
User

30. Some additional roadmap questions to analyze
29

31. Additional roadmap questions
▪ How to integrate Data Publication and Marketplace
functions
30

32. http://fiware.org
Follow @FIWARE on Twitter
Sounds nice? - Contact us!
Juanjo Hierro
FIWARE Foundation CTO
juanjose.hierro@fiware.org