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.
Blink component
Blink>WebAuthentication
Search tags
webauthn, large blob, blobs
Interoperability and Compatibility
Low. This feature has long been part of the WebAuthn L2 recommended standard. 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)
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.
--
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.
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: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.
Do you know of any specific RPs who are looking to deploy such features? What value does it bring them or their users?
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
Interoperability and Compatibility
Low. This feature has long been part of the WebAuthn L2 recommended standard. 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?
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?
Is there any sort of space reclamation protocol for unused credentials? Do we expose the space used per RP in our user UI?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.
--Nina Satragnoshe/they
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.
----Nina Satragnoshe/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/18ed2ade-e5d8-47be-8a09-5907048af8d4n%40chromium.org.
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: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 section with two I could conjure: offline SSH authentication in the context of SSO, and E2E messaging.
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.
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
Interoperability and Compatibility
Low. This feature has long been part of the WebAuthn L2 recommended standard. 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).
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.
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.