fix `did:dht` verification method ID handling

[mistermoe]

Summary

Included a short-term fix for adid:dht issue rasied here: https://github.com/TBD54566975/tbdex-go/pull/20#discussion_r1566623560

Details

Fixed value resolution such that vm.IDs are always absolute. main wasn't accounting for the fact that id in a verification method TXT record is only the fragment (excluding '#') which was causing resolved did docs to look like this:

{
  "id": "did:dht:9kkuh34q7nkd4tphbcg7py9h1g16iftbtskesi9courdwj96q3sy",
  "verificationMethod": [
    {
      "id": "0",
      "type": "JsonWebKey",
      "controller": "",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "-pU-Z07olD1FvAsN1oP8kaXqliGNlItX7ITIOif-dmw"
      }
    }
  ],
  "assertionMethod": [
    "0"
  ],
  "authentication": [
    "0"
  ],
  "capabilityDelegation": [
    "0"
  ],
  "capabilityInvocation": [
    "0"
  ]
}

[!WARNING] This PR doesn't accommodate for the fact that id can be omitted entirely and if so, should be set to the jwk thumbprint of the respective PublicKeyJwk. This will be addressed in a subsequent PR that does a broader refactor of did:dht

vm.Controller was not being set unless it was explicitly set in a verification method's TXT record. Per the spec, This PR sets vm.Controller to document.ID if it isn't explicitly set in the txt record

[KendallWeihe]

This PR doesn't accommodate for the fact that id can be omitted entirely and if so, should be set to the jwk thumbprint of the respective PublicKeyJwk.

@mistermoe is using the thumbprint in some standard somewhere? I know we're doing that in various places, but it has implications when integrating with key manager services, which can maintain their own reference of a key alias.

[mistermoe]

@KendallWeihe , from the did:dht spec here

unrelated, re:

but it has implications when integrating with key manager services, which can maintain their own reference of a key alias.

can you provide a concrete example of what you mean when you say this?

[KendallWeihe]

can you provide a concrete example of what you mean when you say this?

Looks like most key manager services support defining a custom key alias, so no I don't have a concrete example. But even so, it's additional abstraction because the key id defined by the given key manager/store/enclave is the ultimate source of truth.