Contract Agreement Events #256
Description
Feature Request
Contract negotiations in DSP are immutable by design, and the resulting contract agreements inherit this immutability. However, after a contract agreement is established, there are scenarios where it must be associated with subsequent events. Two key use cases illustrate this need:
Claims Updates
A consumer (C) negotiates a contract agreement with a provider (P) using a membership credential (M). The agreement grants indefinite access to an API.
Over time, credential M expires and is replaced by a renewed credential (M′), ensuring that C remains a continuous member of the dataspace.
Currently, if C has an active transfer process initiated under M, the provider P may suspend or terminate it when M expires. This behavior is undesirable, as C’s membership status has not changed.
DSP should provide a mechanism for C to notify P of updated credentials associated with an existing contract agreement.
Contract Retirement
A contract agreement may be “retired” by one of the parties. The term “retired” is intentionally used instead of “canceled” to avoid legal implications (e.g., this may correspond to an opt-out in legal terms).
At present, DSP does not provide a way to model or communicate this state change.
Proposed Solution
Both use cases can be addressed by introducing a Contract Agreement endpoint that accepts notification events. The event model should be extensible to support additional use cases in the future.
Claims Updates
The consumer (C) notifies the provider (P) by sending a claims-updated event associated with a contract agreement.
In dataspaces using DCP, this event can be sent as a POST request containing a self-signed token that includes an access token for C’s Credential Service. The provider can then follow the DCP presentation flow to retrieve updated verifiable presentations (VPs) with the latest claims.
Contract Retirement
Either party may send a contract-retired notification event. The receiving party’s behavior can be dataspace- or policy-specific (e.g., accept, reject, or ignore the request).
Backward Compatibility
This functionality can be introduced in a backward-compatible manner through a DSP profile. The profile would define:
• An additive Contract Agreement endpoint
• An additional JSON-LD context containing new terms extending the 2025 DSP dspace context
The original 2025 DSP context remains unchanged, avoiding any breaking changes or the need to modify the context URL. Connectors supporting this feature would include both the base DSP context and the additional profile context.