w3c-ccg / vc-api-test-suite Goto Github PK

The VC HTTP API Test Suite

Home Page: https://w3c-ccg.github.io/vc-api-test-suite/

License: Other

Dockerfile 0.45% JavaScript 99.55%

vc-api-test-suite's Introduction

VC API Test Suite

The VC API test suite repository contains tests for a standard API specification for constructing and verifying objects which conform to the Verifiable Credential Data Model specification, along with documentation, integration and compatability tests, and related assets for the test and integration process.

Structure

The vc-api test suite repository is structured like so:

packages which contains test suites and related utilities for integration testing, test suite results, and related assets.

Data Visualization

You may wish to programmatically download the latest test results as JSON.

Test Results for All Implementations

HTML Report: TODO

curl -s https://w3c-ccg.github.io/vc-api-test-suite/test-suite/testResults.json | jq

Test Results for a Specific Implementation

HTML Report: https://w3c-ccg.github.io/vc-api-test-suite/test-suite/IMPLEMENTATION_NAME

curl -s https://w3c-ccg.github.io/vc-api-test-suite/test-suite/IMPLEMENTATION_NAME/testResults.json | jq

Contributing

We encourage contributions meeting the Contribution Guidelines.
While we prefer the creation of issues and Pull Requests in the GitHub repository, discussions often occur on the public-credentials mailing list as well.

vc-api-test-suite's People

Stargazers

Watchers

Forkers

peacekeeper clehner mavennet dtlab-labcn-admin rolsonquadras dtlab-labcn artursudnik bigbluehat

vc-api-test-suite's Issues

Cannot find Module

Hello, I am having trouble running npm run start-test-server
it fails with Error: Cannot find module '../services/getReportResults'
Can anyone help?
Thanks

Should we link to implementations?

https://github.com/transmute-industries/issuer-verifier-vc-api

Incorrect test description or implementation.

Hi,

While executing the suite on EWF VC-API implementation, I've notice that this test is confusing. While it is described as testing a response for non-exisiting options.verificationMethod property, actually it is defined:

const body = {
              credential: {
                ...credentials[0].data,
                issuer: value.id
              },
              options: {
                ...value.options[0],
                verificationMethod: 'foo',
              },
            };

Inconsistencies with specs

Hi,

While working on the EWF implementation I am facing inconsistencies of this and this tests. According to the W3CCG spec, there are no proofPurpose and verificationMethod options fields but this test suite assumes they are required.

Could you explain if this is on purpose or by mistake, please?

Remove test case Verifier 11

The Verifier's Verify Credential HTTP API MUST adhere to the proof verification format.

This is essentially a dupe fo the first test... it amounts to "does verification succeed".

Remove test case Issuer 3

The Issuer's Issue Credential HTTP API MUST support the issuance of credentials with at least 2 different DID methods as the "issuer" on a Verifiable Credential.

IMO we should remove this, its not helpful, and increases test complexity.

DIDs are a data model, and issuing does not imply anything but data model conformance.

API tests for data property 'type' don't cover both string and array cases

In the VC Spec, the property type can be string OR array. (The spec, interestingly, does not specify if it can be an array with only one member, which is how Spherity has historically done it). We think validation should validate string AND array, including one-member arrays.

case-23 through case-30 no longer verify

The Traceability JSON-LD context changed, and so these VCs now canonicalize differently:

Run periodically

Since Issuer and Verifier endpoints are breaking and getting fixed from time to time, we should run this periodically, e.g. using a Github action like this:

https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#schedule

Suggestion: Run daily

"checks" is not a valid option in /verify endpoints

The test suite currently sends an option named "checks" to the Verifier endpoints, e.g. see here:

https://github.com/w3c-ccg/vc-http-api-test-suite/blob/main/packages/vc-http-api-test-server/__tests__/verifyCredential.spec.js#L19

However, this is not a valid option in the current API:

https://github.com/w3c-ccg/vc-http-api/blob/main/components/VerifyOptions.yml#L15

We discussed this on the 05 Oct 2021 VC API Work Item call and felt that variability of checks is bad, i.e. there should be a fixed set of checks that each conformant implementation of the API performs, and any additional business logic (e.g. evaluating if a VP matches a certain request) should happen outside of the API. There would therefore be no need for a registry of checks, or for options that the client could supply in the request for enabling/disabling certain checks.

Also see w3c-ccg/vc-api#62 and w3c-ccg/vc-api#59.

Based on this, we should create a PR to remove "checks" from the test suite.

VP case 2 (https://github.com/w3c-ccg/vc-http-api-test-suite/blob/61d498c/packages/vc-http-api-test-server/__fixtures__/verifiablePresentations/case-2.json) has the following id:
http://example.gov/credentials/3732#6c02882c-711f-4069-8e5d-13ce9cbedba8#61ab35c4-a652-4868-9460-6f6509d0f61e#c5aa4b4f-877a-41ba-b3 04-e03a572477ce
But a fragment part of a URI/IRI is not supposed to contain a "#" character:

https://www.rfc-editor.org/rfc/rfc3986#page-50:

   fragment      = *( pchar / "/" / "?" )

https://datatracker.ietf.org/doc/html/rfc3987#page-8:

   ifragment      = *( ipchar / "/" / "?" )

Remove test case Verifier 10

The Verifier's Verify Credential HTTP API MUST verify a Verifiable Credential with at least 2 different DID methods set as the issuer property for a credential.

This is redundant, removing would simplify tests.