PolicyDefinition.getPolicy() can throw a NPE if no policydefinition available.

Feature Request

Description

Currently the EDC-Entities are stored In-Memory. This issue is about creating an extension supporting the persistence of EDC-Entities into a PostgreSQL-Database.

Solution Proposal and Work Breakdown

• Creating an Extension which uses Flyway to initiate a PostgreSQL-Database
• Include SQL-EDC-Extensions to exchange default In-Memory Implementations against SQL-Store Implementations
• Integrate the Extension into the MDS-Control-Plane

Feature Request

Type of Issue

Enhancement

Describe the ideal solution or feature request

Adding group and version for every single sub-project is error-prone and repetitive. We should set those from the parent gradle file.

Feature Request

Description

It is unclear that an MDS certificate must be added to a specific folder. Please add a documentation covering this aspect.
Please also review paths in docker-compose, as feedback was: "relative paths are declared as absolute paths"

Which Areas Would Be Affected?

Documentation

Bug Report

Description

According to README.md the location of the keystore (.jks file) needs to be specified in docker-compose.yaml.
The default settings in parameter EDC_KEYSTORE suggests an absolute path while the README.md suggests a relative path
resources/vault/edc/
Providing an absolute path anywhere in the file system yields a fileNotFound Exception for docker compose up

Expected Behavior

Accept an absolute path configuration of the keystore file anywhere on the file system

Observed Behavior

edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker processes
edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker process 58
edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker process 60
edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker process 62
edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker process 64
edc-ui | 2023/02/07 11:46:47 [notice] 1#1: start worker process 65
edc-ui | 2023/02/07 11:46:47 [emerg] 58#58: io_setup() failed (38: Function not implemented)
edc-ui | 2023/02/07 11:46:47 [emerg] 60#60: io_setup() failed (38: Function not implemented)
edc-ui | 2023/02/07 11:46:47 [emerg] 62#62: io_setup() failed (38: Function not implemented)
edc-ui | 2023/02/07 11:46:47 [emerg] 64#64: io_setup() failed (38: Function not implemented)
edc-ui | 2023/02/07 11:46:47 [emerg] 65#65: io_setup() failed (38: Function not implemented)
edc | 2023-02-07 11:46:49 Configuration file does not exist: dataspaceconnector-configuration.properties. Ignoring.
edc | 2023-02-07 11:46:49 Initialized FS Configuration
edc | 2023-02-07 11:46:50 Error booting runtime: Key store does not exist: /Users/A307961/Daten/Projekte/MDP/MDS-Anbindung/connector/tmp/cert.jks
edc | org.eclipse.edc.spi.EdcException: Key store does not exist: /Users/A307961/Daten/Projekte/MDP/MDS-Anbindung/connector/tmp/cert.jks
edc | at org.eclipse.edc.vault.filesystem.FsVaultExtension.loadKeyStore(FsVaultExtension.java:83)
edc | at org.eclipse.edc.vault.filesystem.FsVaultExtension.initialize(FsVaultExtension.java:60)
edc | at org.eclipse.edc.boot.system.injection.lifecycle.InitializePhase.initialize(InitializePhase.java:37)
edc | at org.eclipse.edc.boot.system.injection.lifecycle.ExtensionLifecycleManager.initialize(ExtensionLifecycleManager.java:61)
edc | at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
edc | at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
edc | at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
edc | at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
edc | at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
edc | at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
edc | at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
edc | at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
edc | at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
edc | at org.eclipse.edc.boot.system.ExtensionLoader.bootServiceExtensions(ExtensionLoader.java:67)
edc | at org.eclipse.edc.boot.system.runtime.BaseRuntime.bootExtensions(BaseRuntime.java:152)
edc | at org.eclipse.edc.boot.system.runtime.BaseRuntime.boot(BaseRuntime.java:222)
edc | at org.eclipse.edc.boot.system.runtime.BaseRuntime.boot(BaseRuntime.java:87)
edc | at org.eclipse.edc.boot.system.runtime.BaseRuntime.main(BaseRuntime.java:75)
edc |
edc exited with code 255

Steps to Reproduce

Steps to reproduce the behavior:

Specify an existing keystore file in docker-compose.yaml

Context Information

specifying the keystore.jks in /resources/vault/edc/ (absolute path although it is a relative path to the installation) resolves the problem

• Time: until 07.02.2022
• Logs: see above
• Parameter: see above
• OS: MacOS Ventura 13.0.1

Feature Request

Type of Issue

Release Request

Describe the ideal solution or feature request

Please release next version of broker extension with deprovisioning feature.

Which Areas Would Be Affected?

GitHub Maven Release

Why Is the Feature Desired?

Showcase most recent features

Who asked for this?

@ip312

Solution Proposal

• Release broker extension
• Update all readmes, docker-composes and other usages of latest release

Feature Request

Type of Issue

improvement

Describe the ideal solution or feature request

A command line script shall be provided, which automatically extracts SKI AKI of a p12 file.

Which Areas Would Be Affected?

Helper Scripts

Why Is the Feature Desired?

Convenience

