did-jwt-vc icon indicating copy to clipboard operation
did-jwt-vc copied to clipboard

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

Open mirceanis opened this issue 4 years ago • 4 comments

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.

mirceanis avatar Mar 01 '21 11:03 mirceanis

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.

stale[bot] avatar Aug 30 '21 14:08 stale[bot]

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

OR13 avatar Jan 13 '22 17:01 OR13

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.

mirceanis avatar Jan 13 '22 18:01 mirceanis

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

OR13 avatar Jan 13 '22 19:01 OR13