"bad @context cardinality" test

[kdimak]

Could you please explain the meaning of @context bad cardinality check from basic group? I just cannot understand what's wrong with this definition of VC (from example-1-bad-cardinality.jsonld):

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "proof": {
    "type": "RsaSignature2018"
  }
}

[TallTed]

I believe that @context should not be an array since it has a single member. In other words, this --

  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],

-- should be --

  "@context": "https://www.w3.org/2018/credentials/v1",

[dlongley]

That example should include a second context that defines the terms used in the VC (such as AlumniCredential) that are not present in the base context.

[llorllale]

@dlongley how can an implementation reasonably deduce the correct context in this scenario?

[dlongley]

@llorllale,

How can an implementation reasonably deduce the correct context in this scenario?

Real world implementations will do more than just check the data model (they will verify proofs, etc.). They may, for example, either use JSON-LD to detect that that certain terms are undefined or have an API that allows callers to specify known/expected contexts and types. So, such an implementation would not be guessing, but would rather be relying on JSON-LD processing or parameters that are explicitly passed via the API.

As for checking against the data model only, we could probably make this test more lenient. I think as long as the first context is appropriate, the test could pass. I think a long term goal of the test suite is to cover both data model tests and, optionally, more -- but this will be up to the CCG to take on. This could result in making this test more lenient in the "data model section" of the test suite but adding more restrictive tests in an optional section elsewhere.

[llorllale]

@dlongley can you please clarify on this:

I think as long as the first context is appropriate, the test could pass.

Do you mean the test should just ensure that when @context is an array:

a. the order of @context is preserved b. the first element of @context is "https://www.w3.org/2018/credentials/v1" c. type should also be an array, and d. the first element of type should be "VerifiableCredential"

?

[dlongley]

For a VerifiableCredential:

1. If @context is an array, the first element must be https://www.w3.org/2018/credentials/v1 and order is preserved. If @context is a string, it must be https://www.w3.org/2018/credentials/v1.
2. If type is an array, VerifiableCredential must be present and should be the first element, but the array is considered an unordered set. If type is a string, it must be VerifiableCredential.

[peacekeeper]

I think this can be closed?