Dependencies Connector & Data Governance Kit

[drcgjung]

This discussion should collect all requirements/features related to the intersection of Connector & Data Governance Kits.

• EDC control plane management API should allow to do an update/PUT request on an already negotiated/agreed asset which does not change its "description" or "offer appearance" but could help to manage its relation to contract definitions.
  • PUT on just private properties such that Contract Criterion would disable or enable offer in the future should be possible.
• Connector Management Interface Standard
  • CX-0018 was "locked" by a different CR
  • separate Standard than CX-0018 is advisable anyway because certification/criteria have different target roles:
    • Enablement Service Providers for Managable EDCs and
    • App Providers for Managing Applications
  • abstract interface versus versioned API, maybe using a link to a "family" of APIs

[drcgjung]

Feature Governance of Dynamic Policies, Contract Definitions and Assets

Motivation

Data Governance requires dealing with dynamic (also: temporary or even scheduled) changes to implemented policies, contracts and assets.

On the other hand, one major principle of a dataspace is that you can trace/audit every transaction that has been made.

This feature should find a way to bring both (superficially conflicting) goals under one principle

Performing a test

We know that assets cannot be deleted once they have been negotiated. This does not hold for contractdefinitions and policies (as long as they maintain referential integrity from contractdefintions -> policies).

So the actual question is whether we find a way to "deactivate" or "version" assets on the fly. For that we setup a test

• with two EDC 0.5.1 parties, provider and consumer
• with a simple http backend
• with a provider policy, a contract definition and an asset (whose privateProperty "enabled" is evaluated by the contract definition)
• consumer sees the asset in its catalogue request
• consumer negotiates asset and initiates a transfer
• asset cannot be deleted (as expected)
• but asset privateProperty "enabled" can be changed (as can any property or dataaddress property including the type)
• consumer does not see the asset in its catalogue anymore

Proposal

• Introduce a private property "enabled" or "active" which is used in any contract definition (check upon being "true")
• Instead of deleting the asset, deactivate it
• Versioning can be done by either
  • introducing a new technical asset (using a technical id which combines a "logical" id with a "version") and deactivating the old version or
  • by overriding/reactivating the existing technical assets.

[drcgjung]

Possible DataAddress-Caching Bug in TX EDX Control Plane (up to 0.6.0-rc1)

Steps to Reproduce

• Setup a Provider Connector hosting an HttpData Asset with a certain baseUrl (hosting Result1)
• Setup a Consumer Connector
• Lookup Offer, Negotiate Agreement, Start HttpProxy Transfer -> Result1
• Make a Put on the Asset to change the baseUrl to some other place (hosting Result2)
• Check the effectiveness by List Asset
• Next restart the Consumer Connector (or use another Connector instance with the same VP)
• Lookup Offer, Negotiate Agreement, Start HttpProxy Transfer -> Result1!!!

What we would have expected

Result2

Comments

The transfer, agreement, offer ids all look different and not suspicious.
Did not have the time to debug through, though. That has to wait 2 weeks until after my holiday

[stephanbcbauer]

@drcgjung since this discussion is ancient and my assumption is you used this for feature planning in older releases, I close this discussion.