DID URLs are currently ambigious

[OR13]

I would assume:

1. didDocument.verificationMethod[0].id === didDocument.id
2. didDocument.verificationMethod[0].controller === didDocument.id

But it's not clear from your example.

I need to get back something like did:jwk:encoded....#key-0

I tried to convert did keys to this format... this is what I got:

{
      "keys": [
        {
          "id": "did:key:z6MkpFJxUgQgYKK68fmokaCWwpRYoWdG3LzZR6dLFXvdJvAT#z6MkpFJxUgQgYKK68fmokaCWwpRYoWdG3LzZR6dLFXvdJvAT",
          "controller": "did:key:z6MkpFJxUgQgYKK68fmokaCWwpRYoWdG3LzZR6dLFXvdJvAT",
          "type": "JsonWebKey2020",
          "publicKeyJwk": {
            "kty": "OKP",
            "crv": "Ed25519",
            "x": "kYUxJdxcqoKbfJKjTPEmbifNrDBvuQuoGynhwmr4BSA"
          },
          "privateKeyJwk": {
            "kty": "OKP",
            "crv": "Ed25519",
            "x": "kYUxJdxcqoKbfJKjTPEmbifNrDBvuQuoGynhwmr4BSA",
            "d": "TmG8GRjqakeuMwczG-d5gZahqOfP5Lbo98ml82AX2Sk"
          }
        }
      ],
      "didDocument": {
        "id": "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9",
        "verificationMethod": [
          {
            "id": "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9",
            "type": "JsonWebKey2020",
            "controller": "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9",
            "publicKeyJwk": {
              "kid": "key-0",
              "kty": "OKP",
              "crv": "Ed25519",
              "x": "kYUxJdxcqoKbfJKjTPEmbifNrDBvuQuoGynhwmr4BSA"
            }
          }
        ],
        "authentication": [
          "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9"
        ],
        "capabilityInvocation": [
          "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9"
        ],
        "capabilityDelegation": [
          "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9"
        ],
        "keyAgreement": [
          "did:jwk:eyJraWQiOiJrZXktMCIsImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4Ijoia1lVeEpkeGNxb0tiZkpLalRQRW1iaWZOckRCdnVRdW9HeW5od21yNEJTQSJ9"
        ]
      }
    }

[OR13]

A couple observations...

There is no way to get properties from in the jwk into the did document... this prevents integration with serviceEndpoints which are useful.

This also makes dereferencing ambiguous, since both:

didDocument.id and didDocument.verificationMethod[0].id are identified with the same bytes.

[OR13]

A few more observations...

relationships to https://datatracker.ietf.org/doc/html/rfc7638 should be made explicit.

If you have jwt.header.kid === did:jwk:... you necessarily cannot have jwt.header.kid === did:jwk:...#key-0... because fragments are not resolved from within the encode method specific identifier... unless you make your spec say something about parsing the jwk to read kid.

This is another version of the sub resource identifier encoding problem that was discussed many time during the DID WG.

See also w3c-ccg/did-method-key#24

[OR13]

Also worth pointing out that keyAgreement is not possible with every valid encoding of a JWK.