We divide the implementation into two features: (1) onboarding and (2) data provisioning.
Figure 1. Component diagram
Other APIs:
The frontend application integrates into redline. The base path is /api/ui.
| Frame | Input from backend (GET) | Output to backend (POST) |
|---|---|---|
| 1 Select dataspace | list of dataspaces (property name) |
- |
| 1.1 Register company | - | - |
| 1.2 Enter company data | - | - |
| 1.3 Upload documents | - | document |
| 1.4 Accept conditions | dataspace (property agreement) |
- |
| 1.5 Submit registration | - | registration data (cf. here) |
| 2 Network overview | registration (participant id, registration date, registration status) | - |
| 2.1 Dataspace details | participant | - |
| 2.2 Manage partners | dataspaceInfo (property participants) |
- |
| 3 Home | - | - |
| 4 Files overview | list of files | - |
| 4.1 Upload file | - | - |
| 4.2 Select file | - | document |
| 4.3 Add details | - | - |
| 4.4 Manage access | dataspaceInfo (property participant.name) |
- |
| 4.5 Upload file | - | file data (cf. here) |
| 4.6 File details | file, agreement, (optional: selected negotiation & transfer properties) | - |
| 4.7 Discover data | list of assets | - |
Table 2. Backend endpoints for GUI interactions
The backend must map user input into backend requests (to CFM and EDC-V). The frontend does not trigger the JAD requests.
- registration data must be mapped to CFM requests
- file upload data must be mapped to EDC-V requests
Required repositories for persistency, partly provided by the JAD database server (see here).
| Repository | Component |
|---|---|
| tenant | backend, CFM database |
| credential | IdentityHub database, IssuerService database |
| asset | control plane database |
| policy definition | control plane database |
| contract definition | control plane database |
| vault data | Hashicorp Vault |
| certificate file | CFM database (?) |
| participant | backend |
| dataspace | backend |
Table 3. Repository for End-User API backend
After entering the company data and requesting access to the dataspace, the participant is technically onboarded.
See CFM interactions.
This use case implements the pull sequence. The SME acts as the data provider and another party acts as the data consumer, that downloads the provided certificate data. Figure 1 depicts a high-level interaction flow.
Figure 2. Representative pull sequence
| # | What | Who |
|---|---|---|
| 1 | Prepare & publish data offering | Provider (SME) |
| 2 | Establish connection (negotiate agreement) | Consumer |
| 3 | Approve access request (negotiate agreement) | Provider (SME) |
| 4 | Download certificate data | Consumer |
Table 4. Steps for providing certificate data. Step 3 is not part of the demonstrator.
See EDC-V interactions.