"bad type cardinality" test

[kdimak]

Could you please explain the meaning of type bad cardinality check from basic group? It's defined at example-3-bad-cardinality.jsonld as following:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": "VerifiableCredential",
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science in Mechanical Engineering"
    }
  },
  "proof": {
    "type": "RsaSignature2018"
  }
}

From the other hand, the same type definition can be found in several other test cases, e.g. in example-016-jwt.jsonld which should be processed with no error.

[llorllale]

The cardinality of type should reflect (not necessarily equal!) that of @context:

Since this document includes an additional context ("...examples/v1"), and since VerifiableCredential is already defined in the standard context for VCs, then it is expected that type be an array and have one more element for a type defined in "...examples/v1".

That said, I'm not sure this test case is set up properly for implementers. How can an implementation reasonably guess the correct type based on the given context and the claims in the VC?

[dlongley]

How can an implementation reasonably guess the correct type based on the given context and the claims in the VC?

See: #96 (comment)

[peacekeeper]

I agree with @clehner on this. The VC in https://github.com/w3c/vc-test-suite/blob/gh-pages/test/vc-data-model-1.0/input/example-3-bad-cardinality.jsonld is valid per the data model and therefore it should not be used for a "negative" test in https://github.com/w3c/vc-test-suite/blob/gh-pages/test/vc-data-model-1.0/10-basic.js#L89.