Issuing credentials with optional values

[TimoGlastra]

In Indy SDK it was allowed to issue a credential based on a credential definition and omitting certain fields from the credential, thus making those values optional.

You could then use attribute markers in a proof request to make sure the value is defined.

This feature seems to have gotten lost in AnonCreds RS and will throw an error "AnoncredsError: Invalid state: Credential attribute 'age' value not provided".

It seems like it's a valid flow to issue a credential with optional fields, and currently you'd have to use an empty string or something to be able to allow for this (but this is of course not very clean).

[TimoGlastra]

Not sure if this got lost in the move from indy-sdk -> indy-credx, or indy-credx -> anoncreds-rs? (@andrewwhitehead @berendsliedrecht)

[andrewwhitehead]

This was updated in anoncreds-clsignatures (hyperledger/anoncreds-clsignatures-rs#21) as credentials with missing attributes were not considered valid when it came to presentations, but they could still be issued (and processed) without an error being raised. When signing the messages there isn't any special handling for omitted messages, and I believe they would effectively be mapped to the zero scalar. Given that an integer zero is mapped to the same value, this seems ripe for abuse.

[berendsliedrecht]

@andrewwhitehead could you elaborate on why this would be abusable? If this would allow for incorrect verification, we definitely should not add this back.

Would the abuse just be that if some wants to check whether your age is non-negative (for some reason...) and the age property was not issued, it will verify anyways?

[swcurran]

This was discussed at the time the “feature” was discovered, and the general agreement was that it was a bad idea. The schema defines the attributes in a credential, and the credential definition used the schema as is. Having the credential definition alter the schema will create confusion and be difficult to manage. If you want to put a different set of attributes in a credential, then create a new schema.

[jorgefl0]

To illustrate a use case, take for instance the W3C Citizenship vocabulary that supports a permanent resident credential with "minimal" set of attributes and a "full" set of attributes such as maritalStatus, marriageCertificateNumber, and marriageLocation. marriageCertificateNumber and marriageLocation would be optional if the person is unmarried.

I realize AnonCreds and W3C VCDM are different animals but it's likely that implementers may have similar predicaments when working with AnonCreds implementations.

Is it still reasonable to expect defining schema variants for this type of scenario?