Redo integrity verification in IsolatedContext spec #44
Conversation
|
@domfarolino, could you review this as well? |
There was a problem hiding this comment.
Generally LGTM % two questions. The first question is in the review. My second question is: by what mechanism does the origin integrity verification map get populated? Is the expectation just that browsers bake in their own static list of algorithms? If so, I think making that a "note" below the dfn would be good, since nothing currently defines how it gets populated (besides saying something about "implementation defined")
I added a note. This particular spec is focused on the security requirements needed to enable powerful capabilities, but is narrower than the entire IWA project, which is one implementation that satisfies the security requirements outlined here. Browser developers could in theory implement a system similar to Meta's Code Verify to meet these security requirements as well. |
SHA: ee2fccb Reason: push, by robbiemc Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: ee2fccb Reason: push, by robbiemc Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This addresses the issues raised by @domfarolino in WICG#42 regarding how the spec was tying integrity verification to browsing context group. Rather than attaching integrity verification information to browsing context group, which doesn't exist for all environments, this moves the information to a user agent level map.
This addresses the issues raised by @domfarolino in #42 regarding how the spec was tying integrity verification to browsing context group. Rather than attaching integrity verification information to browsing context group, which doesn't exist for all environments, this moves the information to a user agent level map.
Preview | Diff