Further adaptations on MIW for VC Issuance 2.0/IATP

[OSchlienz]

Description The objective of this ticket is to collect the necessary remaining changes and tests to adapt the Managed Identity Wallet (MIW) to the new Issuer Component and the VC issuance flow 2.0 incl. revocation as well as to the Verifiable Presentation Flow of the Identity and Trust Protocol (IATP).

This includes following adaptations/integrations:

Interface to Issuer Component (integration support from issuance component)

• Create Wallet Tenant (incl. cofigurable DID/DID-document storage under portal-url)
• Sign VC from issuer component by issuer wallet
• Store a signed VC in holder wallet (by issuer)
• Revoke an issued VC

Interface to EDC/IATP: (integration support from EDC-IATP/MXD)

• Integration & testing of presentation flow with EDC/MXD-team
• SI-token1 request from data consumer
• SI-token 2 request from data provider
• VP request for allowed scopes with SI-token2
• SI-token interoperability between wallets

Adapt MIW to issue VCs as JWT MIW needs to be adapted to required encoding format for VCs and Verifiable Presentations (VP) is JWT ES256K/secp256k1

Implement Revocation Service For the Issuer component, the MIW is required to support the capability for revocation of previosly issued credentials (issuer, holder request, by automation/expiry), and therefore:

• implement revocation service based on Bitstring Status List, as required by IATP https://github.com/eclipse-tractusx/identity-trust/blob/main/specifications/credential.issuance.protocol.md#8-vc-revocation)
• provide revocation process incl. update of status list VC with entry for revocable credential and revocation list entry into revocable VC

Interface for Key Operations Provide interfaces for key storage and signing to be more flexible regarding secure key storage options

Extend/refactor MIW Tests Refactor tests and increase the amount of unit tests

Cleanup work & documentation

• remove unsued endpoints and summary credential logic
• update documentation

Concept for a Multi-Module MIW Develop an approach to separate MIW-services: Issuer Wallet, Holder Wallets, DID Document Hosting, Verifcation, Revocation, etc.

[jjeroch]

@OSchlienz the multi wallet concept is a standalone issue #562 I suggest to delete the following section from this feature ticket to reduce duplication Concept for a Multi-Module MIW Develop an approach to separate MIW-services: Issuer Wallet, Holder Wallets, DID Document Hosting, Verifcation, Revocation, etc.

[stephanbcbauer]

Was presented in the open planning ⇾ dependencies are identified. Developer and Committer are involved.

Additional Information ⇾ a lot to do, this feature will change “the whole product” ⇾ question who will test this big change? Testplan is important ⇾ especially for this feature (E2E)

[stephanbcbauer]

Hello @OSchlienz

Since the feature is a 24.08 feature and the development phase is coming to an end, we need a status on the feature.

• [ ] Currently you are assigned (Responsible) → Is this correct? If not, please assign the correct contact person
• [ ] Please check whether the status (backlog, work in progress ...) is set correctly
• [ ] Please check whether there is an assignment to a committee or expert group (supported-by) to be found on the board
• [ ] Please comment on the current status of the feature
• [ ] Are all SubTasks (issues from other repositories that deal with the feature) linked? → The easiest way is to mention the feature here in the issue (via the ID) so we can see which teams/repositories are involved.

If you need any clarification, please get in touch, thank you very much. Stephan