Hello, What would it mean to have support of Large Blob in Android devices?
> Play Services does not support CTAP 2.1, which is required for this feature Is this the only constraint? Do Android devices in general have support of CTAP 2.1? El viernes, 13 de octubre de 2023 a las 9:20:29 UTC-6, polyset escribió: > 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 nsat...@chromium.org wrote: > >> 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 <nsat...@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 <nsat...@chromium.org> >>>>> wrote: >>>>> >>>>>> *Contact emails* >>>>>> nsat...@chromium.org, identi...@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+...@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/0bb7a99d-b9d3-4355-8164-9035e48970ddn%40chromium.org.