Who asked for this?

@ip312

Bug Report

Description

Port mappings for UI are wrong (EDC_UI_ASSET_PROP_ORIGINATOR)

Bug Report

Description

Performing a data-transfer should not be possible for data-offers, which where retrieved using the Catalog URL in the Catalog Browser.

https://github.com/sovity/edc-ui/blob/845482ed21a94b2ebe2448786efaac75db58a801/src/modules/edc-demo/components/contract-viewer/contract-viewer.component.ts#L130

Expected Behavior

• Retrieving the contractnegotiation using the contractId
• Using the contractnegotiations counterPartyAddress to find the other connectors address

Observed Behavior

• The catalog is fetched
• Then the asset is used to retrieve the counterParty from the assets originator field

Provide docker-compose.yml which contains EDC UI + EDC backend

Feature Request

Description

As I understand, every asset offering needs a policy. As we just have some restricting policies, we need a default "always-true" policy, to avoid restrictions.

Why Is the Feature Desired?

Customers do not want to publish assets always with a limiting constraint.

Stakeholders

@SebastianOpriel

Solution Proposal and Work Breakdown

• Add always true policy.
• Automatically add always-true policy on startup.
• Add to open source images.
• Add to closed source images.
• E2E Test all images.

Bug Report

Description

Getting error while running the postman_collection.json file: "Error: connect ECONNREFUSED 127.0.0.1:9191" along with "Forbidden" when visiting ""https://daps.dev.mobility-dataspace.eu/jwks.json"".

Expected Behavior

The broker extension should be attached and published.

Observed Behavior

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Context Information

Add any other context about the problem here.

• Environment: Which instance or deployment were you using when the error occurred? Staging, Productive, Connector-URL, etc.?
• Used version: If a specific component was used, which Version did you use? E.g. EDC v1.0.0
• Time: When did the error occur? Exact timestamp (incl. time zone; assumed CET/CEST if missing) if possible.
• Logs: Error log or further information
• Parameter: Request contents or information entered
• OS: [e.g. iOS, Windows]
• ...

Possible Implementation and Work Breakdown

You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.

• Task 1
• Task 2
• ...
  
  

Bug Report / Feature request

Description

A clear and concise description of the bug.
If applicable, add screenshots or other information to help explain your problem.

I would like to use these extensions with EDC v0.0.1-milestone-8, because of other extensions depending on this version. Therefore I am a bit in a dependency conflict, because these extensions are working fine with v0.0.1-milestone-7 and the others are working fine with v0.0.1-milestone-8. I think in this case the upgrade is preferred over the downgrade..

Expected Behavior

A clear and concise description of what you expected to happen.

Just work with v0.0.1-milestone-8. No exceptions in the log.

Observed Behavior

A clear and concise description of what happened instead.

Compiles without error. But I am getting this Exception in the log:

2023-02-28 12:01:27 Initialized IDS Core
Exception in thread "main" java.lang.NoSuchMethodError: 'void org.eclipse.edc.protocol.ids.api.multipart.dispatcher.sender.IdsMultipartSender.<init>(org.eclipse.edc.spi.monitor.Monitor, okhttp3.OkHttpClient, org.eclipse.edc.protocol.ids.spi.service.DynamicAttributeTokenService, com.fasterxml.jackson.databind.ObjectMapper)'
        at de.sovity.extension.broker.BrokerExtension.registerBrokerMessageSenders(BrokerExtension.java:255)
        at de.sovity.extension.broker.BrokerExtension.initialize(BrokerExtension.java:131)
        at org.eclipse.edc.boot.system.injection.lifecycle.InitializePhase.initialize(InitializePhase.java:37)
        at org.eclipse.edc.boot.system.injection.lifecycle.ExtensionLifecycleManager.initialize(ExtensionLifecycleManager.java:61)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
        at org.eclipse.edc.boot.system.ExtensionLoader.bootServiceExtensions(ExtensionLoader.java:67)
        at org.eclipse.edc.boot.system.runtime.BaseRuntime.bootExtensions(BaseRuntime.java:152)
        at org.eclipse.edc.boot.system.runtime.BaseRuntime.boot(BaseRuntime.java:222)
        at org.eclipse.edc.boot.system.runtime.BaseRuntime.boot(BaseRuntime.java:87)
        at org.eclipse.edc.boot.system.runtime.BaseRuntime.main(BaseRuntime.java:75)

Steps to Reproduce

Steps to reproduce the behavior:

Basically just upgrade in a sample project the edc-version from v0.0.1-milestone-7 to v0.0.1-milestone-8 and see what happens in the log on startup.

Context Information

Add any other context about the problem here.

• Environment: MDS Dev-Environment
• Used version:
  • EDC: v0.0.1-milestone-8
  • sovity/edc-extensions: v1.3.0
• Time: 2023-02-28 12:01:27 UTC
• Logs: see above
• Parameter: happens on startup
• OS: Debian Docker Image
• ...

Possible Implementation and Work Breakdown

You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.

I don't know.

Failing since merge of last commit information extension.

See https://github.com/sovity/edc-extensions/actions/runs/4195464495

