-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structure DigitalTwinId + "-" + SubmodelId
is not allowed in the offerId
field from contract negotiation request
#484
Comments
DigitalTwinId + "-" + SubmodelId
is not allowed in the offerId
from contract negotiation request
DigitalTwinId + "-" + SubmodelId
is not allowed in the offerId
from contract negotiation request DigitalTwinId + "-" + SubmodelId
is not allowed in the offerId
field from contract negotiation request
The problem here is, that on contract negotiation, we combine the contract-definition-id, the asset-id and a random UUID into one string using the colon ":" as separator: As this is not specific to Tractus-X EDC, but rather the upstream, we should deal with this there. [edit]: I created an issue in upstream EDC: eclipse-edc/Connector#3211 |
We looked at your example once again, and it seems like there is two issues with you code:
Nevertheless, we will try to make the |
this has been fixed upstream by encoding the 3 parts of the id, will be part of the next release: eclipse-edc/Connector#3211 |
Awesome to hear that! Thank you @paullatzelsperger and @ndr-brt! That not only affected our product also affects the IRS for example since they are all using this urn:uuid: prefix ;) |
I assume that we then also need a patch for 0.4.1, otherwise none of the use cases/products can use 0.4.1 at the moment. @stefan-ettl I guess a ZF colleague has already told you that. |
Hi @matbmoser we incorporated the upstream EDC fix in the latest Thanks |
Describe the bug
We at Catena-X were using the target as digital twin id + the submodel id to configure our assets at the providers.
At the previous version of the edc < v0.4.1 it was posible to use the following DID construction of offerid:
# digitalTwinId + "-" + submodelId urn:uuid:32aa72de-297a-4405-9148-13e12744028a-urn:uuid:699f1245-f57e-4d6b-acdb-ab763665554a
Now the problem comes since the offer Id needs to have the following structure:
This causes that when we start the contract negotiation the request stays in state
REQUESTING
and never finds the correct asset.Here is how you can reproduce it:
To Reproduce
1. Call the catalog:
2. Start contract negotiation:
3. Get negotiation:
Log at provider side:
DEBUG 2023-06-14T14:51:58.321440567 [Provider] Contract offer rejected as invalid: The ContractDefinition with id %s either does not exist or the access to it is not granted. DEBUG 2023-06-14T14:52:15.33309943 DSP: Incoming ContractRequestMessage for contract negotiation process DEBUG 2023-06-14T14:52:15.334312952 [Provider] Contract offer rejected as invalid: Invalid id: 1:urn:uuid:32aa72de-297a-4405-9148-13e12744028a-urn:uuid:699f1245-f57e-4d6b-acdb-ab763665554a:3a32e390-2dbf-4c22-894f-31ff6332919e
4. Negotiation tries to terminate but stays in a loop:
Status when asked for the negotiation:
5. After he tries to terminate 7 times he terminates.
Payload from negotiation response after terminated:
Working Example:
Lets do the same as before but using a simple target id like: "3"
1. Request Catalog:
2. Start negotiation:
3. Get negotiation
Logs at provider:
Expected behavior
It should work even if we use DIDs as targets. Because this has been standardized between the companies and is a way to search the asset by target in the EDC provider side.
Context Informations
Add any other context about the probleme here.
Possible Implementation
Ideas:
The text was updated successfully, but these errors were encountered: