Mandatory or Optional?

[David-Chadwick]

How does a verifier know if a property that is defined for a type is mandatory or optional?

For example, a verifiable credential contains a proof property and a terms of use property. The former is mandatory and the latter is optional. But how does the verifier know this?

[msporny]

The short answer is, the spec states MUST (mandatory) and SHOULD, MAY (optional).

For specific types of VCs, that is out of scope for the spec and for another spec to define (via a JSON Schema, for example).

One could argue that we should enable VC types to be able to express verification schema that would hang off of the vocabulary document for the type. For example (in triples notation):

<https://example.com/example-vocabulary#ExampleCredential> <vc:validationJsonSchema> <https://example.com/json-schemas/ExampleCredential.json> .

Note that this is hung off of the Vocabulary Document, not the credential itself. Directly embedding the verification schema in the credential results in security attacks.

[David-Chadwick]

@msporny "the spec states MUST (mandatory) and SHOULD, MAY (optional)."

Unfortunately this is not the case. Take for example, IssuanceDate where the definition states "The value of this property MUST be a string value ...." So the spec tells us what the property value MUST contain if it is present, but does not say whether the property must or should or may be present. I think you will find that this is the case for a lot of the properties defined in the data model document.

We could put a blanket statement at the start of the DM doc, saying something like "all properties defined in this specification are optional unless accompanied by a MUST contain statement".

But this does not cover yet to be defined properties and new types of VCs. So I think that some sort of verification schema is needed that applies to all VCs, both now and in the future. (Think: LDAP object classes with mandatory and optional attributes).

Wild Idea. Would it be possible to extend @context, where the shorthand for a property is defined, by adding the keyword @present with a value of MUST to those properties that are mandatory. For example:

credential : 
@id:  "cred:credential"
@type:   "@id"
@present:  "MUST"

[burnburn]

From TPAC 2018:

• [ ] In Implementation Guidance NOTE document that all conformant implementations will check mandatory properties.
• [ ] Add a link to this issue referencing the test spreadsheet once it exists
• [ ] There is a desire for two types of credential, verifiable and unverifiable. The distinction is that one has a proof and the other does not. @nage has the hot potato.

[msporny]

Ping @nage - main spec is blocked going to CR until a PR for the last list item above "There is a desire..." is in.

[David-Chadwick]

I am not quite sure how this addresses the core issue which is How does a verifier know if a property that is defined for a credential type is mandatory or optional? We are usually clear about what a property must contain if it is present in a VC, but we are much less clear about whether the property itself must or may be present in the VC.

[msporny]

@David-Chadwick does PR #280 help matters?

One could say that the creators of a data vocabulary for a certain type of verifiable credential could also include a data verification schema using the feature suggested in #280 and that would make it crystal clear what is mandatory and what is optional. We only have a solution for JSON Schema at present, but the feature above could just as easily support ShEX and SHACL and other graph constraint/shape languages.

[David-Chadwick]

Ok. So we are effectively punting this issue to the definers of the schema. I am happy with that.

[RieksJ]

'Mandatory' and 'Optional' do not cover all cases. Example include properties that can be multi-valued, such as phonenumbers.

This is a question of specifying the multiplicities (i.e. allowed cardinalities) of property-relations, which is the task of the schema publisher. Not all schema's come with multiplicities specified (e.g. schema.org). But there are good examples, e.g. http://www.oioubl.info/Classes/en/Invoice.html shows 0..n multiplicities in several invoice elements.

[msporny]

PR #280 is merged. That combined with the MUST statements in the spec make answering @David-Chadwick's question " How does a verifier know if a property that is defined for a credential type is mandatory or optional?" much easier. Closing this issue as I think we've done all we can in this iteration of the spec (and have put in a mechanism that enables entities to explicitly state a strict data conformance schema).