vcr/verifier: nil-pointer panic on unparseable issuer DID

[stevenvegt]

Description

When verifying a credential whose issuer field can't be parsed as a DID, the verifier discards the parse error and dereferences a nil pointer on the next line.

Location

vcr/verifier/verifier.go (lines around 156–167):

issuerDID, _ := did.ParseDID(credentialToVerify.Issuer.String())  // err discarded
// ... a few lines ...
_, _, err = v.didResolver.Resolve(*issuerDID, &metadata)           // panic if issuerDID == nil

The _ on did.ParseDID swallows any parse error; if the input isn't a valid DID URI per RFC 3986, issuerDID is nil and the dereference at the Resolve call crashes the whole node (empty connection reply on the originating HTTP request, runtime error: invalid memory address or nil pointer dereference in logs).

Reproduction

Any external issuer that emits a non-RFC3986 did:x509. The original case we hit:

The AET ZORG-ID SDK, signing with the shipped test-nuts.zorginstelling-01.nl soft cert, emits this iss:

did:x509:0:sha256:<hash>::subject:O:Tést Zorginstelling 01::san:otherName:2.16.528.1.1007.99.2110-1-…, othername: Permanent Identifier:<unsupported>

The trailing …, othername: Permanent Identifier:<unsupported> (literal spaces, comma, angle brackets) makes did.ParseDID return (nil, err). Posting that JWT VC to /internal/vcr/v2/holder/{subject}/vc panics the verifier.

A bug on the issuer's side (separately reported to AET) — but a malformed-input panic is a nuts-side defect regardless.

Proposed fix

Surface the parse error instead of dropping it:

-    issuerDID, _ := did.ParseDID(credentialToVerify.Issuer.String())
+    issuerDID, err := did.ParseDID(credentialToVerify.Issuer.String())
+    if err != nil {
+        return fmt.Errorf("could not parse issuer DID: %w", err)
+    }

Turns the panic into a clean validation error.