How to test credentialStatus and credentialSchema?

[OR13]

Since the output of the "verify" operation is not defined in the standard, we don't know how to assert that different verifiers should see the same results after verification.

There are a number of related issues, that make solving for this hard in the case of verifiable credentials:

1. How to discover the issuer public key
2. How is verification displayed
3. How is schema validation displayed
4. How is status validation displayed

Here is an example of how one software implementation might have implemented this:

{
  "issuer": {
    "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:ge8geVqM-wtPeVYdzhscvWD7Nqy-vGMaPg-6jaaKXYc",
    "kty": "EC",
    "crv": "P-384",
    "alg": "ES384",
    "x": "Is8rQC5l01x_2cArWEAoH_Hs5aCJkAqs5kDM4VoP2wb_PVirVTKIh-R10BjQ51Al",
    "y": "YqgOmjZ-Y90BKUbwGLsvHmwmEKOHhuhg1aF2fPNzjPRO7YJG-O__BI3G5OpuNo2b"
  },
  "credentialStatus": {
    "valid": true,
    "https://status-list.vc/0#0": {
      "suspension": false,
      "list": {
        "@context": [
          "https://www.w3.org/ns/credentials/v2"
        ],
        "id": "https://status-list.vc/0",
        "type": [
          "VerifiableCredential",
          "StatusList2021Credential"
        ],
        "issuer": "did:web:status-list.vc",
        "validFrom": "2032-07-15T12:00:00.992Z",
        "credentialStatus": [
          {
            "id": "https://status-list.vc/0#0",
            "type": "StatusList2021Entry",
            "statusPurpose": "suspension",
            "statusListIndex": "0",
            "statusListCredential": "https://status-list.vc/0"
          },
          {
            "id": "https://status-list.vc/1#1",
            "type": "StatusList2021Entry",
            "statusPurpose": "revocation",
            "statusListIndex": "1",
            "statusListCredential": "https://status-list.vc/1"
          }
        ],
        "credentialSubject": {
          "id": "https://status-list.vc/0",
          "type": "StatusList2021",
          "statusPurpose": "suspension",
          "encodedList": "H4sIAAAAAAAAA2MAAI3vAtIBAAAA"
        }
      }
    },
    "https://status-list.vc/1#0": {
      "revocation": true,
      "list": {
        "@context": [
          "https://www.w3.org/ns/credentials/v2"
        ],
        "id": "https://status-list.vc/1",
        "type": [
          "VerifiableCredential",
          "StatusList2021Credential"
        ],
        "issuer": "did:web:status-list.vc",
        "validFrom": "2032-07-15T12:00:00.992Z",
        "credentialSubject": {
          "id": "https://status-list.vc/1#list",
          "type": "StatusList2021",
          "statusPurpose": "revocation",
          "encodedList": "H4sIAAAAAAAAAzsAAD0tZkkBAAAA"
        }
      }
    }
  }
}

We could possibly agree that verify operation returns at least a protectedHeader and a payload.

We could possibly agree that a "validate" operation on the payload, should return some representation of "status" and "schema" checks... but if we don't define a way to compare this, we won't be able to demostrate interop.

for inspiration see the SD-JWT test suite configuration:

user_claims:
  data_types:
    - !sd null
    - !sd 42
    - !sd 3.14
    - !sd "foo"
    - !sd True
    - !sd ["Test"]  
    - !sd {"foo": "bar"}

holder_disclosed_claims:
  data_types:
    - True
    - True
    - True
    - True
    - True
    - True
    - True

expect_verified_user_claims:
  data_types:
    - null
    - 42
    - 3.14
    - "foo"
    - True
    - ["Test"]  
    - {"foo": "bar"}

What we need is something like this... but that covers status and schema validation checks.... not just expected claims.

[OR13]

Previous test suite examples here:

• https://github.com/transmute-industries/vc-jwt-test-suite/tree/main
• https://github.com/transmute-industries/status-list.vc

We will need to provide examples of both valid and invalid status an schemas in order to ensure implementations are interoperable.