Question about IssueCredentialOptions and VerifyOptions

[tsnyder-gs1us]

We are working on a VC-API implementation and have some questions on the different parameters for the IssueCredentialOptions.yml and VerifyOptions. So far the test suite is passing and does not seem to require the options parameters to be used. Does anyone have any guidance on how the options parameters should be used. It is not clear from the descriptions of the properties in the yaml files.

For example what is the purpose of the challenge and domain issuing options? We are familiar with using a challenges with a credential presentation but not sure how that would be used with a single credential. Not sure what the issuer would use the domain property for or how it would be included in the credential.

Same questions for the Verify Options

[msporny]

The group discussed this on the 2023-06-13 telecon.

For IssueCredentialOptions, ALL of the options, which are created, domain, challenge, and credentialStatus, are deprecated and are slated for removal. This will leave options object empty and it will be up to implementations to include implementation-specific options if they desire to do so.

For VerifyOptions, the domain, and challenge options still are used to check the domain and challenge that the verifier is expecting. The proofPurpose should be added to the options. The verificationMethod and created properties, shown in the examaple, should be removed.

The group discussed setting the created date for IssueCredentialOptions and its usefulness. The group discussed whether changing created date was useful. @msporny noted that it might be useful, but that's theoretical. @brianorwhatever, @jandrieu, and @PatStLouis noted that you probably just want the digital proof date to be the time it's issued. It was decided that removing the created from issuance options was the best path forward (as it could be added later if a use case surfaced).

This issue is ready for a PR that makes the changes listed above.

[msporny]

The group discussed this on the 2024-03-05 call and added the following changes to the decisions above:

We should have IssueCredentialOptions, DeriveCredentialOptions, CreatePresentationOptions, VerifyCredentialOptions, and VerifyPresentationOptions.

We also added mandatoryPointers to IssueCredentialOptions and selectivePointers was added to the DeriveCredentialOptions.

Add this text: When an instance prohibits the use of a particular option, it SHOULD return a 4xx error if that option is present in a request.

[mkhraisha]

I believe #375 tackles this issue and it is ready to be closed?