Security: Unsafe type casts in DID verification with JWK parsing

[A-Chronicle]

Problem

Public key JWK parsing uses unchecked as any casts without validation, allowing type-mismatched data to silently proceed through cryptographic verification.

Affected Code

• packages/lib/sdk/src/mercury/DIDCommDIDResolver.ts:44-45 - JWK coordinates cast as any without validation
• packages/lib/sdk/src/castor/methods/prism/index.ts - Base64 JWK decoding with unvalidated any cast
• packages/lib/sdk/src/plugins/internal/didcomm/tasks/HandleRequestCredential.ts:397, 401 - Credential format/claims type-casted without guards

Why This Matters

This is in the cryptographic verification layer. If malformed JWK data gets through, signature verification could incorrectly succeed or fail silently. The TODO comment in prism/index.ts confirms this was always incomplete: 'TODO need to properly parse JWK into key / raw'

Current Code Example

// DIDCommDIDResolver.ts:44-45
const publicKeyBase64 = method.publicKeyJwk?.x as any;
const publicKeyKid = (method.publicKeyJwk as any).kid;

Suggested Fix

Create proper type guards and validated parsers:

function parseJWKCoordinate(jwk: unknown, field: string): string {
  if (typeof jwk !== 'object' || jwk === null) {
    throw new CastorError.InvalidKeyError(`Invalid JWK: missing ${field}`);
  }
  const value = (jwk as Record<string, unknown>)[field];
  if (typeof value !== 'string') {
    throw new CastorError.InvalidKeyError(`Invalid JWK: ${field} is not a string`);
  }
  return value;
}

Impact

Critical - Affects signature verification and authentication in credential issuance/verification flows

[A-Chronicle]

Hey @elribonazo @yshyn-iohk

I've submitted this PR to address two critical security and reliability issues in the Mercury DIDComm implementation that were raised in #625 and #626:

What This Fixes

#625 - Unsafe JWK Type Casting

• Added strict runtime validation for JWK field parsing
• Prevents malformed cryptographic keys from silently passing through signature verification
• Replaces unsafe as any casts with proper type guards

#626 - Silent Error Suppression in Message Unpacking

• Replaces silent failures with explicit error throwing
• Allows callers to distinguish between empty responses and actual parsing failures
• Improves debuggability in credential issuance/verification flows

Ready for Review

• All commits are GPG signed and follow conventional commit specification
• No external dependencies added
• Follows contribution guidelines
• DCO check passing

I'd appreciate your feedback on the implementation and approach. Looking forward to discussing any improvements or concerns.