For this initial managed accounts only launch, IWAs will only need to be signed by a developer key. That verifies the source of the app, but the trustworthiness signal comes from the fact that an admin chose to install the app on devices.
We do have a longer term plan for countersigning by a trusted party, in which case the bundle could have multiple signatures (separate from the developer signatures), only one of which would need to be trusted by Chrome. That particular design isn't finalized yet, and we don't have an ETA on when it would ship. On Thursday, August 1, 2024 at 8:40:48 AM UTC-7 Vladimir Levin wrote: > My understanding is that IWAs would have to be signed by some entity > before they can run (Google?). I was wondering if you had thoughts about a > path forward if other browsers also support IWAs or if other companies want > to sign and accept those bundles. > > Essentially, would it become a somewhat fragmented ecosystem where some > web bundles signed by Google are executed by Chrome, and others signed by > other providers are executed by other browsers with little overlap? I'm not > sure it's a problem, but I was just curious about the possible directions > here. > > Thanks, > Vlad > > On Wed, Jul 31, 2024 at 11:48 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> or LGTM2 - sorry, race condition. >> On 7/31/24 11:46 AM, Mike Taylor wrote: >> >> Thanks for the v2 updates. >> >> LGTM1 >> On 7/30/24 2:09 PM, Reilly Grant wrote: >> >> On Tue, Jul 16, 2024 at 1:20 PM Robbie McElrath <rmcelr...@chromium.org> >> wrote: >> >>> Thanks - before I jump too deeply into the review, would you mind >>> requesting the various review gate bits in your chromestatus entry? >>> >>> Done. We've been using launch/ for the approvals so far. I added a link >>> to the corresponding launch/ approval in chromestatus when applicable. >>> >>> No, the IWA security rules are enforced with existing web primitives >>> (CSP/TT, permissions policy, COI) that already have DevTools support. There >>> is some non-DevTools tooling needed to build and sign the bundle, but I >>> don't think there's a use case for adding bundle-related functionality into >>> DevTools. >>> >>> Makes sense. Are there plans to build said tooling and make it available >>> to ease adoption? >>> >>> >>> Yeah, we already have JS tooling available to create bundles >>> <https://github.com/WICG/webpackage/tree/main/js/bundle>, sign bundles >>> <https://github.com/WICG/webpackage/tree/main/js/sign> (the new >>> integrity block format is already supported), and a webpack >>> <https://github.com/GoogleChromeLabs/webbundle-plugins/blob/main/packages/webbundle-webpack-plugin/README.md> >>> >>> and rollup >>> <https://github.com/GoogleChromeLabs/webbundle-plugins/tree/main/packages/rollup-plugin-webbundle> >>> >>> plugin. These make it easy to integrate with existing npm-based flows, see >>> the telnet demo app >>> <https://github.com/GoogleChromeLabs/telnet-client/blob/main/webpack.wbn.js#L36> >>> >>> for an example. There's also a go tool >>> <https://github.com/WICG/webpackage/tree/main/go/bundle> that can build >>> and sign bundles, but it doesn't support integrity block v2 yet. Updating >>> the go version has been lower priority as we don't know of anyone that >>> actually used it. >>> >>> >>> Integrity block v2 was recently proposed to address key rotation related >>> issues with v1. The internal design doc is here: go/iwa-key-rotation >>> <https://goto.google.com/iwa-key-rotation>. Yes, we will be speccing >>> this. >>> >>> Great - any idea of when you might have some version of a spec draft >>> ready? >>> >>> >>> The engineer working on this estimates it being done in the next few >>> weeks. >>> >> >> An update to the Integrity Block explainer with the version 2 format >> landed in https://github.com/WICG/webpackage/pull/892. >> >> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5146307550248960 >>> >>> Links to previous Intent discussions >>> >>> Intent to prototype: https://groups.google.com/a/ch >>> romium.org/d/msgid/blink-dev/CAEmk%3DMayyUjocrvyQKgu-bZy_ >>> 4z5VJ0ijHCAijBTZY2xLwJpJQ%40mail.gmail.com >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit https://groups.google.com/a/ch >>> romium.org/d/msgid/blink-dev/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt% >>> 2BcKqM5otDfA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt%2BcKqM5otDfA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02549cbf-4750-4edd-8604-fccabecd52bc%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02549cbf-4750-4edd-8604-fccabecd52bc%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb42ff3d-776d-4feb-822b-9d651bdb30e3n%40chromium.org.
