So far, there are models for storing identities, assets and download_requests. As per #3, download_requests should be dropped (in SEDIMARK, that is a task for dataspace components). For the other two models I'm not really sure whether they should remain there.
Is the binding between eth_address and did needed when it is on the did document? not sure what fragment refers to, but why is vcredential here? should it be a secret stored on stronghold?
Then, regarding Assets, why are they stored in the database? Aparently, no calls to the asset registration smart contract is done from the connector so I can imagine it is just used for intermediate storage for the Mediterraneus frontend to use. In SEDIMARK case this should not be necessary as the Offering Manager will be the one keeping the state in case needed as well as keeping the binding between NFT token id and offering.
So far, there are models for storing identities, assets and download_requests. As per #3, download_requests should be dropped (in SEDIMARK, that is a task for dataspace components). For the other two models I'm not really sure whether they should remain there.
First, let's consider the info on Identity Model:
Is the binding between eth_address and did needed when it is on the did document? not sure what fragment refers to, but why is vcredential here? should it be a secret stored on stronghold?
Then, regarding Assets, why are they stored in the database? Aparently, no calls to the asset registration smart contract is done from the connector so I can imagine it is just used for intermediate storage for the Mediterraneus frontend to use. In SEDIMARK case this should not be necessary as the Offering Manager will be the one keeping the state in case needed as well as keeping the binding between NFT token id and offering.