[Core] Add a Signer validation method to include host-specific checks for validate() processes

[Farhad-Shabani]

Problem Statement

IBC messages contain a Singer field, which have not yet been used in any operations of IBC-rs, but should be checked and disallowed for a counterfactual signing. So, from the IBC module standpoint, we get sure that once a message passes the validation phase, all the fields are valid.

• Similar checks are done in IBC-go upon calling a sdk method like here

Proposal

It can be accomplished by exposing an additional interface through ValidationContext that provides a room for hosts to verify signer accounts as needed.

[plafer]

Should this be included in #233 as well?

[hdevalence]

Why does the signer field need to be validated?

IBC messages are self-authenticating, the relayer is not a trusted part of the system design. They're authenticated by the counterparty chain, not the relayer who happened to send the transaction.

The current domain types in ibc-rs ban empty signer fields, but this is does not seem to be part of the IBC specification.

[Farhad-Shabani]

Why does the signer field need to be validated?
IBC messages are self-authenticating, the relayer is not a trusted part of the system design. They're authenticated by the counterparty chain, not the relayer who happened to send the transaction.

Sounds like we are on the same page. Maybe, I didn't phrase this issue well.
The main goal is to make sure that every field, even sub-fields, of a domain IBC message undergoes thorough checks when going through the validate() process (e.g. here). Thus, from IBC-rs point of view, passing the validate() means an IBC message is fully trustworthy.

To achieve this, a validation check:

1. might be performed internally (without needing to assume anything about host chains),
2. or be delegated to hosts by exposing the necessary interface, allowing them to implement whatever validation they believe is necessary. E.g. here for the Signer we can have ctx.validate_signer(signer) within that validate() function.
   (as a side note, for signers in IBC-go, we can use the SDK's AccAddressFromBech32 to verify their authenticity, so no additional signer check method exists there for the context).

This way, we are sure that all the needed validation steps are being considered. None are being missed. Besides, the boundaries between the checks that should be carried out by IBC-rs and those that should be handled by hosts are clearly defined.

The current domain types in ibc-rs ban empty signer fields, but this is does not seem to be part of the IBC specification.

Given the above points, yes. To me, it seems more appropriate to drop this too and leave it to the hosts.

Hopefully, I didn't miss anything, but if so, let me know.

[Farhad-Shabani]

Should this be included in #233 as well?

I think it's better to handle this separately

[plafer]

Why does the signer field need to be validated?

IBC messages are self-authenticating, the relayer is not a trusted part of the system design. They're authenticated by the counterparty chain, not the relayer who happened to send the transaction.

The current domain types in ibc-rs ban empty signer fields, but this is does not seem to be part of the IBC specification.

ibc-go ensures that the Signer field is a valid Bech32 address (e.g. here). A validate_signer() method would allow chains to do similar validation if they want