Carlos Rodriguez

Closing the issue. It seems we don't to take any action or change anything.

Closing as this has already been added to the spec and [implemented in ibc-go](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/07-tendermint/update.go#L124).

> I might be missing something but it looks like the client verification functions can be generic. They just seem to retrieve the host data needed for the final call...

Adding for reference https://github.com/cosmos/ibc-go/issues/1835, where basically the same functionality was requested.

Adding here [comment](https://github.com/cosmos/ibc-go/pull/1713#pullrequestreview-1046458011) from #1758.

We discussed internally and we can support this if we implement the following change: ```diff diff --git a/modules/apps/transfer/types/transfer_authorization.go b/modules/apps/transfer/types/transfer_authorization.go index 242bc86e8..dc5bc2753 100644 --- a/modules/apps/transfer/types/transfer_authorization.go +++ b/modules/apps/transfer/types/transfer_authorization.go @@ -171,6 +171,12 @@...

Thanks for the comment, @george-aj. > Am I right to think that this would mean there's only one match possible? Yes, correct. The whole memo string in `MsgTransfer` should match...

Thanks for the clarification, @george-aj. Yes, that would simplify the code! Assuming we still want to keep the current functionality of including packet data keys in `AllowedPacketData` then we could...

> What about having the memo string validation run first and if it fails then the packet data key validation run? So you mean doing something like this instead? ```go...

Discussed with @womensrights and we will follow @srdtrk's suggestion of dropping support of keys. We will support only memo strings.