Original text:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239. <del> The proxy includes the client's signature value from the original message under the label "sig1", which the proxy signs in addition to the Forwarded field.  Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del>  And a signature output value of:

Reviewer comments:
NAME please check the new test vectors to make sure they pass in your system as well!
It looks good to me (If the tests are correct) URL
+1
The first example signature from fails signature verification. By changing the validity date from 1618884475 to 1618884473 the validation succeeds. I guessed that date as it is the one used in all the other signatures. So I guess that is a typo. (It would have been good to have a different created date, just to make testing less mechanical, but then the signature needs to be changed). There is then perhaps a logical mistake in the next example. The story goes that the proxy receiving the above request alters the message and signs it before sending it on. The original signature is kept and added as part of the signature. The proxy alters the header and adds a header along with a new Signature. But by changing the the proxy makes it impossible for the recipient to verify the initial signature, since that includes a component which was changed. So the spec has to either remove the component from the client request, or change the text at the end of the section which says Note: the proxy's signature does verify for me with the timestamp of the client as it appears in the spec.
Verification of claim above: The test on line 173 of had to be disabled for my tests to pass on the JVM (JS tests coming soon). All the other tests on requests from the spec (well on one I had to change the time for it to pass. Further commits should get the JS to work.
The proxy should not alter the original signature, and that signature does need to include the component. The whole point of the story is that the proxy verifies the first signature, and the service behind the proxy verifies the proxy's signature. If we can make that story more clear, I'd be glad to!
It is indeed an option to have the final recipient rely on the signature of the proxy as a verification of the originally signed message. But the text currently says "The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application." The "independently" reads to me as if the application (that is the server receiving the signature) should be able to verify both signatures. It seems to me that it can only verify the proxy's signature though. But perhaps I was just misreading... It seems there is a dependence of the final recipient on the signature of the proxy. I think there is still the problem of the time being wrong...
Yes, the signature needs to be recalculated and replaced due to the typo in the timestamp (I will need to check the generation script). I can see now how that line can be misread. Though it is definitely possible for the origin server to validate the client's signature if it has additional information, like that discussed in URL and URL -- but this could be made more clear.

Revised text:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239.  <ins> While the proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. While it is possible for the origin server to have additional information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- signatures).  To counter this, the proxy adds its own signature over the new message before passing it along.  The proxy includes the new "@authority" derived component and the Forwarded header, which it added to the message.  The proxy's signature also includes the client's signature value from the original message in its covered components, as a dictionary field member under the label "sig1". Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of: