feat: resolve did:key jwk_jcs-pub (multicodec 0xeb51) P-256 keys

[digitalidentitywallet-team]

Resolve did:key jwk_jcs-pub (multicodec 0xeb51) P-256 keys

Summary

Adds support for resolving did:key identifiers that encode a P-256 public
key as a JCS-normalized JWK (multicodec 0xeb51, jwk_jcs-pub). These keys are
how EUDI Wallet / OpenID4VC issuers commonly represent their signing keys, and
OpenCred currently fails to resolve them, so credentials issued by such wallets
cannot be verified.

Motivation

OpenCred's did:key driver is registered only for the p256-pub multicodec
(zDna… multibase prefix). EUDI Wallet / OpenID4VC issuers instead publish
their P-256 keys using the jwk_jcs-pub multicodec (0xeb51), whose base58btc
multibase prefix is not fixed — it shifts with the encoded JWK length
(z2dm…, z8DK…, zYqN…, …). As a result:

• The keys are unresolvable today, and any VC whose iss is such a did:key
  fails signature verification with a resolver error.
• Routing by the multibase string prefix is unreliable, because the same
  logical key can surface under several different prefixes.

Approach

Route did:key resolution by the decoded multicodec rather than the
multibase string prefix:

1. Decode the multibase (base58btc) payload and read its leading multicodec
   varint (LEB128).
2. If the multicodec is 0xeb51 (jwk_jcs-pub), parse the embedded JWK; if it
   is an EC / P-256 key, normalize the x/y coordinates to exactly 32
   bytes (per RFC 7518 §6.2.1.2 — some issuers serialize a coordinate with a
   leading sign byte, yielding 33 bytes) and re-derive the canonical p256-pub
   (zDna…) did:key via EcdsaMultikey.fromJwk.
3. Delegate to the existing driver with that canonical identifier.

Any other multicodec (including today's zDna… keys) falls through to the
existing driver completely unchanged. The change is a thin wrapper around
didKeyDriver.get, so it adds a new key family without altering resolution
of currently-supported keys.

Backward compatibility

Fully backward compatible. Non-0xeb51 did:key identifiers take the original
code path with no behavioral change; only previously-unresolvable
jwk_jcs-pub keys are newly handled.

Dependencies

Promotes base58-universal (already present transitively) to a direct
dependency, used to decode the multibase payload for multicodec inspection.

Testing

Adds test/bedrock/40-documentLoader.test.js coverage that builds jwk_jcs-pub
did:key identifiers from a sample P-256 JWK and resolves them through the
document loader:

• Resolves a z2dm… (jwk_jcs-pub) identifier to a P-256 verification method
  whose document id is the canonical p256-pub (zDna…) form.
• Resolves the z8DK… / zYqN… variants (same key, but with 33-byte
  coordinates that shift the multibase prefix) and asserts all three normalize
  to the same canonical key / document id — exercising both the
  multicodec routing and the coordinate normalization.

[ottonomy]

Thanks for the contribution. This will be included in the next released version ~10.1.4

I also applied a change to enforce JCS canonicalization to achieve the stated benefit from the EUDI docs

The MSI assures a one-to-one correspondence between the DID and the public key (the same public key cannot generate different DIDs, and different DIDs cannot resolve to the same public key).

This doesn't necessarily line up with what you described as variations in key length. Not quite sure what the benefit is of allowing the issuer to use multiple variants of the same key contra to the EUDI documentation.

I'm going to do a little more work today to try to understand your approach and when different variations of those keys might appear, and how they would relate to the trusted issuer identifiers registered for a workflow.