Open OSchlienz opened 2 months ago
Hi everyone,
I'm pleased with our progress in converting applications into multi-modules. To further improve adaptability, I suggest decoupling more modules, particularly focusing on key storage and signing mechanisms. This could greatly extend our flexibility for future enhancements.
Considering our current scenarios and what we already know, I propose the creation of a high-level module focused specifically on key storage and signing mechanisms as below:
wallet-api
. : Contains constants like DTOs, POJO, Exception, and validation class
wallet-dao
: Contains data access layer
wallet-key-storage-api
: interfaces to store and get keys
wallet-key-storage-impl-db
: Currently we only support databases so we will have only impl for databases. In future may maybe we have wallet-key-storage-vault-impl
wallet-signer-api
: interface to sign VC and VP
wallet-signer-impl-local
: Sign VC/VP in local. in future, we have wallet-signer-impl-azure
wallet-core
: Code services for business logic
waller-service-web
: expose rest APIs to sign and verification
revocation-service-client
: Contains feign client to access revocation APIs(ie. to get status list and revoke index)
revocation-service-dao
: Data access layer
revocation-service-core
: Core services business logic
revocation-service-web
: APIs for revocation
I understand this is a very big change and requires lots of work.
Please share your thoughts.
Ref: https://github.com/eclipse-tractusx/managed-identity-wallet/pull/285 https://github.com/eclipse-tractusx/managed-identity-wallet/discussions/254 CC: @PManaras @mustafasalfiti @hkny @borisrizov-zf
Motivation
We're introducing sub-modules to the MIW to enable features such as a revocation service, which will be a separately runnable service.
Description
To achieve this the
gradle
build and settings files must be edited. The revocation service should reside inside a directory calledrevocation-service
. Any changes required to the build system to enable this service should be added tot the sub-module build file. The root level build file can mostly be re-used.The release GitHub action and accompanying actions should also be prepared for the upcoming feature.
A section in the root-level README.md should be added, describing this architectural change.
The arc42 docs in the
docs/
sub-directory should also be updated to reflect the incoming change.Any other tasks which result from this work, can be added here via a comment.