I'm not very familiar with this logic, so would appreciate more eyes on this. (Perhaps @dmcgowan has time to have a look to double check?)

Look like this at least needs an update in the function's documentation

I'm a bit confused though; what's the purpose of keyID now? If it was previously to specify which key to verify against, now it is fully ignored (any non-empty string would do?) and any key present in verifyOpts.TrustedKeys is accepted?
If keyID is no longer needed, should verifyOpts.TrustedKeys be changed to a slice instead of a map, and this function check for len(verifyOpts.TrustedKeys) > 0?

The new logic treats all rootcerts that are loaded equal; is that a safe assumption? Again, I'm not an expert in this area, but could there be (e.g.) intermediates that are now accepted, but should not?.

Looking at https://datatracker.ietf.org/doc/html/rfc7517#section-4.5

4.5.  "kid" (Key ID) Parameter

   The "kid" (key ID) parameter is used to match a specific key.  This
   is used, for instance, to choose among a set of keys within a JWK Set
   during key rollover.  The structure of the "kid" value is
   unspecified.  When "kid" values are used within a JWK Set, different
   keys within the JWK Set SHOULD use distinct "kid" values.  (One
   example in which different keys might use the same "kid" value is if
   they have different "kty" (key type) values but are considered to be
   equivalent alternatives by the application using them.)  The "kid"
   value is a case-sensitive string.  Use of this member is OPTIONAL.
   When used with JWS or JWE, the "kid" value is used to match a JWS or
   JWE "kid" Header Parameter value.

That wording makes me think that the kid should NOT be ignored ("is used to match a specific key"), and in general, key-ID's SHOULD be unique ("different keys within the JWK Set SHOULD use distinct "kid" values"), BUT, based on this sentence;

One example in which different keys might use the same "kid" value is if they have different "kty" (key type) values but are considered to be equivalent alternatives by the application using them.

It looks like a single kid MAY have multiple alternatives (in different formats, but considered equivalent). If my interpretation of that is correct, then trustedKeys should be something like map[string][]libtrust.PublicKey (single keyID having multiple alternative public-keys?)

As far as I understand, the JWK Key ID is used in the JWKS URI from OpenID, where multiple keys might be specified (see https://code.beryju.org/oauth/discovery/keys), and in that case the Key ID used in that document needs to match the Key ID in the JWT, as well as signature being validated with that same key.

Since this project directly compares against a list of certificates instead of JWK-formatted key entries, there's no way to pre-specify the key ID since it is not encoded in the certificate in any way

I also don't think this will allow the loading of keys from different certificates, since a JWT is always signed by a single public/private key pair, and there is no certificate chain embedded into the signature, so given certificateA is issued by intermediateA, and a JWT signed by certificateA, it will only be validated with the certificateA and not intermediateA

CC: @justincormack , can you please weigh in here so we move forward with this.

Sorry to bump this again, it's already been another month and I'd like to stop using my local dev build in production to circumvent this

since a JWT is always signed by a single public/private key pair, and there is no certificate chain embedded into the signature, so given certificateA is issued by intermediateA, and a JWT signed by certificateA, it will only be validated with the certificateA and not intermediateA

That is incorrect. JSON Web Signatures can and do embed the certificate chain so that tokens signed by certificateA can be verified using the CA certificate which issued intermediateA.