Testing Interop
mkhraisha opened this issue · comments
We should discuss what our tests should look like for actual interop tests.
My current proposal is we create individual test credential fixtures, that are signed by each implementer, which will then be submitted to each verifier, creating a matrix of Issuer-Verifier results.
Open question:
Currently the spec requires VC-JOSE so should all these fixtures be JWTs?
The fixtures should match the spec so they could be individual JWTs or a single file containing an array of JWTs, whichever is the most convenient to testing.
One thing I would like to see is each implementer submit a non revoked credential and a revoked credential to test BitstringStatusList implementation interop, not just signatures.
My suggestion would be to replicate the Business Card Workflow. This seems like a simple scenario that matches what we want to achieve.
Each implementer can submit a valid business card and a revoked business card.
Also, are implementers submitting credentials or presentations? Technically it should be a presentation to be posted to an oauth protected endpoint.
Great discussions. I just want to capture my train of thoughts around error codes and what we could test.
For the /presentations endpoint:
200 -> The VC is verified, valid, unrevoked
400 -> Bad Request (not a presentation, bad content-type, error with data model, invalid proof)
401 -> Unauthenticated Request
422 -> Unprocessable Content: when the verifier can't process the payload because its expired or its revoked
These 4 response code could cover the need to asses if the implementation is doing sufficient testing and to test some interop for the implementers libraries. If more granularity is beneficial we could define error titles in the specification in addition to status to leverage.
ex: 400: Content Type, 400: Proof, 422: Status, 422: Validity Period
Can we confirm the fixtures will have this format:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"verifiableCredential": [{
"@context": "https://www.w3.org/ns/credentials/v2",
"id": "data:application/vc+ld+json+sd-jwt;QzVjV...RMjU",
"type": "EnvelopedVerifiableCredential"
}]
}
Looking forward furthering this dicussion
Proposal is to create a /verify endpoint that takes the same payload as the /presentations endpoint.
The /verify endpoint will be used to test interop and compliance to the spec.
I agree with the fixtures that Patrick is proposing.
Please react with thumbs up or down to this comment