w3c / vc-jose-cose-test-suite Goto Github PK

Need to process the headers and add some extra details related to the "transformed" payload and selective disclosure tags.

Test cases will cover normative statements, for example:

typ and cty values are easy to test, since they appear in header parameters.

However there are some tricky cases that require full verification... for example:

schema credentials and status credentials.

we'll need negative cases for those, and we might want to encode specific error messages, that some implementers might make use of and others might ignore.

Here are a few examples:

• Failed to verify credential status, could not dereference status list
• Failed to verify credential status, signature verification failed.
• Failed to verify credential status, could not dereference public key.
• Failed to verify credential status, status list no longer valid (expiration in the past)
• Failed to verify credential status, status list not yet valid (activation in the future)

I would like for use to encode some of these errors in test cases, even if a "pass" for the test case is simply raising a generic "error" flag.

Should be straightforward to duplicate this code and update the test cases to work for vc-jose-cose.

There's a need to update the test suite to use Accept headers indicating the type of credential requested from the VC API.

For example, in a case where a JWT is requested there should be a header Accept: vc+ld+jwt, whereas where plain json is desired the header value should be vc+ld+json.

This will at minimum involve:

1. Adding negative unit testing for incorrect/missing Accept headers in requests
2. Updating relevant unit tests to include Accept header in requests

This issue blocks w3c-ccg/traceability-interop#575 and w3c-ccg/traceability-interop#574, as the tests downstream should reflect the tests here.

• Provide example key pairs
• Provide example DIDs
• Provide example VC signed by DIDs
• Provide example VP signed by DIDs

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.

ignoring validFrom and validUntil... what should the expected behavior be for nbf and exp.

Once w3c/vc-json-schema#204 is merged, the value of https://github.com/w3c/vc-jose-cose-test-suite/blob/main/testcases/secured-vc-with-schema-credential/schema.jwt has to be updated so that the payload of said JWT includes the credentialSchema property.

For simplicity, I'm providing the correct payload below:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiableCredential",
    "JsonSchemaCredential"
  ],
  "issuer": "https://vendor.example/issuers/42",
  "credentialSchema": {
    "id": "https://www.w3.org/2022/credentials/v2/json-schema-credential-schema.json",
    "type": "JsonSchema",
    "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
  },
  "credentialSubject": {
    "type": "JsonSchema",
    "jsonSchema": {
      "$id": "https://w3c.github.io/vc-jose-cose-test-suite/testcases/secured-vc-schema-credential/schema.json",
      "title": "Example JSON Schema",
      "description": "This is a test schema",
      "type": "object",
      "properties": {
        "credentialSubject": {
          "type": "object",
          "properties": {
            "id": {
              "type": "string",
              "pattern": "https://(.+)/issuers/(.+)"
            }
          }
        }
      }
    }
  }
}

Need to process the headers and translate them in the case of COSE.

We have this experimental file here:

https://github.com/w3c/vc-jose-cose-test-suite/blob/main/testcases/secured-vc-kitchen-sink-valid/validation.json

As you can see, testing validation of all extensions used can get very complicated.

If you think this file is good enough, please say so, if you have additional things you want to see in the validation files for test cases, please let us know.

I suggest we use both did:jwk and did:web, and commit some example keys and controller documents to source.

I can commit it, if people want to see it... but I am also ok leaving it out of the repo, since nobody should need to see it, in order to implement the test cases.