That's it. This seems like the simplest possible approach, and has some interesting properties:

• It addresses many of the "evil third party" concerns that drove interest in hash-based SRI. If some embedded third party content is compromised -- for example, a widget, or a JavaScript library included from offsite -- an attacker may be able to maliciously alter source files, but hopefully won't be able to generate a valid signature for the injected code because they won't possess the relevant private key. Developers will be able to ensure that their code is executing, even when it's delivered from a server outside their control.

• Signatures seem simpler to deploy than a complete list of valid content hashes for a site, especially for teams who rely on shared libraries controlled by their colleagues. Coordinating on a keypair allows rapid deployment without rebuilding the world and distributing new hashes to all a libraries' dependencies.

• Signatures can be layered on top of URL- or nonce-based restrictions in order to further mitigate the risk that unintended code is executed on a page. That is, if we provide an out-of-band signature requirement mechanism, developers could require that a given resource is both specified in an element with a valid nonce attribute, and is signed with a given key. For example, via two CSPs: "script-src 'nonce-abc', script-src 'ed25519-zyx'". Or even three, if you want URL-based confinement as well: "script-src https://example.com/, script-src 'nonce-abc', script-src 'ed25519-zyx'".

• Does anyone need this? Really?

  There's been interest in extending SRI to include signatures since its introduction. w3c/webappsec#449 captures some of the discussion, and though that discussion ends up going in a different direction than this proposal, it lays out some of the same deployment concerns with hashes that are discussed in this document (and that Google is coming across in internal discussions about particular, high-value internal applications).

  It seems likely that many companies are responsible for high-value applications that would benefit from robust protections against injection attacks, but who would also desire a less brittle deployment mechanism than hashes.

  Additionally, many websites which are using hash-based CSPs today experience friction from having to update the CSP header when scripts on the page change, but do not want to use the less safe host-based allowlists in CSP. This would allow specifying a fixed public key in the CSP and on the