The Basic engine is found in [ShibOnedotThree] and extracts keys and certificates directly from MetaData to evaluate signatures or TLS credentials.
...
Since each key found is evaluated, new keys can be introduced by registering them in metadata, waiting a pre-defined period of time for the change to propagate, and then finally deploying the new signing key.
Known Issues
Currently all versions Versions of the [ShibOnedotThree] C++ ServiceProvider prior to the latest, 1.3.1, mistakenly ignore any <md:KeyDescriptor> without a use attribute set to "signing". A future patch will correct 1.3.1 corrects this and permit permits descriptors with no use attribute to be applied.
Validating TLS and X.509 Credentials
Note: As of version 1.3.1 (currently IdP only), the behavior is now identical to the ExplicitKeyTrustEngine. Otherwise, the behavior is as described below.
Each <md:KeyDescriptor> is resolved into a certificate chain. The first certificate in the chain (assumed to be the first one in order) is directly compared to the client or server TLS certificate presented. If they match exactly, then the engine returns success.
In addition, the IdP as of version 1.3.1 now extracts the public key from the TLS certificate and compares it to the key in the certificate in the metadata, as in the new [ExplicitKeyTrustEngine].
The following <ds:KeyInfo> children can be resolved into keys without additional plugin support:
<ds:X509Data>/<ds:X509Certificate><ds:KeyValue>/<ds:RSAKeyValue>(1.3.1 only)<ds:KeyValue>/<ds:DSAKeyValue>(1.3.1 only)
Note that under no circumstances is an X.509 certificate evaluated on any level by Shibboleth during the comparison. Valid or expired certificates issued by any signer with any sort of extensions are acceptable as long as they match what is presented exactly.
...