decentralgabe
commented
10 months ago Suggested order of ops:
- Use test vectors from the spec themselves (if they don't exist, open up issues)
- Search for existing open source impls, and ensure compatibility with them (e.g. did:jwk test vectors from Orie's impl)
- Create our own test vectors from a source of truth lib
I think it's good to have a source of truth lib no matter what. Depending on how the Rust work shakes out this seems like a natural candidate.
We need to ensure that our SDKs are interoperable with one another. We can achieve this by producing language agnostic test vectors for every feature. These test vectors can then be consumed by each SDK to ensure that the feature has been implemented correctly.
We should take a look at the intended approach that has been underway in this repo.
Two other approaches that had been suggested in the past were:
produce test vectors for a given feature and toss them into this repo to be consumed by each individual SDK. This may work especially in situations where test vectors already exist for a given feature. In those cases we may want to consume them from the source of truth or somehow mirror them in this repo
this approach may run into snags when no vectors exist and they cannot be produced by hand. it leaves us in a situation where 1 SDK effectively acts as the "source of truth" for a given feature and takes on the responsibility of producing those vectors
for any given feature, we would decide up front on the shape of each test vector and what each includes.then, every sdk would generate their own vectors published to a deterministic github pages path per repo e.g.
https://tbd54566975.github.io/web5-kt/test-vectors/did-jwk.jsonhttps://tbd54566975.github.io/web5-js/test-vectors/did-jwk.jsonhttps://tbd54566975.github.io/web5-rs/test-vectors/did-jwk.jsonThese vectors could then be consumed by other sdks to ensure interop.
I imagine we may end up landing on a mixture of the two in addition to the efforts already set forth by @finn-tbd