Feature Request

Description

The EDC Datamanagement API repeats artifact prefixes:

• Assets have to be created with "urn:artifact:" prefix.
• Contract Agreements return artifact ids with "urn:artifact:urn:artifact:" prefix.

Our Contract Agreement Transfer API extension removes that double prefix to make things work.

Solution Proposal and Work Breakdown

• Check if that issue persists in current milestone of Microsoft EDC.
• Contribute a solution to the Microsoft EDC.
• Quick Check for source code location of issue.
• Create Issue in Core EDC

Bug Report

Description

Facing an error while running the docker compose, the dataspace connector status is shown as ready however,
while trying to register the resource at broker, it says ""Failed to obtain token: {"error":"invalid_client","error_description":"Client unknown"}""

Using this as Client_id with the given SKI:AKI values which was generated from the get_client.sh script "AE:92:8C:65:A3:FB:41:F1:05:3E:EF:19:05:84:DA:6B:E2:25:E6:90:55:8C:E0:EE:C9:79:10:F5:DD:1E:BF:33:87:8B:8A:BE:A4:01:16:64"

Apparently, in the readme file it says the client_id has "keyid" in between the SKI:AKI combinations but it did not generated any keyid in this case. Wondering if the client_sh script needs to get updated.

Bug Report

Description

The FAQ section shows this client id example:

EDC_OAUTH_CLIENT_ID: 7X:7Y:...:B2:94:keyid:6A:2B:...:28:80

but the /get_client.sh script does not put a keyid between ski and aki.

Also it is described that the user should:

Copy the SKI:AKI combination and use it to start the EDC

This is inconsistent. Because if the key is just copied, it will not contain a keyid.

Expected Behavior

The readme should be consistent with the get_client.sh script output.

Bug Report

Description

Expected Behavior

Consumer is able to negotiate the offer and to consume the data asset.

Observed Behavior

The asset window freezes during the negotiation process.

Steps to reproduce the behavior:

1. Provider
   CaaS Connector
   https://catalog.test.mobility-dataspace.eu/connector/connector?id=https%3A%2F%2Fbroker.test.mobility-dataspace.eu%2Fcatalog%2F-958678592
   Asset:
   https://catalog.test.mobility-dataspace.eu/resources/resource?id=https://broker.test.mobility-dataspace.eu/catalog/-958678592/1598247006/-1999792879
   Policy:

[
  {
    "edctype": "dataspaceconnector:permission",
    "uid": null,
    "target": null,
    "action": {
      "type": "USE",
      "includedIn": null,
      "constraint": null
    },
    "assignee": null,
    "assigner": null,
    "constraints": [
      {
        "edctype": "AtomicConstraint",
        "leftExpression": {
          "edctype": "dataspaceconnector:literalexpression",
          "value": "POLICY_EVALUATION_TIME"
        },
        "rightExpression": {
          "edctype": "dataspaceconnector:literalexpression",
          "value": "2023-02-14T23:00:00.000Z"
        },
        "operator": "GT"
      },
      {
        "edctype": "AtomicConstraint",
        "leftExpression": {
          "edctype": "dataspaceconnector:literalexpression",
          "value": "POLICY_EVALUATION_TIME"
        },
        "rightExpression": {
          "edctype": "dataspaceconnector:literalexpression",
          "value": "2023-12-30T23:00:00.000Z"
        },
        "operator": "LT"
      }
    ],
    "duties": []
  }
]

2. Consumer:
   The Docker container deployed locally

• registered at the broker
• is able to publich a contract offer at the broker

3. Go to Consumer/Catalog Browser

4. Insert as Connector IDs: https://connector-mds-test-001.prod-sovity.azure.sovity.io/control/api/v1/ids/data

5. Click on MDS Demo Asset

6. Click on Negotiate

Bug Report

Description

The MDS test environment was yesterday not available for the short time. When trying to create a contract offer using CaaS I got the following error message,

The policy was definitely not a problem, today I was able to create a contract offer using the same policy.

Expected Behavior

I would expect the error message: "DAPS is currently not accessible" or something similar.

Bug Report

Description

Once the project is deployed and running, I tried creating assets (it works) but I cannot figure out the API URI to use to access the dataset itself.

Both dataset and connectors are available through the MDS broker:

• https://catalog.test.mobility-dataspace.eu/connector/connector?id=https%3A%2F%2Fbroker.test.mobility-dataspace.eu%2Fcatalog%2F-1179781081
• https://catalog.test.mobility-dataspace.eu/resources/resource?id=https://broker.test.mobility-dataspace.eu/catalog/-1179781081/1902456861/526382240

But we do not get how to access the Data itself from the dataset.
Given the current configuration, the data API looks unavailable but we are not sure how to configure it.

Those API endpoints never returns anything usable:

• https://edc-dev.startinblox.com/catalog/MySuperContract-urn:artifact:superduperdataset
• http://edc-dev.startinblox.com:11003/api/v1/ids/data

Expected Behavior

As we understood it, the URL https://edc-dev.startinblox.com/catalog/MySuperContract-urn:artifact:superduperdataset should actually give you access to the description of the data, or to the data itself ?

