References
Last updated
Last updated
Connector
Dataspace Connector: tbd; Trusted Connector:
gerd.brost@aisec.fraunhofer.de, michael.lux@aisec.fraunhofer.de, jean-luc.reding@aisec.fraunhofer.de
DAPS
[Omejdn DAPS in IDS-G] https://github.com/International-Data-Spaces-Association/omejdn-daps
martin.schanzenbach@aisec.fraunhofer.de
MetaData Broker
contact@ids.fraunhofer.de
ParIS
--
The Dataspace Connector is an implementation of an IDS connector component following the . It integrates the and uses the for IDS functionalities and message handling. The core component in this repository provides a REST API for loading, updating, and deleting resources with local or remote data enriched by its metadata. It supports IDS conform message handling with other IDS connectors and components and implements usage control for selected IDS usage policy patterns.
The Trusted Connector is an implementation of an IDS connector component following the .
IDSCP is utilized as a connector interaction protocol. It's specification is provided in the IDS-G (see references in overview table).
in Rust: https://github.com/International-Data-Spaces-Association/idscp2-rust
in Java: https://github.com/industrial-data-space/idscp2-java
Currently, the IDSCP2 Implementation focuses on the Transport Layer Protocol (as defined in https://github.com/International-Data-Spaces-Association/IDS-G-pre/tree/connector-interaction/Communication/protocols/idscp2/TransportLayer) which is used for establishing a secure communication channel between a client and a server application. This secure channel is only established if a DAT token was provided which can be validated by the recipient and if Remote Attestation (necessary for Trust and Trust+ profiles) is conducted successfully. The sending and validation of the DAT and RAT details depends on different drivers which are currently not open source yet. The desired drivers to be used should (at least for the time being) be provided by the connector operator and it should be possible to bring own drivers into the system to be evaluated there.
Leon Beckmann (leon.beckmann@aisec.fraunhofer.de) Oliver Braunsdorf (oliver.braunsdorf@aisec.fraunhofer.de) Monika Huber (monika.huber@aisec.fraunhofer.de) Michael Lux (michael.lux@aisec.fraunhofer.de) Gerd Brost (gerd.brost@aisec.fraunhofer.de)
(will come soon) (tbd)