Generic issuer-to-credentialSubject attribute matching for did:x509

Parent PRD

#4079

What to build

Extract the validatePolicyAssertions logic from X509CredentialValidator and make it apply generically to any credential with a did:x509 issuer. This implements PSA 10.6.2 rule 9: identifier values in credentialSubject that originate from the issuer DID must match the corresponding attributes in the issuer DID.

• In the Verify function (verifier.go), after signature verification succeeds for a credential with a did:x509 issuer, match credentialSubject identifiers against issuer DID attributes
• Implement a recursive walk of the credentialSubject JSON to find all objects with system/value fields (identifier pattern per PSA 10.6.1)
• Match each identifier against the corresponding issuer DID attribute based on system URI:
  • http://fhir.nl/fhir/NamingSystem/ura → URA from issuer DID
  • http://fhir.nl/fhir/NamingSystem/uzi-nr-pers → UZI-nummer from issuer DID
• Handle roleCode as a known special case (direct attribute, not an identifier object)
• Remove validatePolicyAssertions from X509CredentialValidator

This is independent of the CRL/resolver changes and can be worked on in parallel.

Acceptance criteria

• Identifier matching runs for any credential with a did:x509 issuer, not just X509Credential type
• Recursive walk finds deeply nested identifiers (e.g., credentialSubject.hasEnrollment.enrolledBy.identifier)
• URA mismatch between credentialSubject and issuer DID produces an error
• UZI-nummer mismatch between credentialSubject and issuer DID produces an error
• roleCode mismatch produces an error
• validatePolicyAssertions is removed from X509CredentialValidator
• Existing X509Credential tests pass
• New test: PatientEnrollmentCredential with matching UZI-nummer passes
• New test: PatientEnrollmentCredential with mismatched UZI-nummer fails
• New test: HealthcareProviderCredential with matching URA passes
• New test: HealthcareProviderCredential with mismatched URA fails

Blocked by

None — can start immediately (independent of resolver/key resolution changes).

User stories addressed

• User story 1: PatientEnrollmentCredentials get attribute matching
• User story 2: HealthcareProfessionalDelegationCredentials get UZI-nummer and roleCode validated
• User story 3: HealthcareProviderCredentials get URA validated
• User story 7: existing behavior preserved
• User story 8: no type-specific validators needed for new credential types

Start in verifier.go and inspect the existing validatePolicyAssertions logic in X509CredentialValidator, including the existing X509Credential tests. Trace verification after signature validation and identify the credentialSubject structures and issuer DID attributes involved. Done means generic did:x509 credentials pass matching URA, UZI-nummer, and roleCode checks, mismatches fail, recursive identifiers are covered by new tests, and the old validator logic is removed.