EDC - Configurable Verifiable Credential to ODRL constraint mapping

[DanielaWuensch]

Problem: Currently, for each check between a ODRL Policy (such as Data Exchange Governance Policy) and Verifiable Presentations (i.e. holding a valid DataExchangeGovernanceCredential), a custom extension has to be developed.

Suggested solution: Develop a declarative way to configure checks - lowering the bar of entry for individual credential-checks. This would enable the use of verifiable credentials for any constraint, which does not to be fixed in EDC development phase but can be configured while using EDC in a data space.

Impacted components

• Upstream EDC
• Tractus-X EDC
• maybe CX-0018, CX-0050 standards
• Catena-X e.V. profiles, Tractus-X ODRL profiles

[DanielaWuensch]

Scope to be refined what constraints will be configurable based on ODRL

[jimmarino]

There are a number of things to consider here. First, much of this has already been supported since the May release. See the specification here.

Leaving aside the technical, security, and performance issues with implementing a feature where an expression language such as JsonPath is permitted within an ODRL constraint, we should define what a "declarative approach" means in practice.

It's important to keep in mind that unless TX-EDC implements very complex dynamic configuration reloading at runtime, a redeployment will need to be performed for all updates. This means technical operators will always be involved in significant policy updates.

Another point is any policy change needs to be properly tested. Specifically, it should never be the case that someone updates policy using some form of declarative language and does not write automated tests. Even if a declaration is used, test cases - in code - must be written and included in a build pipeline. Writing a policy extension in the EDC is trivial and not more difficult than writing a test which needs to be done anyway.

[lgblaumeiser]

@DanielaWuensch @arnoweiss : Actually, after our recent discussion on the DataExchangeGovernance Credential, I have to admit, I do not understand the gap we are talking about in this feature. From my understanding, it was out of the box possible to request the value DataExchangeGovernance and the corresponding credential in a "FrameworkAgreement" ODRL atomic constraint. That was my understanding of what we discussed as missing in our meeting on June 28th, when we discussed this proposal. Can you give some insights of the existing gap that you wish to be filled? Thanks!

[arnoweiss]

• Provider acts as issuer and verifier for VCs. While the DataExchangeGovernanceCredential attests claims that are accepted network-wide, a Provider may want to enforce their individual ContractReferences with a self-issued VC that they can revoke.
• Multi-network EDC Trusting multiple Issuers is implemented. Processing multiple credential schemas isn't which raises a permutation problem: If an organization participates in network A only, that's simple. But there'd have to be a separate build for a company in network A & B. And network A, B, C.

On implementation: There could be a Management-API endpoint that a provider uses to register mappings. When negotiation is started by the consumer, all constraints that are backed with a mapping provider-side are evaluated against a VC, all others aren't. That'd keep the expressions out of the ODRL-policies.

[jimmarino]

These cases still need to be tested by automated infrastructure. There is no getting around writing code. 😊

More broadly, changes in runtime behavior should always be part of the deployment process, not outside of it. This philosophy guided EDC's design not to use dynamic configuration.

[stephanbcbauer]

Presented in the DRAFT Feature Freeze -> Committer is available

[lgblaumeiser]

@jimmarino @arnoweiss Can you please discuss the issue and come to a conclusion on what to do with this requirement. Thanks!

[DanielaWuensch]

In release 25.03 the policy management will be approached in a generic way to ensure any CX specific anchors in the VC verification. So, I will close this issue.