Bug when credential and status list are not signed with the same key

[cre8]

When I have a crdential signed with Cert A and the status list signed with Cert B (both certs include different public keys), the validation will fail.

The reason for this is that when no custom statusVerifier is passed, the sd jwt instance will use the same as defined for the credential verification: https://github.com/openwallet-foundation/sd-jwt-js/blob/main/packages/sd-jwt-vc/src/sd-jwt-vc-instance.ts#L316

Here only the verifier is set:

credo-ts/packages/core/src/modules/sd-jwt-vc/SdJwtVcService.ts

Line 320 in 5c6bc68

verifier: getSdJwtVerifier(agentContext, issuer.publicJwk),

which is passing the public key:

verifier: getSdJwtVerifier(agentContext, issuer.publicJwk),

A recommend logic was implemented here having the same logic: https://github.com/openwallet-foundation-labs/eudiplo/blob/main/apps/backend/src/verifier/presentations/credential/sdjwtvcverifier/sdjwtvcverifier.service.ts#L38

The logic behind this implementation:

• search in the verify method for a matched identity (following the ETSI TS 119 602 trust list). A match includes the public key for signing the cert and one for signing the revocation list
• if one match was found, save it to matchedEntity
• when statusVerifier is called, pass the matched entity to the status list. It will check if the status list is signed with the correct key

With this approach you get the freedom to implement your credential key and status key binding based on the eco system

[TimoGlastra]

I think this makes sense. We already have a method to get the trusted x509 certificates for a verification. I think we should rework this to allow returning:

• the allowed status list signers
• optionally, the allowed doctypes/vct types

That way the user of Credo can return this, and it can be integrated with any trust mechanism