You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if web developers could verify the provenance of resources they depend upon, establishing the technical foundations upon which they can increase confidence in the integrity of their dependencies. We offer brittle, content-based integrity mechanisms today which can (in theory) but do not (in practice) enable this capability. This proposal explores an alternative that builds upon existing integrity checks (e.g. <script integrity> and signature mechanisms (RFC9421 to give developers an additional option when deciding how to protect their sites from unexpected injection.
In short, developers will include the following on their site:
<scriptsrc="https://amazing.example/widget.js"
crossorigin="anonymous"
integrity="ed25519-[base64-encoded public key]"></script>
Servers will deliver resources signed with the asserted key:
HTTP/1.1 200 OKAccept-Ranges: noneVary: Accept-EncodingContent-Type: text/javascript; charset=UTF-8Access-Control-Allow-Origin: *Identity-Digest: sha-512=:[base64-encoded digest of the response body]:Signature-Input: sig1=("identity-digest";sf); alg="ed25519"; keyid="[base64-encoded public key]"; tag="sri"Signature: sig1=:[base64-encoded result of Ed25519([response body], [private key])]:
Modulo a few details we're still working out in the draft spec and on GitHub, that's it. Easy peasy. WDYT?
The text was updated successfully, but these errors were encountered:
Request for Mozilla Position on an Emerging Web Specification
@
-mention GitHub accounts): @mikewestOther information
TL;DR:
It would be nice if web developers could verify the provenance of resources they depend upon, establishing the technical foundations upon which they can increase confidence in the integrity of their dependencies. We offer brittle, content-based integrity mechanisms today which can (in theory) but do not (in practice) enable this capability. This proposal explores an alternative that builds upon existing integrity checks (e.g.
<script integrity>
and signature mechanisms (RFC9421 to give developers an additional option when deciding how to protect their sites from unexpected injection.In short, developers will include the following on their site:
Servers will deliver resources signed with the asserted key:
Modulo a few details we're still working out in the draft spec and on GitHub, that's it. Easy peasy. WDYT?
The text was updated successfully, but these errors were encountered: