the trust chain is fastly renewed to check against any revocation of its subject

the trust chain is resolved under a well known trust anchor, that defines if the subject can play the role of wallet provider

wallet provider's public key may rotate, therefore I'm againts any hard-coded cryptographic binding within the application'd code.

the Trust List as reinforcment makes sense, since it is inline with the eIDAS trust architecture, at the same time the trust list may contain the trust anchors or the wallet providers.

at the same time a bogus wallet provider, listed in the trusted list as well, may became an adversary. For this reason some security/implementation consideration should be developed along this issue. there may be cases where a wallet instance knows how to interact with its wallet provider. We need to explain and make this clear to the implementers

Wallet Providers though their Trust Chain Root Authorities are anchored in Trust Lists managed by appointed Supervisory Bodies or by delegated authorities. This ensures the integrity and authenticity of wallet solutions are rigorously maintained. These layers of security and oversight create a trusted environment, allowing users to rely on the legitimacy and safety of their Wallet Instances. Consequently, this robust framework significantly mitigates the risk of fraudulent redirections, safeguarding users' transactions and data.

@cmarco0 has correctly pointed out how a trust chain cannot be faked.