FIWARE Data Space Components

Jesús Ruiz

Acting CTO

FIWARE Foundation

jesus.ruiz@fiware.org, @FIWARE

About FIWARE

• FIWARE Mission: to build an open sustainable ecosystem around public, royalty-free and implementation-driven software platform standards that will ease the development of Smart Solutions in multiple sectors:
• contributing to creation of standards when they do not exist
• solving how standards can be integrated
• Together with members of the FIWARE Community, FIWARE Foundation actively participate in relevant bodies trying to drive/influence direction based on open source implementation experience: ETSI, IDSA, Gaia-X, …
• FIWARE related standards for digital twins data management are being used by organizations to break information silos and become smart organizations adopting a system of systems approach
• FIWARE related standards have become de-facto in smart cities worldwide
• adoption is growing in other domains (mobility, destinations, ports, water, energy, agrifood, …)
• Data Spaces: the next natural step in digitalization following a Digital Twin based system of systems approach

​

​

​

​

1

Systems view of Data Spaces

2

Evolution of Data Space Connector concept

• The concept of Data Space Connector has evolved to match the idea of an integrated suite of components every organization participating in a data space should deploy to “connect” to the data space
• These components would be deployed and configured in controlled environments (e.g., a Kubernetes cluster) and implement a number of services which may be required for an organization to connect in its role as provider of data services, consumer of data services �or both:
• Authentication (including the interface to trust services)
• Authorization (policy enforcement)
• Connection to Data Exchange APIs
• Data resources publication (Metadata Management)
• Contract Management
• Logging
• Remote Attestation
• …
• The concept of Data Space Connector in IDS RAM 4.0 has evolved to support this vision

3

Alignment with DSBA TC recommendations and EU Digital ID regulations - what it means for Data Space Connectors

• Aligning with DSBA TC recommendations means:
• Interface with Trust Services should align with EBSI specifications (DID-Registry, Trusted-Issuers-Registry APIs but extended to support authentication based on VCs)
• Authentication should be based on W3C DID + VC/VP standards and SIOPv2/OIDC4VP protocols and implement the interface to trust services
• Authorization should implement a P*P architecture implementing ABAC using ODRL as policy language
• IDS Dataspace Protocols considered as relevant input
• Compatibility with NGSI-LD as data exchange API
• First two points → compliance with EU regulations
• How to implement Contract Management is under analysis but the path to go is clear for us:
• TM Forum APIs should be adopted as basis for new IDS protocol for Product Ordering
• Current IDS Contract Negotiation Protocol should be renamed and focused as Policy Negotiation Protocol

4

4

FIWARE Data Space Connector

​

• A first release of FIWARE Data Space Connector components together with recipes for deployment was released September 2023 combining components already aligning with DSBA TC recommendations:
• Context Broker technology for Data Exchange/Transfer
• Trust and IAM components implementing W3C DID + VC/VP standards, SIOPv2/OIDC4VP protocols and interface to trust services based on extended EBSI APIs (DID-registry, Trusted Issuers Registry)
• BAE modules implementing TM Forum APIs for product ordering
• Very soon:
• Idra product from Engineering as DCAT-compliant data resources catalog function for Metadata Management → aligning with IDS Dataspace Protocol
• Transfer Control Protocol → aligning with IDS Dataspace Protocol
• For future releases, following modules will be incorporated:
• Personal Data Consent Management modules (based on CaPE product from Engineering).
• logging modules based on either BAE/marketplace functions for logging or, if we want to rely on blockchain, Cannis Major
• The FIWARE Data Space Connector is the best DSC aligned with DSBA recommendations and EU regulations available in the market

5

https://github.com/FIWARE/data-space-connector

Lowering barriers for connecting to Data Spaces

• Organizations already using FIWARE (sometimes provided as a Service) for the integration of systems will be able to connect to Data Spaces just activating FIWARE Data Space Connector components:
• making owned digital twin data visible to third parties
• importing digital twin data and systems from third parties
• SMEs and small public administrations not yet using FIWARE can rely on “Data Custodian” SaaS solutions that:
• deploy a FIWARE Context Broker instance for managing access to data of the organization in a standard manner (NGSI-LD, smart data models)
• bring tools for easily integrating business support systems of the organization with this Context Broker instance
• deploy a FIWARE Data Space Connector for bringing access to the Context Broker and configure the access policies to be enforced as well as contract terms and conditions (including pricing)
• A FIWARE DSCaaS Testing and Experimentation Facility able to work with iSHARE satellites and GXDCHs has been developed and will be offered to DIHs as tool for evangelization and coaching

6

