Verifier API should return verified VCs

[msporny]

@David-Chadwick wrote:

Looking at your latest version of the verifier API, I have the following suggestion to make for when the input is a signed VP. The 200 OK code should return the set of validated credentials in standard W3C format, without their proofs.

In the case where the VP for verification is encoded as a JWT, with the encapsulated VCs also being JWT proofed, each JWT VC has removed several fields from the W3C VC and put them as claims in the JWT. Thus it would be good if the verifier API, after validating the JWTs, could put these claims back into the W3C VC, and return this as a standard W3C formatted credential without any proof. This would then mirror what the issuer does, as it is given a standard W3C credential and it turns it into a JWT. In this way, whether the Verifier API verifies a JWT VP, a LD-Proof VP, or an mDL VP, they will all return standard W3C credentials without any proofs and the API caller will have a consistent response regardless of how the VP was formatted

[mavarley]

I agree that having one expected output format from the API would be a very good idea.

Is this ready for PR?

[msporny]

The group discussed this on 2023-01-24. @PatStLouis asked if the array would be the whole credential or just credential subject. Both @msporny and @dlongley thought it was the whole credential. @dlongley noted that stripping the proofs might not be a good idea, there might be other proofs that are not assertion proofs that you'd want to do something with. @jandrieu noted that this might be most valuable for JWTs and it makes sense to hand entire JWT to verifier, if they check/make it works, give JSON back. Idea of stripping off proofs for Data Integrity Proofs, seems odd. Perhaps this can be type-specific. @msporny noted that JWT input/output isn't defined in the OAS files today and that's work that still need to be done. @PatStLouis noted that JWT input/output goes along w/ multi credential support, is a JWT considered a VC or it's own credential? @jandrieu noted that we should support minimum communication possible or we might undermine edge device scenarios where every byte matters. @PatStLouis doesn't really see the point of returning the whole VC, if you sent it as an input, it tells you whether or not its verified, if it returns what you input, what's the point? @msporny noted that there might not be a use case anymore for VC 2.0. @dlongley the v1.1 work doesn't get into how data integrity proofs work and generally speaking, modern data integrity libraries will throw errors when things are dropped. Other point, main use case for this feature is for JWTs, unless verifier returns back decoded data, you can't use it because that's how JWTs work -- they don't have the option of functioning in the way data integrity proof VCs do. @ottonomy noted how open badges validator ended up being built -- as a client, had use cases where output of validator was would be "The trusted version" -- a lot of other work was done in the call/process, returned a lot of other stuff, totally different scope here, but as a client, one way of valuing is "this is the trusted version, canonical form".

The group came to consensus on the following: The Verifier API can return a canonical form after verification, it is an option that is off by default, but can be turned on. The option is valid with all types verifiable credentials that are secured in different ways.

[jrhender]

Discussion about "canonical form" on the 2024-02-20 weekly call (approximately minute 10 of the recording):

• Shouldn't use the term "canonical form" as it may mislead people
• Instead, what this means is return "what has been verified" (i.e. what was signed)

[jrhender]

Although #366 is merged, I believe another PR should be made to add this feature to the Verify Presentation endpoint before closing this issue

[msporny]

PR #380 has been merged, closing.