This flow could be prone to 'man-in-the-middle' attacks at 'Message 2' Link

Indeed we need to guarantee that a malicious actor cannot redirect Trust Chain verification to a fake chain.
To avoid this an option Wallet Instance could include Wallet Provider's Public Key (Instance will need to be updated in case of key changes in this case), other option would be that Wallet Provider or its Trust Chain Anchor need to be 'anchored' in a Trust List/Registry managed by the Supervisory Body where its Public Key is available.

From Wallet Provider's side, to avoid that third parties could request a Wallet Attestation (therefore the attestation would come not from the Wallet Instance but from a malicious actor), there should be a method to securely identify a real Wallet Instance (for example there could be an instance identifier encrypted with a dedicated WP Private Key).