Test Vectors - Verifiable Credentials

[decentralgabe]

This issue outlines gaps in testing of Verifiable Credentials and associated specs (JSON Schema, Status List, Verifiable Presentations). Tasks may have partial test coverage today (linked if true). If sufficient test coverage already exists, please close the task and link the relevant test.

Tasks may need discussion on the best way to approach them. The goal is to create a set of language agnostic test vectors that give us sufficient confidence in maintaining interoperability of features between implementations.

https://tbd54566975.github.io/web5-spec/#verifiable-credentials-vcs
https://tbd54566975.github.io/web5-spec/#verifiable-credentials-v11-data-model
https://tbd54566975.github.io/web5-spec/#verifiable-presentation-v11-data-model

W3C Verifiable Credentials v1.1

• VCDM v1.1 Verifiable Credentials support the full data model today's tests

  • as outlined here

• VCDM v1.1 Sign and Verify VCs using VC-JWT today's tests

  • Valid issuer (able to resolve DID, retrieve verification method)
  • Invalid issuer (unable to resolve DID, unable to retrieve verification method)
  • Transform to/from VC Data Model and VC-JWT Representation

• VCDM v1.1 Validate Verifiable Credentials today's tests

  • Valid, expired, issued at in future
  • Conforms to Credential Schema(s) if present
  • Available/unresolvable schema/schema available but incorrect
  • Schema validity cases (multiple schemas, one valid, none valid, all valid)
  • Status validity cases (valid status(es) (e.g. not revoked) if present, multiple statuses)
  • Able to resolve status, unable to resolve status

W3C Verifiable Presentations v1.1

• VCDM v1.1 Verifiable Presentations support the full data model

  • as outlined here

• VCDM v1.1 Sign and Verify VPs using VP-JWT

  • Validation of signatures on embedded VCs
  • Valid issuers (able to resolve DID, retrieve verification method)
  • Invalid issuers (unable to resolve DID, unable to retrieve verification method)
  • Is the presenter authorized to present these credentials (i.e. same DID)?
  • Transform to/from VC Data Model and VC-JWT Representation

• VCDM v1.1 Validate Verifiable Presentations

  • Correct audience
  • Valid, expired, issued in future
  • Validation of content in embedded VCs (are they signed? are they verifiable? both VPs and VCs could be contained)
  • Conforms to credential schema(s) if present (available schema, missing schema, incorrect schema)

[nitro-neal]

any thoughts on the practicality for validating the vc schema more robustly?

here is an example we have:

    {
      "description": "bad first context item",
      "input": {
        "credential": {
          "@context": [
            "https://www.w3.org/2018/credentials/examples/v1",
            "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"
          }
        }
      },
      "errors": true
    },

currently we just have "errors:true" so maybe web5-js throws an error for the correct thing (bad first context) BUT maybe web5-rs throws an unknown other issue like issuanceDate parsing or something.

There was an appraoch we were thinking of taking where it was a new element in the vecotr mapping of error messages
web-js: "Context is invalid"
web5-rs : "The first Context is not correct"

So you would know it is failing for the correct reason..

Is this overkill? any other suggestions ?

[decentralgabe]

I like where you're headed...we should catalog the type of errors that could arise and make sure we have test vectors for each of them. Saying "we have an error" is good, but it would be better to produce specific errors given specific faulty inputs.

We can have multiple 'positive' and 'negative' test cases, describing what they're specifically testing.