Main take aways

• FIWARE has a good track record in moving from vision to execution, making things happen!
• We shall not re-invent the wheel: leverage relevant open standards and be compatible with EC regulations
• DSBA brings all relevant organizations joining forces: �BDVA, FIWARE, Gaia-X, IDSA … together !!
• The FIWARE Data Space Connector accelerates the creation of data spaces aligning with DSBA Technology Convergence recommendations and EC policies on Digital ID
• FIWARE Foundation offers to lead incorporation of new IDS Dataspace Protocols that are required: Authentication, Authorization, Product Procurement/Ordering
• Combining FIWARE Context Broker technology and Data Space Connector technology as a Service, it is possible to create SaaS solutions easing involvement of SMEs in data spaces

​

​

7

Sounds nice? - Contact us!

Jesús Ruiz

Acting CTO, FIWARE Foundation

jesus.ruiz@fiware.org

http://fiware.org

Follow @FIWARE on Twitter

FIWARE Data Space Connector brings the opportunity to implement data space following DSBA and EU Digital ID recommendations

​

• Aligning with DSBA Technical Convergence (TC) recommendations means incorporating support to dataspace protocols following open industry standards:
• Authentication based on W3C standards (DID+VC) and OpenID protocols (SIOPv2, OIDC4VP, OIDC4VCI)
• Interface with Trust Services based on EBSI specifications
• Authorization based on ABAC model and ODRL as policy language
• Marketplace functions based on TM Forum APIs
• Existing IDS Dataspace Protocols for Catalog and Transfer Control
• First two points are required for compliance with EU regulations
• A first release of FIWARE Data Space Connector components together with recipes for deployment was released September 2023 including components already aligning with DSBA TC recommendations
• The FIWARE Data Space Connector is the best DSC aligned with DSBA recommendations and EU regulations available in the market

9

https://github.com/FIWARE/data-space-connector

What is a data space?

• A data space can be defined as a data ecosystem built around commonly agreed technology building blocks for:
• Data Interoperability: all participants exchange data using agreed APIs (protocols and data formats)
• Trust and Sovereignty on Data: trust of parties accessing data services can be verified, digital identity can be managed in a decentralized manner (each organization managing its own users) and there is a common approach how authorization policies can be defined and enforced
• Data Value Creation: Publication and Discovery of data services offerings as well as negotiation of contracts follow common standards
• A data space also requires governance: definition of a number of business, operational and organizational agreements every participant adhere to and existence of a governance body
• Many of these building blocks can be defined to work for multiple application domains → data spaces are not only valuable for building an ecosystem around providers of organizations in a given application domain (e.g., smart cities) but an ecosystem where organizations can offer services each other and together develop new data value chains

​

10

Data Spaces Building Blocks

11

MATERIALIZING DATA SPACES REQUIRES TO TAKE OPTIONS AND ADOPT A MINIMUM BUT ENOUGH SET OF TECHNOLOGY STANDARDS

Mapping of Technology Building Blocks and Systems

12

Data Spaces Business Alliance (DSBA): joining forces

13

BDVA, FIWARE, GAIA-X and IDSA launched the Data Spaces Business Alliance (DSBA) to accelerate Business Transformation in the Data Economy (Sep 23^rd, 2021)

• One voice and a common framework to make interoperable Data Spaces happen;
• Together, the Alliance’s founding organisations represent 1,000+ leading key industry players;
• With its combined cross-industry expertise, resources and know-how, the Alliance drives awareness and rely on more than 100 Hubs for dissemination
• Technical Convergence discussions towards common reference technology framework for creation of Data Spaces:
• Agile approach based on delivery of subsequent versions of a Minimum Viable Framework (MVF) specification where we do not only identify standards and target components but how to integrate them
• Once alignment on relevant topics within several of the ongoing workstreams is achieved, the publication of a new version of the DSBA Technology Convergence document will be published to incentivize development of compliant implementations

DSBA Technical Convergence version 2.0

• The DSBA Technical Convergence (TC) delivers a Minimum Viable Framework (MVF) enabling the creation of data spaces
• This MVF is based on the convergence of existing architectures and models, leveraging each other’s efforts on specifications and implementations.
• A new edition of the DSBA TC (version 2.0) was released on April 21st - Major highlights
• Description of common vision and conceptual model
• Identification of major standards per technology pillar and specifications of how they get integrated
• Some initiatives committed to follow DSBA technical recommendations (others welcome to do the same!):
• FIWARE Data Space Connector
• iSHARE Trust Framework
• DOME project under Digital Europe Programme

14

Working to integrate results under i4Trust collaboration program

