Split up ContractOffer object

[paullatzelsperger]

Problem description

Currently, the ContractOffer fulfills two separate purposes:

1. Convey the initial "data offer" from provider to consumer
2. Serve as protocol envelope during the contract negotiation

Those two situations have different requirements, for example for the initial data offer the entire Asset needs to be sent to the consumer, whereas during negotiation it is sufficient to carry the assetId. Similarly, it might be sufficient during negotiation to carry just the policyId instead of the entire Policy.

Proposed solution

• ContractOffer: limit the use to the initial offer to consumers. Possibly remove contractStart and contractEnd, since no contract is yet in effect.
• rename ContractOfferRequest to ContractNegotiationRequest
• create new object ContractOfferDescriptor (working title), which is contained in the ContractNegotiationRequest:

  public class ContractOfferDescriptor {
    private String id; //original offer id
  
    private String policyId; //references the original policy
    private Policy customPolicy; //optional: if the consumer wants a custom policy. If set, then policyId must be ignored.
    private String assetId; //references the originally offered asset
  
    private URI provider;
    private URI consumer;
  }

Open Questions:

In case the consumer wants to send back a custom policy, should we send back a full ContractOffer instead of the -Descriptor?

• Pro: avoids the nullable policy field and having a sparsely populated -Descriptor
• Contra: requires ContractNegotiationRequest and the handlers to be able to handle both types, possibly through object inheritance. I.e. ContractOffer and ContractOfferDescriptor could have a common base class.

[ndr-brt]

Completely agree on separating the object for two different contexts.

I have a question about the "customPolicy": it will have an id? Would it be the same as Policy or it should be represented by another class?

[paullatzelsperger]

I think it should be a conventional Policy object, with an ID. The consumer could already have this policy in their PolicyStore.

[ndr-brt]

In the case the consumer won't have that policy in the PolicyStore should it store it?

[sebbader]

From an ODRL/IDS perspective, splitting it up is a bit of a tricky thing to do. During the negotiation, the serialised object will be of type odrl:ContractOffer in any case. Means, the EDC internal representation can of course be slit - but it might be a challenge for the serialiser to select the right class then.

[juliapampus]

I agree, but mapping to and from IDS with the serializer is done for communication purposes only, the IDS objects will not be used for any processing. EDC objects are uniquely identified by their IDs.