Fix loosing properties when generating verifiable credentials

[icetrust0212]

No description provided.

[aurelticot]

This doesn't fix the issue for two reasons:

• createVerifiableCredential is not the only entrypoint.
• The default options should be set according to the behaviour we want (keep the properties)

[icetrust0212]

This doesn't fix the issue for two reasons:

• createVerifiableCredential is not the only entrypoint.
• The default options should be set according to the behaviour we want (keep the properties)

Even createVerifiableCredential is not the only entrypoint, I don't think it's harmful for now.
I don't have enough context for other projects, but this will be fixing current proof-connector issue and not harmful at least.

Also default options is the same as did-jwt-vc. it's empty object in default. {}
I think we need to set it with empty object ({}) so that it won't affect to other project.

[aurelticot]

Even createVerifiableCredential is not the only entrypoint, I don't think it's harmful for now. I don't have enough context for other projects, but this will be fixing current proof-connector issue and not harmful at least.

I didn't say it was harmful, I said it's not the only entrypoint, implying the same logic should be applied to the other ones. The proof-connector is supposed to use createVerifiableCredentialRecord which this PR doesn't cover.

Also default options is the same as did-jwt-vc. it's empty object in default. {} I think we need to set it with empty object ({}) so that it won't affect to other project.

It's been flagged as a bug to loose the properties, passing an empty object doesn't fix the bug. Whatever did-jwt-vc uses as default options, if we think these properties should not be lost we should set the options accordingly.

[icetrust0212]

Even createVerifiableCredential is not the only entrypoint, I don't think it's harmful for now. I don't have enough context for other projects, but this will be fixing current proof-connector issue and not harmful at least.

I didn't say it was harmful, I said it's not the only entrypoint, implying the same logic should be applied to the other ones. The proof-connector is supposed to use createVerifiableCredentialRecord which this PR doesn't cover.

Also default options is the same as did-jwt-vc. it's empty object in default. {} I think we need to set it with empty object ({}) so that it won't affect to other project.

It's been flagged as a bug to loose the properties, passing an empty object doesn't fix the bug. Whatever did-jwt-vc uses as default options, if we think these properties should not be lost we should set the options accordingly.

Yeah, I understand. If it's not the only entrypoint. I will go through other endpoints.

Sure, we won't pass empty options. Empty is just default value if we don't pass the option.
We will pass necessary options when we call function (createVerifiableCredential) in verida-js.
The issue was that there was no way to pass this option when we use verida-js functions. Now we can pass options when we call createVerifiableCredential function.