[Concept] Enhancing Transparency and Management of EDC Contract Agreements and Policies

[ds-mwesener]

As a system administrator,
I want a mechanism to log all contract agreement IDs associated with EDC assets and policies,
so that there is clear transparency and historical tracking of changes and updates.

Links:

• blocks Changing policy manually for an already published asset #1064

Hints / Details

• The history should reflect a list of contract agreement IDs with dates to keep the history of old contracts transparent.
• There should be a clear delineation of assets and policies that require updates and those that do not.

Process

1. Call the registry API including a filter to get the relevant asset by globalAssetId. (Ask Jaro for specific details.)
   1a. Ensure access to the registry element ID is maintained as it will be needed along with the globalAssetId.
2. Extract the EDC asset ID from the subprotocol body.
   2a. Ensure access to this information is maintained along with registryId and globalAssetId for future updates.
3. Filter and retrieve contract definitions using the EDC asset ID to check if the current policy matches the existing one. If the policy remains the same, no new contract is required. If not, proceed to create new EDC asset, EDC policy, and EDC contract definition as needed.
4. Create new EDC contract definitions as described in step 3 if necessary.
5. Utilize the registryId associated with the globalAssetId for updates.
6. Update the registry subprotocol body with the new EDC asset ID to reflect changes.

Acceptance Criteria

• Create a concept which defines the flow including request examples.
• The system logs every contract agreement ID whenever there is an update to the associated EDC assets and policies.
• The system provides a history view where each entry includes the date of the contract and its associated ID.
• The system ensures that EDC assets that do not need updates are not updated.
• The system updates the EDC policies and contract definitions only if there are changes in the policies.
• For notifications we need to define which policy should be used for contractNegotiation, this could be a button in the policy management table which sets a policy as active (just example)
• Mock has been created how a policy will be set to active for notifications.

Out of Scope

• Managing or updating registry APIs or other systems not directly handling EDC assets and policies.
• Detailed mechanisms of how external systems interact with this update mechanism.

[ds-mwesener]

Todos:

Tickets for implementation needs to be created

Open questions:

Do we want to set an active policyfor notification or do we want to pick the policy based on the BPN?
Example: I have the bpn BPNCML1 and want to send it to BPNCNKC. When trying to send the notification the offer policy of BPNCNKC will be validated against a policy with the BPN: BPNCNKC created in tracex: BPNCML1

How to handle multiple policies (same bpn) as well as multiple offers with different policies.

• FindFirstValid?
• All match?

[ds-crehm]

Concept was merged with #1007

It's available here: https://github.com/eclipse-tractusx/traceability-foss/blob/main/docs/concept/%231108-policy-management-enhancement/%231108-policy-management-enhancement.md

Ready for review.

[mkanal]

• "User can not create valid, active policies for BPNs that already have a valid, active policy" - do we have the term of active and inactive policy? If not we should not claim that. Please use term "valid" and "invalid" defined by the validUntilRange...

• "If the EDC of the receiving BPN provides multiple contract offers, Trace-X will check if any of them are active and match the own policy definition. In that case, the data will be sent. This applies to data provisioning and notification transmission." - Which artefact is mentioned here with "any of them" (policy or DataOffer)

• "After startup, additional policy is created for the own BPN. Its constraints are identical to the default-policy and it will be used for the initial contractOffer creation." This requirements is mentioned nowhere. Please remove this requirement.

• "contractOffer is only updated when the policy for the own BPN is changed or when a new policy for the own BPN is created." In case the contractOffer is aligned with the default policy and this will change the contractOffer is updates as well.

• "There must always be one policy with the own BPN included. It can not be deleted. The validUntil date for this one should be null and cannot be set to a different value." Please let us discuss about this sentence I do not understand it correctl.y

• " Default-policy is always used for sending notifications, when there is no policy defined for the receiver BPN." There is a mismatch to point 6 and 7

• "A part can be republished with a different policy -> in this case the policy must be updated with the chosen policy and then republished. For this the policy update process below must be used and then the existing publish-process can be used to republish and synchronize the part." > This might be to complicated and not reasonable or comprehensible to the user. Admin should be able to republish assets and choose another policy without having to change the current one.

• "When a policy is updated, all parts that used this policy must be updated and republished with the new policy. In this case, all parts using that policy must be updated. " > What is the difference between sentence one and two?