Observed Behavior

It just freezes. Blank screen.

Context Information

The docker-compose.yml looks like:

  edc-ui:
    image: ghcr.io/sovity/edc-ui:latest
    container_name: edc-ui
    ports:
      - '11000:80'
    environment:
      - EDC_UI_ASSET_PROP_ORIGINATOR_ORGANIZATION=Startinblox Dev Connector
      - EDC_UI_ACTIVE_PROFILE=mds-open-source
      - EDC_UI_DATA_MANAGEMENT_API_URL=http://edc-dev.startinblox.com:11002/api/v1/data
      - EDC_UI_DATA_MANAGEMENT_API_KEY=ApiKeyDefaultValue
      - EDC_UI_CATALOG_URLS=http://edc-dev.startinblox.com:11003/api/v1/ids/data
      - EDC_UI_ASSET_PROP_ORIGINATOR=http://edc-dev.startinblox.com:11003/api/v1/ids/data
  edc:
    container_name: edc
    image: ghcr.io/sovity/edc-mds:latest
    environment:
      # Basic Configuration
      EDC_IDS_TITLE: 'Startinblox EDC Connector'
      EDC_CONNECTOR_NAME: 'Startinblox EDC Connector'
      EDC_IDS_DESCRIPTION: 'Minimal configured Open Source EDC built by sovity'
      EDC_IDS_CURATOR: https://startinblox.com
      EDC_HOSTNAME: edc-dev.startinblox.com
      EDC_IDS_ENDPOINT: http://edc-dev.startinblox.com:11003/api/v1/ids
      EDC_API_AUTH_KEY: ApiKeyDefaultValue

      # Data Space Configuration
      EDC_OAUTH_CLIENT_ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
      EDC_KEYSTORE: /resources/vault/edc/edc-dev.startinblox.com.jks
      EDC_OAUTH_TOKEN_URL: https://daps.test.mobility-dataspace.eu/token
      EDC_OAUTH_PROVIDER_JWKS_URL: https://daps.test.mobility-dataspace.eu/jwks.json
      EDC_BROKER_BASE_URL: https://broker.test.mobility-dataspace.eu
      EDC_CLEARINGHOUSE_LOG_URL: https://clearing.test.mobility-dataspace.eu/messages/log

      # Deployment Configuration
      WEB_HTTP_PORT: 11001
      WEB_HTTP_PATH: /api
      WEB_HTTP_DATA_PORT: 11002
      WEB_HTTP_DATA_PATH: /api/v1/data
      WEB_HTTP_IDS_PORT: 11003
      WEB_HTTP_IDS_PATH: /api/v1/ids
      EDC_IDS_ID: urn:connector:example-connector
      IDS_WEBHOOK_ADDRESS: http://edc-dev.startinblox.com:11003

Thanks in advance.

Feature Request

Description

We want to streamline Backend/Control Plane and UI configuration.

Currently our UI and EDC Backends have different configuration properties regarding connector info:

/* Only in Backend */
EDC_IDS_ID: urn:connector:sth

// Potentially the same, broker uses CONNECTOR_NAME
EDC_CONNECTOR_NAME: The name of the connector
EDC_IDS_TITLE: Title of the Connector

EDC_IDS_DESCRIPTION: Description of the Connector
EDC_IDS_CURATOR: URL of the curator, i.e. the company, which configures data offerings etc.
EDC_IDS_MAINTAINER: URL of the maintainer

/* In both */
EDC_IDS_ENDPOINT: URL of the Connectors endpoint (possibly overlapping with EDC_UI_ORIGINATOR)

/* Only in UI */
EDC_IDS_CURATOR_ORGANIZATION_NAME (previously EDC_UI_ORIGINATOR_ORGANIZATION)

Stakeholders

MDS would like to see full connector info in UI.

We would like less configuration in UI and all configuration in Control Plane.

Solution Proposal and Work Breakdown

• Create Extension that adds a UI Config Endpoint
• Config Endpoint provides JSON with UI Config ("EDC_UI_*"), same as in UIs documentation
• Pass values from ENV Vars ("EDC_UI_*" + selected mapped others) into served UI config
• If CONNECTOR_NAME and IDS_TITLE are the same and CONNECTOR_NAME is our variable, they should be merged and broker extension should use the correct env variable.
• Ensure API Endpoint is named in a way that adding an editing endpoint later will work out well.

When generating the jks file out of the p12 using the get_client.sh we had the following error:

$ ./get_client.sh dwd-connector.test.mobilitydataspace.io.p12 thepassword
Error outputting keys and certificates
40A7D2E2ED7F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()
Could not read certificate from ./cert.crt
Unable to load certificate
:

We had to add a -legacy switch in the first openssl command (line 22) for the script to work.

So that:

becomes:

openssl pkcs12 -in "$P12_FILE" -clcerts -nokeys -legacy -out "$CRT_FILE" -passin "pass:$PASSWORD"

Feature Request

Describe the ideal solution or feature request

Add config file for Dependabot, to automatically update dependencies via PRs.

