We have a Managed Identity Wallet (MIW) application and this application is used to issue various types of verifiable credentials using did:web method.
In the current application, there is no credential revocation implemented. Credential revocation will be needed in the following cases:
When any business partner deboarded from Opco.
When there are any changes in credentials or updates needed in credentials. In this case, we need to revoke the older VC and need to reissue it.
The core functionalities are:
Issue status list credentials to all wallets (Issuer)
Maintain status list index for revocation
Verify revocation status of credential
Cross-cutting Concepts
Please refer to this for more information: Bitstring Status List v1.0
Business Solution Target Group
Managed Identity wallet and Portal application
Challenges
Opco cannot revoke issued VC in case of deboard of a business partner.
Opco cannot revoke VC in case of any changes in VC and needs to issue a new VC.
Currently, we are deleting VC directly from the database in case of offboarding of business partners. Deleting is not a proper solution as if any wallet has older VC (Stored somewhere locally) then they can validate this VC.
Furthermore, since deleting could not be an option for bring your own wallet concept, lack of revocation is a blocker for realizing the concept.
Benefit Hypothesis & Problem Statement
The benefits of this application are:
This Catena-X can issue revocable CX type of VC to business partner.
Revocation status can be checked while verifying the VC.
In case of updated VC, we can revoke older VC and reissue it with updated data.
Requirements Overview
After insemination of this service, the below requirements should be achieved:
Opco can issue revocable VC to business partner.
Opco can revoke the issued VC to a business partner.
Business partner issues revocable VC to self.
One can verify whether VC is revoked or not during verification of VC.
Quality Goals
Status list VC should be stored in durable storage and backup should be taken.
The current index should be created for each issued revocable VC.
While revocation, the correct index should be revoked.
The application should work in case of horizontal scanning.
Only authorized user/client can access the revocation API.
One status list index should be created for one VC.
ma3u
commented
9 months ago
Introduction and Goals
Initial Situation from Business View
We have a Managed Identity Wallet (MIW) application and this application is used to issue various types of verifiable credentials using
did:webmethod.In the current application, there is no credential revocation implemented. Credential revocation will be needed in the following cases:
The core functionalities are:
Cross-cutting Concepts
Please refer to this for more information: Bitstring Status List v1.0
Business Solution Target Group
Challenges
Opco cannot revoke issued VC in case of deboard of a business partner.
Opco cannot revoke VC in case of any changes in VC and needs to issue a new VC.
Currently, we are deleting VC directly from the database in case of offboarding of business partners. Deleting is not a proper solution as if any wallet has older VC (Stored somewhere locally) then they can validate this VC.
Furthermore, since deleting could not be an option for bring your own wallet concept, lack of revocation is a blocker for realizing the concept.
Benefit Hypothesis & Problem Statement
The benefits of this application are:
Requirements Overview
After insemination of this service, the below requirements should be achieved:
Quality Goals