Remove VC validation if rawVC is present

[anant-srirangam]

Background
Currently when uploading a new VC we add rawVC in the verifiableCredentialContainer and then almost the same things (in general basic use case) as we have in the rawVC to the verifiableCredentialContainer. Unless we do so the validation for upload fails. For instance : if I remove issuer from the container then upload would fail even if its there in the JWT raw VC.

On the other hand when the connector calls IH for signed JWTs before sending out for lets say catalog request, it uses only the rawVc information in the participating agent context (verified this using debugger and matched the contents of rawVC vs the overall verifiableCredentialContainer).

So the idea for improvement here is that : why not decode the raw Vc and validate that during credential upload or storage instead of validating presence of issuer, credentialSubject and other fields in verifiableCredentialContainer ??

[paullatzelsperger]

we can't do that because:

• we need the rawVC, because only it represents the signed credential. it cannot be changed. Typically, the holder is not the signer.
• we need the structured information for querying and indexing. On-the-fly decoding of the rawVC and executing a query on it would either have to be implemented in the database, or we'd have to materialize the entire stream in memory. Both options are not viable.

In addition, uploading credentials through the VerifiableCredentials API is not the standard use case: Credentials should be ingested through the Issuance flow of DCP. Your standard workflow should not be based on uploading credentials this way.

I'm afraid you will have to go through the trouble of providing valid data on API ingress.

[anant-srirangam]

why not decode and store as API logic instead of depending on participant's manual upload action? You dont have verifier the signature but simple payload extraction of JWT and then add it to the data objet before storing and indexing. This could also reduce your failure points and make debugging easy in case something goes wrong with credentials.

[paullatzelsperger]

I get what you mean, but there are two main reasons why I would still not want to do that:

1. we would effectively have to "guess" the credential format: while this may be obvious to the human, and would be easy for JWT vs JSON-LD, it becomes a bit more obscure when formats like SD-JWT are used. Deciding between VC DataFormats would be another "guess" we'd have to make. Probably possible, but brittle.
2. Making those fields explicit, and having the client filling them out correctly forces a conscientious action and acts as safety guard - it becomes much less likely to upload the wrong credential by erroneously posting the wrong JWT string.