bug: ContractAgreement validity is not longer asserted when validating token received by Data Plane

[bscholtes1A]

Bug Report

Describe the Bug

From #2950, the contract validity is no longer checked when validating the token received in input of the Data Plane public API.

See ContractValidationRule.java

Expected Behavior

Token validation should fail if contract is expired.

Observed Behavior

Token validation is successful even if contract is expired.

Possible Implementation

After discussion with @ndr-brt, maybe we want take opportunity of this issue to plug the PolicyEngine in the Data Plane?
However, it would require that the contract agreement information can be retrieved from the Data Plane, which was avoided as per initial design.

[jimmarino]

Can't the token validity always be less than the contract validity, i.e., ensure the token validity is not greater than the contract validity? If the token duration is short enough, this should be OK for most cases.

[bscholtes1A]

Can't the token validity always be less than the contract validity, i.e., ensure the token validity is not greater than the contract validity? If the token duration is short enough, this should be OK for most cases.

This can be an approach, but even that requires to be discussed a bit as for now there is not method computing the contract end date except the ContractExpiryCheckFunction, which only computes this date internally and return a boolean.

[jimmarino]

Can't the token validity always be less than the contract validity, i.e., ensure the token validity is not greater than the contract validity? If the token duration is short enough, this should be OK for most cases.

This can be an approach, but even that requires to be discussed a bit as for now there is not method computing the contract end date except the ContractExpiryCheckFunction, which only computes this date internally and return a boolean.

A utility method could do this by delegating to a Policy evaluator or walking the Policy tree. Let's discuss.

[veronikasiska]

I encountered a case where the contract negotiation was finalised from the consumer side, but terminated from the provider side, due to a mismatch in the client ID and the connector ID in the contract negotiation request ("Invalid client credentials: Invalid counter-party identity"). Still, the file transfer was completed successfully.

Could this be due to the same bug?

[FlorianFehrleIEE]

Is there anything new regarding this bug?
I am sitting on a project, where I need exactly this missing functionality, which leads to stalling of the project at the moment.

[ndr-brt]

wouldn't this be superseded by data-plane signaling? (#3704)

[jimmarino]

wouldn't this be superseded by data-plane signaling? (#3704)

Yes, it should be.