Would it be possible to show the uncompressed data in the modal before a read or write returns?
There are a few reasons for this: 1) I want to know what the window is storing on my credential 2) this opens up development use cases not yet available On Thursday, March 9, 2023 at 2:53:42 PM UTC-4 [email protected] wrote: > On Fri, Mar 3, 2023 at 8:08 AM Rick Byers <[email protected]> wrote: > >> 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. >> > > 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 [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 >>> >> > > -- > 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/0f8b054b-b650-4783-b686-f2bc37a366f5n%40chromium.org.
