This is a decent mitigation. It would be important to mandate that the one initiating the connection has to disclose the code if required (an important ask requ

This is a decent mitigation. It would be important to mandate that the one initiating the connection has to disclose the code if required (an important ask requiring verification). This seems like it would be obvious, but without being explicit in the protocol there may be some clever social engineering technique to reverse that role. Not following this requirement would allow for a very lenient MITM attack where the attacker can initiate both connections and get one of them to leak the code and use it on the other. Another option would be to have the TOTP code be a custom 10-digit variant (eg. KeePassXC allows this). One party starts with the first 5 digits and the other party must finish it. If this option isn't available, a less ideal one (inconvenient, lower compliance) is to wait for code rollover and have the second party provide the next code. Another problem: A TOTP app is required, in which case why not have an E2E encrypted communication app instead? The only time this is useful is when you cannot have your secure device go online and use the E2E encrypted app and you need to authenticate an unsecured channel on some other device.