[This comment is partly based on discussion in yesterday’s ZIP sync meeting, although it is my analysis.]
I’m skeptical of some of the rationale for this feature; I don’t think it will actually help much with centralized exchanges, for instance.
I’m also skeptical of the “It is transitive (which is bad)” argument, because Bob can always give Charlie enough information to allow Charlie to act as Bob. This is a general counterargument to attempting to prevent transitive grants of authority in any cryptographic capability system (which is what Zcash is). [*1]
But my long-standing position has been that addresses as currently designed grant too much authority, so I accept that part of the argument — expressed in the points “It’s loose” and “It’s not easily revocable”.
My main comment on the protocol outline at Zcash Transaction Confirmation Via Recipient Counter-Signatures - Google Docs is that it is insufficient for the recipient to prove knowledge of the incoming viewing key. That key is a viewing key, not an authorization key, and it is fully intended that it can be given out to parties that should not be able to act as the recipient.
I suggested, in comments on the Google Doc, a different approach involving additive blinding of \mathsf{ask} (identical to what we already use for hardware wallets) that fixes the problem and allows the transaction to be authorized by knowledge of the spending key. Note that the required RedPallas signature can be produced by a hardware wallet, and so a recipient that holds its spending keys in a hardware wallet can use it to authorize transactions (which would otherwise be a showstopper for authorizing transactions using the spending key).
This approach would require proving the “Spend authority” and “Diversified address integrity” parts of the Action statement for the new note, along with “New note commitment integrity” to ensure that the proof is about the right note. Given that the recipient-authorization signature would also have to be unlinkable in a protocol based on Qedit’s proposal, a blinding step for \mathsf{ivk} with at least similar cost to “Spend authority” [*2] is needed (both solutions in the Google Doc have at least that cost), and that would also need to be done in a zk proof along with “New note commitment integrity”. So the extra cost for my approach relative to Qedit’s (restricting to variants with adequate address privacy properties) is at most one full-width variable-base Pallas scalar multiplication in a zk circuit, while fixing a significant problem that would interfere with the use of viewing keys. My approach is also easier to analyze because it reuses RedDSA’s key rerandomization property rather than inventing a new protocol for blinding.
It is possible to make transactions that make a payment requiring authorization indistinguishable from those that do not. Details omitted here, but note that we can have a proof per transaction that proves linking of the recipient authorization with the required RedPallas signature key if needed and with an arbitrary key if not. This incurs constant additional validation cost for all transactions regardless of the number of actions (with the trade-off that if a payment requires authorization, it must be the only payment in the transaction).
[*1] In fact diversified addresses were almost rerandomizable, which would have allowed Bob to give Charlie a randomized address for Alice that could not be traced to Bob. The design decision to make them non-rerandomizable in Sapling was motivated by fixing a separate decryption oracle attack. That is, we did not make a conscious decision that preventing untraceable forwarding of addresses was a goal; that was a side-effect of the use of \mathsf{DiversifyHash} which was introduced for a different reason.
[*2] Qedit’s “Unlinkability Solution 2” uses multiplicative blinding rather than additive. That costs slightly more (a variable-base scalar multiplication rather than a fixed-base one). I am not sure why they chose multiplicative.