Derive Eq and PartialEq on the various types in vc.rs?

[vdods]

I'd like to generally improve the usability of the the types in the ssi::vc module from a developer standpoint. In particular, it would be very useful to have derived PartialEq (and Eq if possible) for all the various types, so e.g. ssi::vc::Credential or ssi::vc::CredentialSubject could be directly compared for equality. Would you be open to a PR affecting this change? I'm just wondering if not deriving at least PartialEq was an explicit choice or not.

[clehner]

Derived PartialEq/Eq would not necessarily make sense for these objects when the credential is using JSON-LD, i.e. with RDF-based proof types. For Credential it might be okay, but for CredentialSubject, the @context of the parent (credential) object should be taken into account when comparing these. I can elaborate on this if you need.
If PartialEq was implemented for Credential to be equivalent to if it was derived implementation with all contained objects using a derived PartialEq, that would correctly match equivalent credentials in the narrow case where the JSON structure is the same (which is not necessarily required for all proof types). But a derived PartialEq implementation for CredentialSubject, Issuer, etc. could be problematic because they lack reference to the credential's context.

Can you say more about how/where/why you want to do equality comparisons?

[vdods]

Interesting. JSON-LD strikes again :-D

I'm interested in this generally for verifying in test code that credentials survive a round-trip through encode (sign) and decode+verify. The reason this isn't trivial is probably also because of JSON-LD and the context/schema stuff. I noticed that unless I truly correctly formatted the VC, some fields in the subject weren't making it through a round trip.

For now I've come up with a decent workaround for the specific credential schemas I'm working with (basically I convert from and to a struct which represents my specific credential schema, and check that for equality). So if adding PartialEq to the credential types is problematic, then no worries.

I am curious though about how you and others go about debugging problems with contexts and schemas. For example, I've defined my own simple VC context which simply specifies an email address for a given subject, but it fails with "key expansion failed" when I try to create an LDP format proof (and it doesn't fail for JWT format).

[clehner]

When I get key expansion failed, I try to narrow down where the key is that is failing to expand, by removing parts of the credential until the error goes away, then adding back parts until the error occurs.

[dredozubov]

@vdods It's possible to add newtypes to use specifically in the test suite to test encode-decode and decode-encode properties. This way these types won't propagate icky implementations through the codebase, but can be used to test properties like this.