In the test case "Case: PSBT With invalid output witnessScript typed key", after PSBT_OUT_WITNESS_SCRIPT key with garbage data (which ends with `...478ef51309d`, follows value `2b` which would denote the length of the data value of the key. But the length of actual remaining data is only 7 bytes. Thus, an implementation that reads key-value pairs and checks for validity of the key data after it has read the current key-value pair, will not be able to hit the exact condition intended for this test case: extra data within the key itself. This is because such implementation will hit serialization error when it will try to read the data of the value and will get the short read.
Reading full key-value pair and then checking key format afterwards is fairly normal thing to do, as the format of the keys with all their meaning is an abstraction of higher level than just the simple key-value serialization format.
The proposed change is to replace byte `2b` after the key data to `06` and thus make the value length in the key-value pair valid (not going beyond the end of the data).
base64 encoding has been changed accordingly.
The sentence seems to suggest that the "master key fingerprint" can be the fingerprint of any intermediate node on the derivation path, which isn't true.
Being new to the spec, I had to reread this multiple times to understand it. Ordering the setences according to scope seems to make it easier to grock.
Change from a global map with input data to a global k/v pair with input and output data.
Add new types for finalized scriptSigs and scriptWitnesses.
Redefined types to support new model
Updated the formatting of the listing
Clarifies that global data fields redeem scripts, witness scripts,
and hd keypaths can be used for data necessary for both the inputs
and outputs of the transaction.