Provider negotiation policy evaluation

[ndr-brt]

I noticed that currently the policy evaluation of a negotiation on the provider side is done in the ContractNegotiationProtocolService.notifyRequested, and the result is influencing the response sent to the consumer (ACK or ERROR).

If the policy doesn't evaluate correctly, the negotiation doesn't get created at all on the provider side, but to me it would look more correct to have the negotiation in REQUESTED state, then asynchronously the policy can be evaluated by the ContractNegotiationManager and the negotiation could transition to AGREED or, eventually, TERMINATED.

It would be a little change but that will open the door for a policy-driven manual negotiation approval (now it can be done by setting the PendingGuard, but to me it looks something that the PolicyEngine should have control on).

wdyt?

[jimmarino]

We need to be careful here of DDOS attacks. I think this is the correct behavior - EDC does not persist rejected agreements. We may want to influence the error sent back.

[ndr-brt]

But on ContractRequestMessage we'll still validating:

• authentication token
• access policy
• asset existence

just moving the contract policy evaluation shouldn't be big of a deal "DDOS wise", but it open up to flows in which the provider can use the policy engine to make a negotiation "manually agreeable".
plus, semantically wise, returning ERROR after receiving a ContractRequestMessage will look more of a validation/message format issue, while, evaluating the contract policy asynchronously will make the flow like this:

• consumer: sends ContractRequestMessage
• provider: message is OK, negotiation is REQUESTED
• provider: async evaluate policy:
  • if success: create agreement and sends ContractAgreementMessage -> AGREED
  • if failure: sends ContractTerminateMessage -> TERMINATED

[ndr-brt]

thinking about the DDOS thing, I think a sort of throttling mechanism could be put in place, e.g.: a participant shouldn't request more than X negotiations on the same offer in a specific time frame.

but I think this is a completely different topic

[jimmarino]

Let's talk about this. I want to avoid persisting objects unless absolutely necessary. One option is to have two phases for policy eval by adding an additional async scope. We should also define better error messages in the case of a sync rejection.