There have been a number of discussions at TC39 that have resulted in the committee holding the opinion that Integrity data belongs out of band. There are a number of reasons for this, module cycles and maintainability being the some of the easier to explain.
WICG is already incubating the Import Map proposal, but the explainer outlines that integrity is currently out of scope. There is a possibility that an integrity map and an import map could merge into a single manifest, but it would appear that it should be explored and spec’d on its own merits first.
The left hand side is the resource, the right hand side the SRI. This would scale to various resource types, not limited to JavaScript. it could integrate into the existing integrity checks already in HTML for any resources in the map. I would imagine that it would likely support all the types of meta data currently support by the integrity attribute
As we see more adoption of modules in JavaScript and individuals consuming resources VIA HTTPS URLs I think having a mechanism for integrity checks with be extremely important, having a standard mechanism for this even more so.
There is no full integrity modules story right now. This is because lazy loading of modules with dynamic import() does not support integrity. Working towards a concrete solution for the integrity of modules is clearly an important problem so thanks for bringing this up!
SystemJS recently came up across this integrity limitation and without any other proposals being available had to implement a custom solution here. I’d be very interested to see further collaboration in this space.
@Jake_Archibald’s suggestion for fetch maps (a more general “stable [module] source text by externalizing hashed names in specifiers”): [Proposal] fetch-maps
Given the potential size of this data and that it likely would have to be shipped in the initial HTML, I think that being cautious with the total size would be important. Collapsing some of these could help but maybe even a less human-readable format could be great.
In general, integrity solutions provide answers to the question “does this resource have a property that is easy for a trusted source to arrange it to have but hard for an untrusted source to arrange it to have.”
There are non-hash based ways to answer that question; e.g. signature verification which would require metadata (a public key chain) that is specified once for potentially many modules, not per-URL.
One argument for putting signature verification explicitly out of scope might be that resources can come from the cache, and it might be tricky for the cache to store enough information to verify a signature for a resource that was initially fetched outside the scope of any integrity metadata.
I just don’t know enough about signed HTTP bodies.
I believe import map scripts themselves do support integrity attributes, which is crucial since the import map does have such a high security position.
That said I just checked the Chrome implementation and apparently it does not, which seems like a problem.