Summary

Remove all port/channel capability authentication checks in core handlers which are routed by ICS 026.

These checks do not add additional protection. ICS 026 will use the port or channel identifier to obtain the capability provided to the core handler. Then the core handler will verify the capability using the same ICS 026 module. The circular logic became evident during a code walk through.

Code example

Here is the call stack when this occurs in ibc-go.

1. Initiate MsgChanOpenInit
2. Obtain portCap
   - which calls capabilityKeeper.LookupModules
   - which calls GetCapability
3. Authenticate portCap
   - which calls capabilityKeeper.AuthenticateCapability
   - which calls GetCapabilityName
   - which performs the opposite lookup as GetCapability

Thus, within practice, we are obtaining the capability via the reverse lookup (using IBC scoped keeper) and authenticating the capability using the forward lookup (using the same scoped keeper). Capability authentication should only occur when the capability provided is by another module (SendPacket for example)

Spec change example:

Remove the following check from chanOpenInit

abortTransactionUnless(authenticateCapability(portPath(portIdentifier), portCapability))

Note, I believe the spec isn't specifying how portCapability is obtained