Disallow credentials with VC/JSON and VC/JWT members that do not encode the same value

[mirceanis]

As discussed in PR#63 there is potential ambiguity during VC/JWT <-> VC/JSON transformation if both entries are present but encode different values.

During VC or VP creation these methods should throw an error in that case and the transformations that are performed for convenience could override the entries that don't correspond to the respective encoding.

It is very inefficient to keep both representations in a credential payload, but that is an ambiguity with the spec we're working on so it must be handled. Let's discuss the best approach before venturing a fix.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[OR13]

We've discussed this issue in the VC WG, and there are currently 2 camps.

I am in the camp of preserving all information, others are in the camp of using "instead of" and potentially loosing some information.

The next VC WG will likely address this with a single spec dedicated to JWT, and I expect one of the camps will loose at that point.

I would advise implementers to not destroy information, the redundancy and interoperability is worth more than the bytes saved.

See also this list: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Av2.0

[mirceanis]

Thank you for the summary. Indeed it's not ok to drop information. Fixing this particular GH issue means throwing an error when information would be overridden or dropped, thus not allowing any ambiguity.

[OR13]

@mirceanis yes, we have a similar issue we are tracking in our implementation.