Update the transfer process

Oct 13, 2025 by wbrum.org 88 views

Feature Request

Currently, we store the VC dataModel in the CredentialDefinition. However, this is not enough to derive the profiles to be used for a certain credential. In order to support IssuerMetadata with, we should store instead the VC formats supported, which then through a registry #676 can be translated into a list of supported profiles.

Why Is the Feature Desired?

The feature is desired because the current implementation of storing the VC dataModel in the CredentialDefinition is not sufficient to meet the requirements of deriving the profiles to be used for a certain credential. By storing the VC formats supported, we can leverage the registry #676 to translate them into a list of supported profiles, which is a more efficient and effective approach.

Which Areas Would Be Affected?

The following areas would be affected by this feature:

DPF (Decentralized Presentation Framework): The DPF would need to be updated to support the new approach of storing VC formats supported instead of the VC dataModel.
CI (Continuous Integration): The CI pipeline would need to be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Build: The build process would need to be updated to accommodate the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Transfer: The transfer process would need to be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.

Who Will Sponsor This Feature?

The feature will be sponsored by @johnDoe, who will ensure that the necessary changes are made to the codebase and that the feature is properly tested and validated.

Solution Proposal

The solution proposal is to remove the dataModel from the CredentialDefinition and instead store the VC formats supported. This will allow us to leverage the registry #676 to translate the VC formats supported into a list of supported profiles. The following steps will be taken to implement this solution:

Update the CredentialDefinition: The CredentialDefinition will be updated to store the VC formats supported instead of the VC dataModel.
Update the DPF: The DPF will be updated to support the new approach of storing VC formats supported.
Update the CI pipeline: The CI pipeline will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Update the build process: The build process will be updated to accommodate the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Update the transfer process: The transfer process will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.

Technical Details

The technical details of the solution proposal are as follows:

DataModel removal: The dataModel will be removed from the CredentialDefinition and replaced with the VC formats supported.
Registry integration: The registry #676 will be integrated to translate the VC formats supported into a list of supported profiles.
DPF updates: The DPF will be updated to support the new approach of storing VC formats supported.
CI pipeline updates: The CI pipeline will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Build process updates: The build process will be updated to accommodate the changes in the CredentialDefinition and the new approach of storing VC formats supported.
Transfer process updates: The transfer process will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported.

Benefits

The benefits of this feature are as follows:

Improved efficiency: The new approach of storing VC formats supported will improve the efficiency of the system by reducing the number of steps required to derive the profiles to be used for a certain credential.
Increased effectiveness: The new approach will increase the effectiveness of the system by providing a more accurate and reliable way of deriving the profiles to be used for a certain credential.
Enhanced user experience: The new approach will enhance the user experience by providing a more streamlined and user-friendly way of deriving the profiles to be used for a certain credential.

Drawbacks

The drawbacks of this feature are as follows:

Complexity: The new approach will introduce additional complexity to the system, which may require additional resources and expertise to implement and maintain.
Regulatory compliance: The new approach may require additional regulatory compliance, which may add additional costs and complexity to the system.
Interoperability: The new approach may require additional interoperability efforts to ensure that the system can work seamlessly with other systems and stakeholders.

Conclusion

Frequently Asked Questions

We've received several questions about the feature of removing the dataModel from the CredentialDefinition and storing the VC formats supported instead. Below are some of the most frequently asked questions and their answers.

Q: What is the current implementation of storing the VC dataModel in the `CredentialDefinition`?

A: The current implementation stores the VC dataModel in the CredentialDefinition, which is not sufficient to derive the profiles to be used for a certain credential.

Q: Why is the current implementation not sufficient?

A: The current implementation is not sufficient because it does not provide enough information to derive the profiles to be used for a certain credential. By storing the VC formats supported, we can leverage the registry #676 to translate them into a list of supported profiles.

Q: What are the benefits of storing the VC formats supported instead of the VC dataModel?

A: The benefits of storing the VC formats supported instead of the VC dataModel are improved efficiency, increased effectiveness, and enhanced user experience.

Q: What are the drawbacks of storing the VC formats supported instead of the VC dataModel?

A: The drawbacks of storing the VC formats supported instead of the VC dataModel are complexity, regulatory compliance, and interoperability.

Q: How will the DPF be updated to support the new approach of storing VC formats supported?

A: The DPF will be updated to support the new approach of storing VC formats supported by modifying the code to handle the new data structure.

Q: How will the CI pipeline be updated to reflect the changes in the `CredentialDefinition` and the new approach of storing VC formats supported?

A: The CI pipeline will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported by modifying the build scripts and configuration files.

Q: How will the build process be updated to accommodate the changes in the `CredentialDefinition` and the new approach of storing VC formats supported?

A: The build process will be updated to accommodate the changes in the CredentialDefinition and the new approach of storing VC formats supported by modifying the build scripts and configuration files.

Q: How will the transfer process be updated to reflect the changes in the `CredentialDefinition` and the new approach of storing VC formats supported?

A: The transfer process will be updated to reflect the changes in the CredentialDefinition and the new approach of storing VC formats supported by modifying the transfer scripts and configuration files.

Q: Who will be responsible for implementing and maintaining the new approach of storing VC formats supported?

A: The development team will be responsible for implementing and maintaining the new approach of storing VC formats supported.

Q: What is the timeline for implementing and deploying the new approach of storing VC formats supported?

A: The timeline for implementing and deploying the new approach of storing VC formats supported is currently being planned and will be communicated to the team and stakeholders in due course.

Additional Resources

For more information on the feature of removing the dataModel from the CredentialDefinition and storing the VC formats supported instead, please refer to the following resources:

Documentation: The documentation for the feature can be found in the project's documentation repository.
Code: The code for the feature can be found in the project's code repository.
Meetings: The meeting notes and minutes for the feature can be found in the project's meeting notes repository.

Conclusion

In conclusion, the feature of removing the dataModel from the CredentialDefinition and storing the VC formats supported instead is a necessary step to improve the efficiency and effectiveness of the system. We hope that this Q&A article has provided you with a better understanding of the feature and its implementation. If you have any further questions or concerns, please do not hesitate to reach out to the development team.