There are likely to be cases within a domain where a client wants to
get his address "signed" with BATV but where you don't want to hand
out the shared secret (or private key for that matter) to the client.
Sure, but this is hardly a concern unique to BATV. DKIM has the same
issue, as I expect does any other content signing scheme. We didn't
think that we had to define remote signing methods for DKIM, so it's
not clear to me why we have to define them here.
Because DKIM is specifically designed to cover message transfer between
administrative domains. It is not a MUA-level facility, occasional
assertions to the contrary notwithstanding.
BATV could also be restricted in a similar way, but (a) The present draft
doesn't say that and I don't know if there is consensus for such a restriction
being imposed and (b) Unlike DKIM, which has to covers the entire message and
therefore gets more problematic the more hops it tries to encompass, there's no
similar issue for BATV because local parts of addresses are pretty well
preserved by the present infrastructure.
As I said previously, you can restrict BATV in this way but I really have to
wonder if the resulting very narrowly applicable mechanism is worth the bother.
Ned