On Fri, Mar 3, 2023 at 8:08 AM Rick Byers <rby...@chromium.org> wrote:
> LGTM3 > > On Wed, Mar 1, 2023 at 7:35 PM Nina Satragno <nsatra...@chromium.org> > wrote: > >> Hey Rick! >> >> On Mon, Feb 27, 2023 at 6:14 PM Rick Byers <rby...@chromium.org> wrote: >> >>> Hi Nina, >>> Seems pretty solid to me, just a few questions inline. >>> >>> On Wed, Feb 22, 2023 at 5:15 PM Nina Satragno <nsatra...@chromium.org> >>> wrote: >>> >>>> *Contact emails* >>>> nsatra...@chromium.org, identity-...@chromium.org >>>> >>>> *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. > For security keys, there is a minimum size <https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#getinfo-maxserializedlargeblobarray> specified that implies the availability of at least 1kb of dedicated space, but there is technically nothing stopping authenticators from sharing space outside that minimum. I don't think this will be a problem in practice, but I have opened an issue against CTAP <https://github.com/fido-alliance/fido-2-specs/issues/1377> to clarify this (regrettably, the repository for CTAP is closed source). > > 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 blink-dev+unsubscr...@chromium.org. >>>> 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 >> > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0jiomTypMiGkbtFHf98zrLN60XCdX28kO1cCYr-_ox6Fn%2BgQ%40mail.gmail.com.