Bug Report

Description

Tests for the last-commit-info-Extension are failing.

Steps to Reproduce

1. Readd commented lines in LastCommitInfoEnvTest
2. Readd commented lines in LastCommitInfoJarTest
3. Run gradle test

Feature Request

Description

To interact with the EDC it would be great to have

• OpenAPI definition in place (at docs?) #178
• extensive Postman collection, which is at least capable of requesting catalogs, negotiating contracts and transfer data. @tmberthold

Feature Request

Type of Issue

Enhancement

Describe the ideal solution or feature request

Additional fields, visible to the MDS EDC UI shall be added to the Metadata Broker extension.

Which Areas Would Be Affected?

Message Payloads of Broker asset registration messages of EDC Broker Extension.

Why Is the Feature Desired?

Alignment of EDC UI capabilities with other extensions.

Solution Proposal

Use provided information, to set according fields in asset description. Please find below an example of a Resource Description at Broker from https://catalog.test.mobility-dataspace.eu/resources/resource?id=https%3A%2F%2Fbroker.test.mobility-dataspace.eu%2Fcatalog%2F-1257235213%2F-439825952%2F1892951068

{
  "@context" : {
    "ids" : "https://w3id.org/idsa/core/"
  },
  "@type" : "ids:Resource",
  "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068",
  "ids:created" : {
    "@value" : "2022-12-08T10:25:00.311Z",
    "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
  },
  "ids:version" : "1",
  "ids:language" : [ {
    "@type" : "ids:Language",
    "@id" : "https://w3id.org/idsa/code/EN"
  } ],
  "ids:resourceEndpoint" : [ {
    "@type" : "ids:ConnectorEndpoint",
    "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068/-1664286248",
    "ids:endpointDocumentation" : [ {
      "@id" : "https://github.com/Mobility-Data-Space/mobility-data-space/wiki/MDS-Ontology"
    } ],
    "ids:accessURL" : {
      "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068"
    },
    "http://www.w3.org/2002/07/owl#sameAs" : {
      "@id" : "https://w3id.org/idsa/autogen/connectorEndpoint/4700dfe4-5723-49a4-a62b-6a0f38707269"
    }
  } ],
  "ids:representation" : [ {
    "@type" : "ids:Representation",
    "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068/-1493557143",
    "ids:created" : {
      "@value" : "2022-12-08T10:25:01.448Z",
      "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
    },
    "ids:language" : {
      "@type" : "ids:Language",
      "@id" : "https://w3id.org/idsa/code/EN"
    },
    "ids:mediaType" : {
      "@type" : "ids:IANAMediaType",
      "@id" : "https://w3id.org/idsa/autogen/iANAMediaType/2c0a78df-b103-45f7-b652-f5d9acbcc81d",
      "ids:filenameExtension" : "text/plain"
    },
    "ids:modified" : {
      "@value" : "2022-12-08T10:25:01.448Z",
      "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
    },
    "ids:instance" : [ {
      "@type" : "ids:Artifact",
      "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068/-1493557143/-287640995",
      "ids:byteSize" : 79099,
      "ids:creationDate" : {
        "@value" : "2022-12-08T10:25:01.686Z",
        "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
      },
      "ids:checkSum" : "711729741",
      "ids:fileName" : "Stop_Times.txt",
      "http://www.w3.org/2002/07/owl#sameAs" : {
        "@id" : "https://dataspaceconnector:8080/api/artifacts/384992c5-2f4b-4664-9f96-f7ef1ea0c703"
      }
    } ],
    "http://www.w3.org/2002/07/owl#sameAs" : {
      "@id" : "https://dataspaceconnector:8080/api/representations/b43754d8-2e39-4ce9-a544-c6399e9fddd9"
    }
  } ],
  "ids:contractOffer" : [ {
    "@type" : "ids:ContractOffer",
    "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068/-575473219",
    "ids:permission" : [ {
      "@type" : "ids:Permission",
      "@id" : "https://broker.test.mobility-dataspace.eu/catalog/-1257235213/-439825952/1892951068/-575473219/2093720462",
      "ids:title" : [ {
        "@value" : "",
        "@type" : "http://www.w3.org/2001/XMLSchema#string"
      } ],
      "ids:description" : [ {
        "@value" : "",
        "@type" : "http://www.w3.org/2001/XMLSchema#string"
      } ],
      "ids:action" : [ {
        "@type" : "ids:Action",
        "@id" : "https://w3id.org/idsa/code/USE"
      } ],
      "http://www.w3.org/2002/07/owl#sameAs" : {
        "@id" : "https://dataspaceconnector:8080/api/rules/4d173dba-bbfa-4b69-a756-97345535df1e"
      }
    } ],
    "ids:contractStart" : {
      "@value" : "2022-12-08T00:00:00.000Z",
      "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
    },
    "ids:contractEnd" : {
      "@value" : "2022-12-31T00:00:00.000Z",
      "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
    },
    "ids:contractDate" : {
      "@value" : "2022-12-08T10:25:02.354Z",
      "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
    },
    "http://www.w3.org/2002/07/owl#sameAs" : {
      "@id" : "https://dataspaceconnector:8080/api/contracts/7a62f208-53bb-48e8-9cb3-81d3b51b62d9"
    }
  } ],
  "ids:title" : [ {
    "@value" : "Test Case",
    "@language" : "en"
  } ],
  "ids:description" : [ {
    "@value" : " Test case for the DFRS Workshop",
    "@language" : "en"
  } ],
  "ids:keyword" : [ {
    "@value" : "Test",
    "@language" : "en"
  }, {
    "@value" : "DFRS",
    "@language" : "en"
  } ],
  "ids:standardLicense" : {
    "@id" : "https://creativecommons.org/licenses/by/4.0/"
  },
  "ids:paymentModality" : {
    "@type" : "ids:PaymentModality",
    "@id" : "https://w3id.org/idsa/code/FREE"
  },
  "ids:modified" : {
    "@value" : "2022-12-08T10:25:00.311Z",
    "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
  },
  "ids:publisher" : {
    "@id" : "https://mobility-dataspace.eu"
  },
  "http://www.w3.org/2002/07/owl#sameAs" : {
    "@id" : "https://dataspaceconnector:8080/api/offers/5033ca17-3eb7-447e-a583-44d7a56ad030"
  },
  "http://w3id.org/mds#transportMode" : {
    "@value" : "Road",
    "@type" : "http://www.w3.org/2001/XMLSchema#string"
  },
  "http://w3id.org/mds#dataCategory" : {
    "@value" : "Traffic Information",
    "@type" : "http://www.w3.org/2001/XMLSchema#string"
  },
  "http://w3id.org/mds#dataSubcategory" : {
    "@value" : "Hazard Warnings",
    "@type" : "http://www.w3.org/2001/XMLSchema#string"
  }
}

