In section 4.1 Basic Address Resolution, the spec says:
it is expected that paymail services will implement at a minimum P2PKH output scripts... paymail services can be implemented such that they derive new keys from only an xpub. In this way, neither the wallet seed nor any private keys are held by the paymail service implementation.
However, by deriving keys from an xpub, without access to corresponding private keys, the Paymail service would be unable to implement Section 4.3 Receiver Approvals which requires returning a signed message to the sender for validation using the receiver's public key.
The signature field MUST contain a valid Bitcoin message signature over the UTF8 byte string content of the token field that senders MUST validate against the receiver's public key.
The signature field is added and MUST contain a valid Bitcoin message signature over the UTF8 byte string content of the concatenation of the token and output field that senders MUST validate against the receiver's public key.
A workaround might be that the Paymail service has its own keypair for signing response messages. Subsequently, the sender would verify the signatures using the Paymail service's public key rather than the receiver's public key.
In section
4.1 Basic Address Resolution, the spec says:However, by deriving keys from an xpub, without access to corresponding private keys, the Paymail service would be unable to implement
Section 4.3 Receiver Approvalswhich requires returning a signed message to the sender for validation using the receiver's public key.202 AcceptedReceiver CallbackA workaround might be that the Paymail service has its own keypair for signing response messages. Subsequently, the sender would verify the signatures using the Paymail service's public key rather than the receiver's public key.