| Component | Specification | Open Source Implementation | Contact Person |
|---|---|---|---|
| Connector | Connector interaction specification in IDS-G (will come soon) Connector specification in IDS-G (tbd) | Dataspace Connector Trusted Connector | Dataspace Connector: tbd; Trusted Connector: |
| [email protected], [email protected], [email protected] | |||
| DAPS | DAPS specification | [Omejdn DAPS in IDS-G] https://github.com/International-Data-Spaces-Association/omejdn-daps | [email protected] |
| MetaData Broker | MetaData Broker specification in IDS-G | ||
| Whitepaper | MetaData Broker Open Core | [email protected] | |
| ParIS | ParIS specification in IDS-G | ParIS Open Core | -- |
The Dataspace Connector is an implementation of an IDS connector component following the IDS Reference Architecture Model. It integrates the IDS Information Model and uses the IDS Messaging Services 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 IDS Reference Architecture Model.
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 ([email protected])
Oliver Braunsdorf ([email protected])
Monika Huber ([email protected])
Michael Lux ([email protected])
Gerd Brost ([email protected])