Bug Report

Describe the Bug

The broker-extension jar is not published as the publishing block is missing.

Feature Request

Type of Issue

Enhancement

Describe the ideal solution or feature request

Automatically building SNAPSHOT-Versions for Extensions.

Bug Report

Describe the Bug

The documentation says The test environment is set by default., but presents dev enivronment links.
The docker compose file contains test environment links.

Expected Behavior

Only one environement (dev) shall be used at this stage.

Feature Request

In order to unregister the connector at the broker, the unregisterConnectorAtBroker()method has to be implemented.

Type of Issue

feature

Why Is the Feature Desired?

Feature necessary for the deprovisioning of the connector.

Unregistering a connector at shutdown is missing from the diagram.

Is this still needed? Referenced issue says it is solved.

Bug Report

After following the tutorial from the Mobility Data Space here and deploying our own environment on kamatera to have something online to play with and better understand the interactions between multiple connectors. When starting the projet using the provided docker-compose configuration however, I get an error.

Description

Current status is that, upon running the project using the docker compose up command, the EDC container is failing on the following error:

edc         | 2023-03-01 14:46:59 Error booting runtime: java.sql.SQLException: No suitable driver found for  
edc         | org.eclipse.edc.spi.persistence.EdcPersistenceException: java.sql.SQLException: No suitable driver found for 
edc         | 	at de.sovity.edc.extension.postgresql.connection.DriverManagerConnectionFactory.create(DriverManagerConnectionFactory.java:44)
edc         | 	at org.eclipse.edc.sql.datasource.ConnectionFactoryDataSource.getConnection(ConnectionFactoryDataSource.java:40)
edc         | 	at org.flywaydb.core.internal.jdbc.JdbcUtils.openConnection(JdbcUtils.java:48)
edc         | 	at org.flywaydb.core.internal.jdbc.JdbcConnectionFactory.<init>(JdbcConnectionFactory.java:75)
edc         | 	at org.flywaydb.core.FlywayExecutor.execute(FlywayExecutor.java:146)
edc         | 	at org.flywaydb.core.Flyway.baseline(Flyway.java:297)
edc         | 	at de.sovity.edc.extension.postgresql.migration.FlywayService.migrateDatabase(FlywayService.java:51)
edc         | 	at de.sovity.edc.extension.postgresql.migration.DatabaseMigrationManager.migrateAllDataSources(DatabaseMigrationManager.java:36)
edc         | 	at de.sovity.edc.extension.postgresql.PostgresFlywayExtension.initialize(PostgresFlywayExtension.java:33)
edc         | 	at org.eclipse.edc.boot.system.injection.lifecycle.InitializePhase.initialize(InitializePhase.java:37)
edc         | 	at org.eclipse.edc.boot.system.injection.lifecycle.ExtensionLifecycleManager.initialize(ExtensionLifecycleManager.java:61)
edc         | 	at org.eclipse.edc.boot.system.injection.lifecycle.ExtensionLifecycleManager.initialize(ExtensionLifecycleManager.java:61)
................
edc         | 	at de.sovity.edc.extension.postgresql.connection.DriverManagerConnectionFactory.create(DriverManagerConnectionFactory.java:42)
edc         | 	... 24 more
edc         | 
edc exited with code 255

