Currently the code is all a bit intertwined for different formats. This worked okay, but with different formats having different structures, it's become a bit hard to manage. This has mainly come up with adding support for the SD-JWT format, and that uses credential_definition.type , while JWT VC uses types (top level and plural), and JSON-LD uses credentialDefinition.types (camelCase and plural).
Should there have been more consistency between these types? Definitely! but it shows that we shouldn't assume the format specific fields between formats will be similar, and thus to improve maintainability of this library, I think all format specific handling should be separated form the general protocol implementation.
Thus we have the base offer/request etc.. interfaces and handling, and then for each format you need to define the specific offer/request/issuer metadata interfaces, as well as some functions that can e.g. verify a request, or transform an offer of that specific format into a request. This could be an interface that is implemented with some common methods.
This would allow adding new formats without needing to hardcode them in this library, and would make it easier to see what is base OID4VCI code, and what is custom format specific logic
Maybe we can nicely combine this with #75 as there will be a new version which again has different behavior for the credential offers to metadata resolution/mapping
Currently the code is all a bit intertwined for different formats. This worked okay, but with different formats having different structures, it's become a bit hard to manage. This has mainly come up with adding support for the SD-JWT format, and that uses
credential_definition.type
, while JWT VC usestypes
(top level and plural), and JSON-LD usescredentialDefinition.types
(camelCase and plural).Should there have been more consistency between these types? Definitely! but it shows that we shouldn't assume the format specific fields between formats will be similar, and thus to improve maintainability of this library, I think all format specific handling should be separated form the general protocol implementation.
Thus we have the base offer/request etc.. interfaces and handling, and then for each format you need to define the specific offer/request/issuer metadata interfaces, as well as some functions that can e.g. verify a request, or transform an offer of that specific format into a request. This could be an interface that is implemented with some common methods.
This would allow adding new formats without needing to hardcode them in this library, and would make it easier to see what is base OID4VCI code, and what is custom format specific logic
Thoughts on this?