EDR dataAddress.agreementId carries the provider's local agr_id instead of the shared agreementId

[AndrYurk]

Since #5275, ContractAgreement has two identifiers:
id (agr_id) — the local, per-connector entity id (FK in ContractNegotiation/TransferProcess, used in the management APIs).
agreementId (agr_agreement_id) — the shared id that "acts as the id in the protocol layer between the consumer and provider" (per the DR).
The DR is explicit that the local id "will no longer represent the identifier of the contract shared between parties," i.e. anything crossing the party boundary should use the shared agreementId.
Observation (two separate connectors)
On a consumer TransferProcessStarted callback, the two ids don't line up:

{
  "type": "CONSUMER",
  "contractId": "f777d84d-6f87-40c9-801a-4535d4810f42",   // consumer's LOCAL agr_id
  "dataAddress": {
    "properties": {
      "process_id": "946758f0-...",  
      "participantId": "did:web:...:BPNL...81BS",        
      "endpoint": "https://provider-...-edc/.../api/public",
      "agreementId": "0a620e7e-b441-4569-97c2-d684deb146d7",// provider's LOCAL agr_id
       ....
    }
  }
}

The dataAddress is minted by the provider data plane, and its agreementId is the provider's local agr_id. That value doesn't appear in any consumer-side API (the consumer's @id and agreementId resolve to its own ids), so the consumer cannot correlate the EDR back to its agreement.

Questions
Is it intended that the EDR dataAddress.agreementId exposes the provider's local agr_id, or should it be the shared agr_agreement_id (consistent with the DR's "protocol layer between consumer and provider")?

[wolf4ood]

Hi @AndrYurk

The PR mention did not touch any data addresss or EDR generation. Just for clarification

The data address is a DSP concept and fly over DSP protocol. The EDR is a client side concept materialized in the EDR API/Cache which wrap the data address from DSP and enrich it with local information like agreement, transfer process and other info.

I don't recognize that shape of the data address object which I guess is from a transfer process callback json. On my environment using edc 0.18.0 I get this object

{
  "id": "968b05e0-d9ec-481a-a018-1eea69a59473",
  "at": 1785963030240,
  "payload": {
    "transferProcessId": "357ba57c-fdc1-414a-b699-ab6dd63fddb5",
    "callbackAddresses": [
      {
        "uri": "http://localhost:46707/hooks",
        "events": [
          "transfer.process.started"
        ],
        "transactional": true,
        "authKey": null,
        "authCodeId": null
      }
    ],
    "assetId": "87f31389-2a08-4f3f-aa73-b8eb84fc9aa0",
    "type": "CONSUMER",
    "contractId": "9c9856cb-e84a-48e5-b5e2-ee6d89fe3fa5",
    "participantContextId": "urn:connector:consumer",
    "protocol": "dataspace-protocol-http:2025-1",
    "dataAddress": {
      "properties": {
        "https://w3id.org/edc/v0.0.1/ns/type": "https://w3id.org/idsa/v4.1/HTTP",
        "https://w3id.org/edc/v0.0.1/ns/endpoint": "http://localhost:56810/proxy",
        "https://w3id.org/edc/v0.0.1/ns/authType": "bearer",
        "https://w3id.org/edc/v0.0.1/ns/endpointType": "https://w3id.org/idsa/v4.1/HTTP",
        "https://w3id.org/edc/v0.0.1/ns/authorization": "<token>"
      }
    }
  },
  "type": "TransferProcessStarted"
}

which does not contain the agreementId nor the participantId nor the process id. how does those properties gets populated in your case?. If in a custom dataplane on the controlplane -> dataplane message you only get the local agreement id

The contractId is already there and can be used for correlation upon receiving this callback.

[AndrYurk]

Hi @wolf4ood, thanks for the answer. The data address I mentioned was received as a callback for the transfer.process.started event (sorry that I didn't mention it before). Note that for the event contract.negotiation.finalized, the agreementId field is a shared agr_agreement_id.