Being a complete newbie in Java, I cannot figure out how to workaround that one (I did a few tricks on the certificates generation mecanism to get the proper JKS). Pretty sure something evident is missing

Expected Behavior

The EDC container should run, as expected without any critical errors.

Steps to reproduce the behavior:

1. Clone the project
2. Follow the steps from the documentation here to get the certificate
3. Launch the containers using docker compose up
4. See error

Context Information

Add any other context about the problem here.

• Environment: Dev but online on Katamera
• OS: Ubuntu Server with Docker and Docker-compose installed, plus headless JRE-8
• ...

docker-compose.yaml in sovity/edc-ui#46 was reviewed by @SebastianOpriel

align both files in terms of ports, (attribute) order and naming, resulting in two near-identical files where one is for the MDS with extensions (edc-extensions) and one is open source (UI)

          I would add that under Windows e.g. Git Bash can be used. I tested the script with Git Bash and it works fine.

Originally posted by @ip312 in #19 (comment)

Feature Request

Description

Please refactor the repository to use the test environment instead of dev environment (see #8)

• Docker-compose
• Documents
• Code

In case code adjustments were necessary, please create a new release. If adjustments are just in docker-compose and docs, no new release is necessary.

Feature Request

Description

The development image should use a minimal setup of extensions, which is compatible with the OS-Ui.

Feature Request

Type of Issue

feature

Describe the ideal solution or feature request

On release the pipeline should trigger gradle publish not just for the whole project but also for every single extension.

Which Areas Would Be Affected?

CI

Solution Proposal

• add gradle publish to every extension
• find out how to trigger publish with the pipeline

Feature Request

Type of Issue

Enhancement

Describe the ideal solution or feature request

Publish EDC-Policies

• Time-Interval-Restricted Policy
• Participant-Restricted Policy

The different readme are outdated because the docker-compose has been moved to the root directory.

Feature Request

Description

Below you find an example how to add data sources. However, there are asset attributes that are not present in Postman, namely originator and originatorOrganisation. So far I have thought that we use publisher (for data provider) and sovereign (for data owner). Is there still an originator in the IDSA world? What role does it have? If so, it would be good to extend the postman collection so that originator and originatorOrganization are also there. Otherwise, we are not entirely consistent.

To answer where and how Asset Data Source Configuration happens in EDC, the API call that creates the asset also provides the data source configuration.

This is an example request that creates an asset:
POST /api/v1/data/assets

{
    "asset": {
        "properties": {
            "asset:prop:id": "urn:artifact:test",
            "asset:prop:name": "test",
            "asset:prop:originator": "http://localhost:3000/v1/ids/data",
            "asset:prop:originatorOrganization": "Example GmbH",
            "asset:prop:language": "https://w3id.org/idsa/code/EN"
        }
    },
    "dataAddress": {
        "properties": {
            "type": "HttpData",
            "method": "POST",
            "baseUrl": "http://my-api/",
            "contentType": "application/json",
            "header:Accept": "application/json",
            "header:SomeOtherHeader": "Value",
            "body": "{\"my\": \"query\"}"
        }
    }
}

A full list of properties for “HttpData”-type Data Sources known to us can be found here:

sovity/edc-ui#28

Please note that depending on configured data management endpoint base path the URL might differ.

Bug Report

Description

Trying to run tests via gradle does not catch any tests. This becomes appearent when trying to run individual tests from IntelliJ and having it configured to run tests via gradle.

Expected Behavior

Gradle should find tests.

Steps to Reproduce

./gradlew :extensions:contract-agreement-transfer-api:test --tests "de.sovity.edc.extension.contractagreementtransferapi.controller.ContractAgreementTransferApiControllerIntegrationTest"

Or running any individual test / test method via IntelliJ while Settings > Build, Execution, Deployment > Build Tools > Gradle > Run Tests Using is set to Gradle (Default).

Possible Implementation and Work Breakdown

• (Optional) Make executing a single test via gradle work
• Find evidence that running all tests actually executes tests.
• Find evidence that our pipeline is actually running tests.

Bug Report

Description

There are both git pull_request_template.md and PULL_REQUEST_TEMPLATE.MD checked in which leads to the following git warning: warning: the following paths have collided (e.g. case-sensitive paths on a case-insensitive filesystem

The pull_request_template.md should be removed.

Feature Request

Type of Issue

Docs

Describe the ideal solution or feature request

A sequence diagram for what is happening inside the extension would be nice. An example is here: https://github.com/eclipse-edc/Connector/tree/main/docs/developer/architecture/catalog

Which Areas Would Be Affected?

Docs

Why Is the Feature Desired?

Transparency, understandability, reusability

How does this tie into our current product?

Reusability and adjustability of code

Solution Proposal

Create Sequence diagram as puml (e.g. VS Code or IntelliJ extension) and place as .png+.puml inside broker-extension in appropriate docs folder.

Bug Report

Description

Once the project is deployed and running, I tried creating assets (it works) but I cannot figure out the API URI to use to access the dataset itself.

Both dataset and connectors are available through the MDS broker:

• https://catalog.test.mobility-dataspace.eu/connector/connector?id=https%3A%2F%2Fbroker.test.mobility-dataspace.eu%2Fcatalog%2F-1179781081
• https://catalog.test.mobility-dataspace.eu/resources/resource?id=https://broker.test.mobility-dataspace.eu/catalog/-1179781081/1902456861/526382240

But we do not get how to access the Data itself from the dataset.
Given the current configuration, the data API looks unavailable but we are not sure how to configure it.

Those API endpoints never returns anything usable:

• https://edc-dev.startinblox.com/catalog/MySuperContract-urn:artifact:superduperdataset
• http://edc-dev.startinblox.com:11003/api/v1/ids/data

Expected Behavior

As we understood it, the URL https://edc-dev.startinblox.com/catalog/MySuperContract-urn:artifact:superduperdataset should actually give you access to the description of the data, or to the data itself ?

Observed Behavior

It just freezes. Blank screen.

Context Information

The docker-compose.yml looks like:

  edc-ui:
    image: ghcr.io/sovity/edc-ui:latest
    container_name: edc-ui
    ports:
      - '11000:80'
    environment:
      - EDC_UI_ASSET_PROP_ORIGINATOR_ORGANIZATION=Startinblox Dev Connector
      - EDC_UI_ACTIVE_PROFILE=mds-open-source
      - EDC_UI_DATA_MANAGEMENT_API_URL=http://edc-dev.startinblox.com:11002/api/v1/data
      - EDC_UI_DATA_MANAGEMENT_API_KEY=ApiKeyDefaultValue
      - EDC_UI_CATALOG_URLS=http://edc-dev.startinblox.com:11003/api/v1/ids/data
      - EDC_UI_ASSET_PROP_ORIGINATOR=http://edc-dev.startinblox.com:11003/api/v1/ids/data
  edc:
    container_name: edc
    image: ghcr.io/sovity/edc-mds:latest
    environment:
      # Basic Configuration
      EDC_IDS_TITLE: 'Startinblox EDC Connector'
      EDC_CONNECTOR_NAME: 'Startinblox EDC Connector'
      EDC_IDS_DESCRIPTION: 'Minimal configured Open Source EDC built by sovity'
      EDC_IDS_CURATOR: https://startinblox.com
      EDC_HOSTNAME: edc-dev.startinblox.com
      EDC_IDS_ENDPOINT: http://edc-dev.startinblox.com:11003/api/v1/ids
      EDC_API_AUTH_KEY: ApiKeyDefaultValue

      # Data Space Configuration
      EDC_OAUTH_CLIENT_ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
      EDC_KEYSTORE: /resources/vault/edc/edc-dev.startinblox.com.jks
      EDC_OAUTH_TOKEN_URL: https://daps.test.mobility-dataspace.eu/token
      EDC_OAUTH_PROVIDER_JWKS_URL: https://daps.test.mobility-dataspace.eu/jwks.json
      EDC_BROKER_BASE_URL: https://broker.test.mobility-dataspace.eu
      EDC_CLEARINGHOUSE_LOG_URL: https://clearing.test.mobility-dataspace.eu/messages/log

      # Deployment Configuration
      WEB_HTTP_PORT: 11001
      WEB_HTTP_PATH: /api
      WEB_HTTP_DATA_PORT: 11002
      WEB_HTTP_DATA_PATH: /api/v1/data
      WEB_HTTP_IDS_PORT: 11003
      WEB_HTTP_IDS_PATH: /api/v1/ids
      EDC_IDS_ID: urn:connector:example-connector
      IDS_WEBHOOK_ADDRESS: http://edc-dev.startinblox.com:11003

Thanks in advance.

If Connector Name, Curator and Maintainer are adjusted in docker-compose,, the old values still seem to be visible in the broker.

Feature Request

Type of Issue

Cleanup

Describe the ideal solution or feature request

• Remove Option B https://github.com/sovity/edc-extensions#option-2-manually-with-keystore-explorer
• Keep other parts of the Readme.md consistent
• Add hint with regards to necessary command line packages (openssl, keytool) and wsl/linux

Discussion

Situation

In the EDC sphere convention-over-configuration seems to have been replaced by full configurability of extension http ports and base URLs. Combined with us often using multiple extensions the amount of ports we need to keep track of is alot. Combined with us having multiple environments (test-bed, production, getting-started docker-composes, fake backend in UI):

Proposal

I think it's time we create a convention for our ports, which starts with:

• Naming our "common" ports of our control- and data planes.
• Naming our "endpoints" and deciding common base URLs.
  • Let's be real, we have one control plane and one data plane, ideally we would not even have multiple ports and apis should follow same naming pattern.
• Write them in the README.md
• First adoption might be to use them in the getting-started docker-compose files in both edc-extensions and edc-ui.
• (adv) add those ports as defaults in Dockerfiles
• (adv) gradually make other environments use those ports

Benefits

Easier explaining and onboarding of new people.

Ports are never just configured once, but have to be used again and again when referencing said endpoints

@efiege @tmberthold

Feature Request

Type of Issue

Enhancement

Describe the ideal solution or feature request

The connector should be build using the policy-extensions.