What should be the scope of the DLT connector?

[psotres]

We should decide the scope of this component:

1. Is it going to be a wallet for offloading crypto/identity related operations?
2. Besides 1, is it going to carry out the interactions with the needed smart contracts or should those interactions with JSON-RPC evm endpoints be handled by other components (Frontend, Offering Manager, EDC connector)?

[psotres]

List of potential crypto-related functionalities to support, some of them already implemented:

• [ ] Ethereum Address Generation (EcdsaSecp256k1) --> (linked to #4)
• [ ] IOTA identity generation (Ed25519)
• [ ] DID generation --> without/with DSP-related service endpoints, and with [did:iota:xxxx:] prefix which can be later resolved to our tangle (linked to #7)
• [ ] DID update --> to include/modify DSP in a subsequent stage from initial generation or change whatever is needed (linked to #7)
• [ ] DID resolution --> supporting [did:iota:xxxx] resolution. At least support xxxx=sedimark, but if IOTA-sdk allows us to also support resolution of standard IOTA methods out of the box it would cover a more generic & decentralised scenario. Otherwise we can rely on https://github.com/iotaledger/uni-resolver-driver-iota or something even more generic like https://github.com/decentralized-identity/universal-resolver
• [ ] Signatures generation
• [ ] Signatures verification --> It would be nice to have the option to use as input parameter the DID instead of a public key
• [ ] VC management --> Interaction with the identity SC/issuer directly done through this component, storage of the VC as secret on stronghold
• [ ] VP generation
• [ ] Secret storage
• [ ] Secret retrieval
• [ ] Option to load/save the underlying stronghold vault snapshot into a file for later usage (import/export)