Closed matgnt closed 11 months ago
Yes, as stated, the @id should be used as the correlation id for callback requests. This is necessary to implement reliability guarantees in implementations that choose to do so. The provider is not required to use the correlation id as its internal unique identifier.
The provider is not required to use the correlation id as its internal unique identifier.
Yes, this is how it should be and the text also describes it that way. But the examples look differently. There, the id from the request (of the consumer) is taken as the id on the provider side, which I think can be very misleading. I would propose to use different ids in 2.5.1 (request and response, including the location header) and 2.4.1
Additionally I think we should make a non-normative statement, probably not in http binding, but in the general part, that:
processId is NOT meant to be like a thread id, but only a reference between a request / response (previous state -> next state) reference.
That's at least how I would interpret it. Is this correct? I couldn't find the place (in negotiation) how the usage of processId is described. I can find multiple statements like:
A XXMessage must contain a processId.
But no details about what it should be exactly.
processId is NOT meant to be like a thread id, but only a reference between a request / response (previous state -> next state) reference.
That's at least how I would interpret it. Is this correct? I couldn't find the place (in negotiation) how the usage of processId is described. I can find multiple statements like:
ok, seems I misunderstood this part. It now sounds to me more like an id that stays the same for the entire 'process' / (thread).
The contract negotiation unique id.
It is also part of the example here: https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/message/contract-negotiation.json
but unfortunately not part of the example here (that I used to understand the process...): https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/contract.negotiation.binding.https.md#241-get
I think this caused the confusion. I only figured out because how processId
is used in the transfer process.
I think we should:
The contract negotiation unique id
to:
The contract negotiation unique id that stays the same for the remaining negotiation process.
Optionally we could even extend the information to: It is generated by the consumer as the @id field in the request and will be taken over by the provider as the processId for further reference.
ContractNegotiationError
section to a more general section
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/contract.negotiation.binding.https.md#22-contract-negotiation-errorprocessId
) https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/contract.negotiation.binding.https.md#241-getand from the original issue:
@id
fields in 2.4.1 and 2.5.1We need to discuss this again, because it turns out, EDC does use the processId
also for the path param, e.g. /negotiations/{processId}/agreement
where it expects the callbacks and NOT the @id
from the ContractRequestmessage
from the consumer.
I think whatever is correct, we need to explain this in more detail.
Meeting summary: needs a followup with: @jimmarino @juliapampus @ndr_brt @matgnt
Similar in the transfer process. Here the spec is very clear, but EDC implements it with another interpretation (against the spec in my opinion)
See https://github.com/eclipse-edc/Connector/issues/3253#issuecomment-1619628738
After a discussion (in a smaller group of @jimmarino @ndr-brt ) we agreed on the following:
processId
will be changed into consumerId
and providerId
.Location
header with an id will be removed:id
will use the providerId
consumerId
consumerId
This needs to go through a bigger group to be confirmed, maybe @juliapampus @sebbader-sap @mkollenstart if you could have a look at this.
@sebbader-sap asks for clearer names for consumerId and providerId
e.g. consumerProcessId and providerProcessId
From an implementation/validation perspective, I would opt for including both the provider and consumer IDs in the subsequent messages. Since validation logic often doesn't contain the direction the message is sent to, resulting in generic rules that one of both should be present while in fact that can be wrong.
I do agree with clearer names like consumerProcessId and providerProcessId
What about consumerPid
and providerPid
?
summary from the meeting today: open questions:
consumerPid
instead of providerPid
- use
consumerPid
instead ofproviderPid
what does this mean? should they both exist right?
- how about http binding. is the field still required even though it is transferred via path? what if the 2 ids are different?
I'd say that it should exist also in the request body and it should match with the path one (as it should be done with the @type
field)
- should we include both ids in all messages (when available, meaning not in the start messages...)
I'd vote for a yes.
Simplify transfer and negotiation processes.
processId
will be changed into consumerPid
and providerPid
.:id
will use the providerPid
:id
will use the consumerPid
consumerPid
(or providerPid
)consumerPid
Example:
POST https://connector.consumer.com/negotiations/:consumerPid/agreement
Authorization: ...
{
"@context": "https://w3id.org/dspace/v0.8/context.json",
"@type": "dspace:ContractAgreementMessage",
"dspace:consumerPid": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c97605aab",
"dspace:agreement": {
"@type": "odrl:Agreement",
"@id": "e8dc8655-44c2-46ef-b701-4cffdc2faa44",
"dspace:consumerId": "...",
"dspace:providerId": "...",
}
}
}
providerPid
and consumerPid
(except the initial messages)Example:
POST https://connector.consumer.com/negotiations/:consumerPid/agreement
Authorization: ...
{
"@context": "https://w3id.org/dspace/v0.8/context.json",
"@type": "dspace:ContractAgreementMessage",
"dspace:consumerPid": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c97605aab",
"dspace:providerPid": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c57398-abc",
"dspace:agreement": {
"@type": "odrl:Agreement",
"@id": "e8dc8655-44c2-46ef-b701-4cffdc2faa44",
"dspace:consumerId": "...",
"dspace:providerId": "...",
}
}
}
decided on 31.08.2023 to implement option 2
Done with #151 and #152
Original title: http binding: Negotiation examples with '@id' are misleading and probably security-wise not best practice
During implementation I stumbled over the
@id
fields in the http bindinghttps://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/contract.negotiation.binding.https.md
urn:uuid:dcbf434c-eacf-4582-9a02-f8dd50120fd3
is used in many places, e.g. the GET on thenegotation
resource and also the POST onnegotiation/request
to my understanding, that means the consumer sets an
@id
in its request and the provider would take this very same (consumer given id) under which the consumer can fetch the state of the request (from the provider). I think the provider should NOT take over a consumer given id in any case. The provider MUST generate its own resource id.Yes, the callback needs a correlation to the user given id, correct. But never the provider should make a resource available under the consumer given id as I would read the example right now.
Any thoughts? Maybe just a copy/paste issue?
-- Matthias Binzer