The current implementation of the payload-hash-sha256 and payload-hash-sha1 match types only considers secrets provided one per header. To support secret rolling (as used by Stripe), I propose supporting the following scheme:

Initially, we have the following:

X-Coral-Signature: sha256=9ebcba58721f138c3f82a5896f350601aa5b162f5e274b47a312118bbc9ba9f0

But when we're rolling secrets, we send requests with a signature from the old secret, and the new secret for a time frame allowing administrators to update code or environment variables to the new secret. This gives us a header that looks like this instead:

X-Coral-Signature: sha256=3ad8d2e511faefce65e6576f5ea850431ca2e1f39d8b3b13e3dce6971d35f1eb,sha256=9ebcba58721f138c3f82a5896f350601aa5b162f5e274b47a312118bbc9ba9f0

Which is essentially:

sha256={ new signature },sha256={ old signature }

This is the same process for the sha1 type.