Some key concepts: Products, Services, Resources

• A Participant of the Data Space can play the role of a Provider or Customer (or Consumer) of (Data) Products
• A (Data) Product is realized as a combination of Services and/or Resources:
• Services provide access to data or processing of data
• Resources typically required for the execution of the Services
• Products (and corresponding services and resources) are provisioned and activated for a particular Customer:
• Provision and activation may take days: not all automatically!
• Not everything runs on the Cloud: cloud-to-edge products
• Example: Air Quality Monitoring Product
• Comprises a number of Services (e.g., web portal, REST services endpoints, etc) some of which bring access to data (air quality measures) or processing of data (air quality predictions)
• It requires that IoT devices are deployed in the field and some computing capacity provisioned on the cloud (resources)

15

Some key concepts: Verifiable Credentials

​

• VCs will be used to describe participants in data spaces
• VCs will be used to describe products offered by participants, e.g.:
• issued by certification agencies, describing compliance with certain regulations (e.g., GDPR compliance) recommendations (e.g., low carbon emissions) or technical compliance (e.g., NGSI-LD compatible interface).
• provided by the own service provider describing aspects of the service (e.g., access policies, technical standards supported, etc)

​

16

DSBA Technical Convergence: Conceptual Model

17

• Providers offer products based on published specifications
• According to those product specifications, products are based on a combination of services and resources following published specifications
• Products, Services and Resources are described based on a number of characteristics which may be modeled as Verifiable Credentials
• Offerings are published by the Provider around Products following specifications

DSBA Technical Convergence: Conceptual Model

18

• Products, Services and Resources specs get materialized into concrete Product, Service and Resource instances

DSBA Technical Convergence: Conceptual Model

19

• When a customer is interested in a given offering around a product, it issues a Product Order
• Completing a Product Order means that a new instance of a Product (with its corresponding services and resources) is provisioned and activated for the customer, or that a tenant for the customer is created to serve the customer
• Once the new instance or tenant for the customer is provisioned and activated, the customer can start using it, which translates into creation of usage logs that will bring the basis for rating and billing

What it means acquiring rights to use a product/service?

• Organizations that acquire rights to use a product (data service):
• become trusted issuers of VC including claims relevant for data service access
• They can issue such VCs for users within the organization
• Organizations willing to access services or resources of a product have to first go through authentication to gain an access token when:
• it will be verified whether the organization is a trusted participant (Trust service)
• it will be verified whether the organization is a trusted issuer of the VCs defined around claims that are meaningful for business logic of the product → access rights were properly acquired (e.g., via some marketplace or directly via the connector managing access to the product)
• Authorization based on Attribute Based Access Control (ABAC) will be performed on any request by verifying that users with the VCs traveling in the access token sent with the request can perform the request based on defined policies

​

​

20

DSBA Technical Convergence: Conceptual Model

21

DSBA Technical Convergence: Conceptual Model

22

Onboarding of an organization in the data space

• The organization validates that the VC containing its description as organization is compliant with Gaia-X specifications using the services of a Gaia-X Digital Clearing House (GXDCH) - as a result, a VC is issued by the GXDCH (steps 1-2). That VC will end stored in the wallet of the LEAR either as part of the same process (once the GXDCH implements the OIDC4VCI) or via an issuer of VCs that exists inside the organization (step 3)
• The API for registering the organization is inspired in the DID-Registry API defined by EBSI but extending it to allow:
• creation, update and deletion of entries beyond read(ing) of entries
• authentication with VCs (including the VC issued by a GXDCH)
• Using an onboarding application (or a web portal) the organization’s LEAR requests the authentication into the Participant Lists service which ultimately translates into a request to the Verifier (step 4-6)
• a page is accessed where a QR for authentication is displayed (step 4)
• the QR code is scanned through the wallet (step 5) which translates
• into a request to the verifier (step 6)
• The verifier checks in the PRP/PAP what VCs it has to request to the wallet (step 7). In principle it will find the following VCs to be requested: a) the LEAR VC accrediting the user as LEAR of the organization, b) the VC containing the description of the organization, and c) the VC issued by some GXDCH acredditing that the previous VC is Gaia-X compliant
• The verifier responds to the previous request sending a VP request to the wallet which responds with the requested VCs (steps 8-9)
• The verifier checks that the LEAR VC has been signed using proper eIDAS certificates and that the GXDCH VC has been issued by a trusted GXDCH (step 10). It finally produces an access token (steps 11-12) which the onboarding application can then use to invoke the EBSI DID-Registry+ API in order to register the organization as data space participant (step 13)

