Test Vectors - Decentralized Identifiers

[decentralgabe]

This issue outlines gaps in testing of various DID methods and DID capabilities. Tasks may have partial test coverage today (linked if true). If sufficient test coverage already exists, please close the task and link the relevant test.

Tasks may need discussion on the best way to approach them. The goal is to create a set of language agnostic test vectors that give us sufficient confidence in maintaining interoperability of features between implementations.

https://tbd54566975.github.io/web5-spec/#decentralized-identifiers-dids https://tbd54566975.github.io/web5-spec/#did-document-data-model https://tbd54566975.github.io/web5-spec/#did-resolution-metadata-data-model https://tbd54566975.github.io/web5-spec/#did-document-metadata-data-model

did:jwk

• [ ] did:jwk create and resolve for all supported key types
  • (secp256k1, ed25519, secp256r1, and x25519) today's tests
  • access verification method (it exists, it does not exist)
• [ ] did:jwk serialize and deserialize to/from JSON DID Documents to JWKs

did:web

• [ ] did:web create with all features
  • multiple verification methods, verification relationships, services, different key types
• [ ] did:web update
  • multiple verification methods, verification relationships, services, different key types
• [ ] did:web resolve via a direct network request today's tests
  • valid resolution
  • invalid resolution (does not exist, bad certificate)
  • access verification methods (it exists, it does not exist)
  • [ ] did:web serialize and deserialize to/from JSON DID Documents to JWKs

did:dht

Can be based off of the spec test vectors.

• [ ] did:dht create and publish today's tests
  • with multiple options: verification methods, relationships, services, types, gateways, etc.
• [ ] did:dht update any/all properties
• [ ] did:dht resolve today's tests
  • local resolution as a fallback
  • resolve via a DHT node/gateway
  • access verification methods (it exists, it does not exist)

DID Data Models

• [ ] Support DID resolution with DID resolution metadata and DID document metadata

[nitro-neal]

these look good to me currently for did jwk we only have resolve test for secp256k1 and Ed25519 so not enough for a full checkmark ❌ Its a bit of chicken and egg, because I would like to make these tests with the rust cli.. but we need to build these key types and add them to cli.

I think they are getting added now basically so this would be a good vector to improve upon and get a ✅ for, but lol as soon as I add the other key tyeps it will break all other repos for this vector (as expected, but painful)

[nitro-neal]

As another thing I was talking to @KendallWeihe about, and curious to your take @decentralgabe , for something like did:dht publish, would you expect sdks do it 'for real' and do an http request, or you expect they will have to implement some mocking stuff.

Or could each sdk decide on their own? maybe js does mocking but rust just 'does it for real over the network' but knowing there could be intermittent failures

[decentralgabe]

mocking would probably be sufficient, as long as the test vector is able to show conformance with the DHT API