demo · v141

Key Rotation

The whole point of signature-based SRI over hash-based SRI: the publisher can ship updates without updating the integrity attribute on every consumer. Generate an Ed25519 keypair, sign a payload, mutate the payload, watch verification flip. Then re-sign with the same key — and verification snaps back.

Heads up Requires Chrome 141+. The browser's actual signature-based SRI plumbing runs at network layer; this page uses SubtleCrypto directly so you can see the same verification primitive a Chrome consumer would run.
checking support…
publicKey (raw, base64)(not generated)
payload (the resource bytes)
signature (base64)(not signed)
no verification yet

in the real header chain: the server returns Integrity + Signature headers, the page declares the expected public key in integrity="ed25519-…", Chrome runs the same verification you see here, refuses to apply the resource if it fails.

the page-side integrity

<script src="/app.js"
        integrity="ed25519-MCowBQYDK2VwAyEAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        crossorigin="anonymous"></script>

// Server response includes:
//   Signature: sig1=:base64Signature:
//   Signature-Input: sig1=(...)
// Chrome verifies the signature using the public key from the integrity attribute.
// Verification fails -> resource is dropped, just like a content-hash mismatch.

why this angle

The explainer's core argument is "complementing the existing mechanisms" — hash-based SRI pins one byte sequence forever, which is impossible for any resource that ships updates (analytics scripts, telemetry, A/B test runtime). Signature-based SRI lets the publisher rotate content while consumers keep the same public key. The "supply chain integrity for dynamic resources" framing maps directly onto this: every npm dependency that auto-updates can be made tamper-evident by pinning to a publisher key, not a content hash.

see also