23

Consumer registration at Connector Level using TM Forum APIs

• Using a contracting app (or a web portal), a LEAR of the consumer organization will request authentication into the connector of the service provider (steps 1-3 involving scanning of QR code using the wallet)
• The Verifier will request from the user’s wallet a VC that acredits him/her as LEAR of the organization, eventually other VCs (steps 4-5). The wallet will check whether the verifier belongs to a participant in the data space (step 6) and return the requested VCs (step 7)
• The Verifier checks whether the LEAR’s VC was issued by a trusted participant of the data space (step 8), and also checks whether other VCs required were issued by trusted issuers (step 9)
• If verifications were ok, it issues a token (step 10) that is transmitted to the user (step 11)
• Using the returned token, the user invokes TM Forum API to register the consumer organization at the Connector (steps 12-17) establishing the necessary access control (steps 12-14)
• Once the organization is registered and fulfills all the necessary information (which may take some time), the organization is registered in the local trusted issuers list as trusted issuer of VCs which include claims as buyer of products in the connector (step 18)

24

Contract Management at Connector Level using TM Forum APIs

• A LEAR of the consumer organization will start authentication into the contract negotiation module of the connector of a service provider (steps 1-3 involving scanning of QR code using the wallet)
• The Verifier will request to the user (via his/her wallet) for VCs that acredit a) the user is a LEAR of the organization, b) (s)he owns credentials connected to roles meaningful for contract negotiation that the organization issued to the user and c) some other VCs (steps 4-5). The wallet will check that the verifier belongs to a participant in the data space (step 6) and return the requested VCs (step 7)
• The Verifier checks whether the LEAR’s VC was issued by a trusted participant of the data space (step 8), and rest of VCs required were issued by trusted issuers (step 9). Note that the VC for accessing contract negotiation functions requires that the organization were previously registered in the contract negotiation module, otherwise it will not be found in local trusted issuers registry
• If verifications were ok, it issues a token (step 10) that is transmitted to the user (step 11)
• Using the returned token, the user invokes TM Forum API to perform operations on the contract negotiation module (steps 12-17) establishing the necessary access control (steps 12-14)
• Once the organization is registered and fulfills all the necessary information (which may take some time), the organization is registered as trusted issuer of VCs which include claims as valid user of products accessible via the connector (step 18)

25

Interaction once procurement has been completed (user involved)

• A user of the product (employee or customer of the consumer oganization that was issued a VC in step 0 that acredits him/her as user playing a role relevant to the business logic of the product) request authentication in the connector (steps 1-3 involving scanning of QR code using the wallet)
• The Verifier will request to the user (via his/her wallet) for VCs that acredit a) the user owns credentials connected to roles meaningful for the given product/application and b) some other VCs (steps 4-5). The wallet will check that the verifier belongs to a participant in the data space (step 6) and return the requested VCs (step 7)
• Verifier verifies whether the VC was issued by an organization that a) is a trusted participant of the data space (step 8) and b) is a trusted issuer of the VCs meaningful for the application (that is, VCs only organizations that ordered the product can issue), also checks whether other VCs required were issued by trusted issuers (steps 9)
• If verifications were ok, it issues a token (step 10) that is transmitted to the user (step 11)
• Using the returned token, the user invokes services of the product (step 12)
• The PEP proxy will verify whether a user with the claims (attributes) included in the VCs extracted from the token is authorized to perform the given request (steps 13-15)
• If authorization is ok, the request is forwarded (step 16) and a response returned to the user (step 17)

26

Interaction once procurement has been completed (M2M)

• An application from the consumer organization that acquired rights to use a product requests its authentication in the connector (steps 1)
• The Verifier will request to the application for VCs that acredit a) the application owns credentials connected to roles meaningful for the given product/application and b) some other VCs (steps 2-3). The wallet will check that the verifier belongs to a participant in the data space (step 4) and returns the requested VCs (step 5)
• Verifier verifies whether the VC was issued by an organization that is a trusted participant of the data space (step 6) and is a trusted issuer of the VCs meaningful for the application (that is, VCs that only organizations that ordered the product can issue), also checks whether other VCs required were issued by trusted issuers (steps 7)
• If verifications were ok, it issues a token that is transmitted to the application (steps 8)
• Using the returned token, the application invokes services of the product (step 9)
• The PEP proxy will verify whether the application with the claims (attributes) included in the VCs extracted from the token is authorized to perform the given request (steps 10-12)
• If authorization is ok, the request is forwarded (step 13) and a response returned to the app (step 14)

27

DSBA-compliant FIWARE Data Space Connector

​

28