LGTM3 On Wed, Mar 1, 2023 at 7:35 PM Nina Satragno <[email protected]> wrote:
> Hey Rick! > > On Mon, Feb 27, 2023 at 6:14 PM Rick Byers <[email protected]> wrote: > >> Hi Nina, >> Seems pretty solid to me, just a few questions inline. >> >> On Wed, Feb 22, 2023 at 5:15 PM Nina Satragno <[email protected]> >> wrote: >> >>> *Contact emails* >>> [email protected], [email protected] >>> >>> *Explainer* >>> >>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Large-Blob-Extension >>> >> >> *Specification* >>> https://www.w3.org/TR/webauthn-2/#sctn-large-blob-extension >>> >>> *Summary* >>> The WebAuthn large blob extension allows relying parties to store opaque >>> data associated with a credential. This is useful for authentication >>> schemes involving storing certificates on authenticators. >>> >> >> Sorry if it should be obvious, but can you say a little more about >> the utility? How are such certificates expected to be used? The explainer >> doesn't describe the developer/user benefits of this feature. >> > > It's not obvious at all! I added an example use cases > <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Large-Blob-Extension#example-use-cases> > section > with two I could conjure: offline SSH authentication in the context of SSO, > and E2E messaging. > Makes sense, thank you! > > >> Do you know of any specific RPs who are looking to deploy such features? >> What value does it bring them or their users? >> >> > During the prototype period, we had a handful of developers reach out to > ask for availability & file bugs (e.g. crbug.com/1282491, > crbug.com/1312802, crbug.com/1312788). We also had a couple large RPs > express interest privately. > Perfect, thanks. > When we're the first engine to ship, the API owners are tasked with making >> an risk vs. moving the web forward tradeoff evaluation and it's not clear >> to me from the explainer exactly how this "moves the web forward". Maybe >> worth adding a few sentences to the explainer? >> >> *Blink component* >>> Blink>WebAuthentication >>> >>> *Search tags* >>> webauthn, large blob, blobs >>> >>> *TAG review* >>> https://github.com/w3ctag/design-reviews/issues/820 >>> >>> *TAG review status* >>> Pending >>> >>> *Risks* >>> >>> *Interoperability and Compatibility* >>> Low. This feature has long been part of the WebAuthn L2 recommended >>> standard <https://www.w3.org/TR/webauthn-2/#sctn-large-blob-extension>. >>> It is supported by production CTAP 2.1 security keys as well as recent >>> enough versions of the Windows WebAuthn API. >>> >>> Gecko: No signal ( >>> https://github.com/mozilla/standards-positions/issues/750) >>> >>> >>> WebKit: No signal ( >>> https://github.com/WebKit/standards-positions/issues/139) >>> >> >> Looks like that's in-development now (though Ricky does say they want to >> study the privacy and security properties a little more). >> >> Web developers: Positive. We had a few developers reach out about >>> availability, e.g. crbug.com/1282491. >>> >>> Other signals: Microsoft has shipped the OS-level large blob API, see >>> https://github.com/microsoft/webauthn/blob/master/webauthn.h >>> >>> *Ergonomics* >>> WebAuthn is already an asynchronous API with a "long" time to get a >>> response (in the order of seconds) since it needs user interaction. Adding >>> this feature will not impact the "normal" webauthn flow. For relying >>> parties (i.e. websites) using it, it won't significantly affect performance. >>> >> >> Can you say a little bit about storage limits? This is to be stored on >> the authenticator itself, right? Is there a max size per credential or RP? >> > > We are limiting the pre-compression size of each blob to 2kb. > > The storage capacity depends on the authenticator. Phones will essentially > have "unlimited" storage, while security keys will have comparatively > little. The key I have on my desk reports a max size of 1kb > (post-compression). The way we've seen this storage implemented in security > keys is as a shared space for all RPs that is dedicated to large blobs (so > filling it does not stop the creation of new resident credentials). > Nice. Is this detail of the space being reserved for large blobs (and to breaking only other large blobs when exhausted) something worth covering in the "SHOULD" clause in the spec? I don't have a strong opinion, just trying to reduce the risk of this feature leading to any perception of unreliability of passkeys generally. There are a lot more phones out there than security keys out there. > > >> To what extent should we worry about one RP taking up all the space and >> breaking functionality of other RPs? Are there any mechanisms to >> minimize this, or at least for us to monitor whether this is a problem in >> practice, and if so which origins are the biggest users? >> > > If a website tries to write a large blob when the storage is full, Chrome > will report the failure to write back to the relying party which can handle > this error. > > Users can go to chrome settings (chrome://settings/securityKeys) to manage > the storage for their security keys. Deleting a credential will remove its > accompanying large blob. Additionally, visiting the settings page for a > security key will trigger a "garbage collection" for the edge case where a > user might have deleted a credential using a tool that does not know about > large blobs, which would otherwise leave an orphaned blob. > > I'll go ahead and add a histogram to the large blob operation result so we > can measure failure conditions (like the storage being full). However, I'm > not sure if there would be a lot of value in adding RP-keyed metrics. Using > the full storage doesn't necessarily mean they're abusing the API. Perhaps > we can revisit if we see high numbers of failures due to the storage being > full. > SGTM > > >> Is there any sort of space reclamation protocol for unused credentials? >> Do we expose the space used per RP in our user UI? >> >> > We don't show the space used per RP. This might be somewhat tricky to > communicate, as we would know the post-compression space, which is not what > the RPs see. My recommendation here is to wait and see if this becomes a > problem first, and if it does, augment this UI surface. > Agreed, thanks. > > -- > > I filed bugs for the metrics > <https://bugs.chromium.org/p/chromium/issues/detail?id=1420691> and max > size limiting > <https://bugs.chromium.org/p/chromium/issues/detail?id=1420688> I talked > about as action items. > > Hopefully this answers all your questions. > Cheers! > > >> *Activation* >>> This feature can't be polyfilled since it relies on hardware support. >>> Large blob is a fairly simple feature, only exposing a way to query for >>> support, write, and read blobs. Integration with existing frameworks >>> exercising webauthn should be straightforward. >>> >>> *Security* >>> The implementation requires compressing and uncompressing arbitrary >>> data. This is done in the data decoder service >>> <https://source.chromium.org/chromium/chromium/src/+/master:services/data_decoder/gzipper.h>, >>> which runs in a sandboxed process. This implementation feature was >>> security-reviewed >>> <https://chromium-review.googlesource.com/c/chromium/src/+/2464011>. >>> >>> *WebView application risks* >>> None. >>> >>> *Debuggability* >>> Developers can use the devtools webauthn tab >>> <https://developers.google.com/web/tools/chrome-devtools/webauthn> to >>> debug this feature. Support can be toggled on or off to simulate >>> authenticator capabilities. >>> >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)?* >>> No. >>> >>> This feature will be supported on Mac, Linux, Windows (< 10 19h1; >= >>> 11), & Chrome OS. Windows >= 10 19h1 relies on a high-level API. Support on >>> that high level API landed on Windows 11. Similarly, the android webauthn >>> implementation relies on a higher level API that does not support this >>> feature. >>> >>> *Is this feature fully tested by web-platform-tests?* >>> Yes. https://wpt.fyi/webauthn, see large-blob >>> >>> *Flag name* >>> enable-experimental-web-platform-features >>> >>> *Requires code in //chrome?* >>> No. >>> >>> *Tracking bug* >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1114875 >>> >>> *Measurement* >>> None. >>> >>> *Non-OSS dependencies* >>> On Windows, for security keys the API depends on a version >= 3 of the >>> WebAuthn >>> API <https://github.com/microsoft/webauthn/blob/master/webauthn.h>. >>> This is currently present on recent enough versions of Windows 11. On >>> Android, for security keys the API depends on the Google Play Services >>> implementation of FIDO. At the moment, Play Services does not support CTAP >>> 2.1, which is required for this feature. On Mac & Linux, support for >>> security keys is provided by Chrome. On all desktop platforms, support for >>> hybrid (i.e. phone/tablet) authenticators does not depend on the OS. >>> >>> *Sample links* >>> https://webauthn-large-blob.glitch.me >>> >>> *Estimated milestones* >>> M113 >>> >>> *Anticipated spec changes* >>> None. >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5657899357437952 >>> >>> *Links to previous Intent discussions* >>> Intent to prototype: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ >>> >>> -- >>> Nina Satragno >>> she/they >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0jio%3DVeazm9pRoLcLm62XhHZEdPmBMoOFEwatDukkijXSmhQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0jio%3DVeazm9pRoLcLm62XhHZEdPmBMoOFEwatDukkijXSmhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > Nina Satragno > she/they > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9-yqW%3DF5Nr6JjNCDiiGp3ceLs2vcMGRKX2hyE0FU-dSw%40mail.gmail.com.
