QR-based signing flow payloads in Miniscript context

The discussion around the standard proposal reveals a mix of approval and concerns, particularly regarding feature flags. While recognizing their potential utility for enhancing functionality, there is an apprehension that without meticulous definition, these flags might lead to complications in application. The integration of a session ID or a similar signing request identifier is favored as it would significantly aid in ensuring that responses, particularly signatures, are accurately associated with their respective PSBT/signing flow. This mechanism would allow coordinators to verify and confirm that returned signatures are correctly matched before they proceed with merging them into the broader transaction framework.

Further examination highlights the importance of stringent verification processes by the signer. The signer is expected to authenticate each request against a pre-established descriptor or policy and the provided PSBT. This step is critical to ensure that the signature is only provided for the intended transaction path. In scenarios where no specific spend-path selection is communicated, the default behavior of the signer should prevail. This approach is deemed crucial for wsh Miniscript applications, where the PSBT might detail the script without clarifying the desired satisfaction path. This could be equally significant for TapMiniscript contexts, where multiple potential execution paths might exist due to the presence of various leaves or satisfaction options.