Intent to Ship: WebAuthn: Large blob storage extension (largeBlob)

841 views
Skip to first unread message

Nina Satragno

unread,
Feb 22, 2023, 12:15:45 PM2/22/23
to blink-dev, identity-dev
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.

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. 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)


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.

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, which runs in a sandboxed process. This implementation feature was security-reviewed.

WebView application risks
None.

Debuggability
Developers can use the devtools webauthn tab 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. 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

Rick Byers

unread,
Feb 27, 2023, 6:14:47 PM2/27/23
to Nina Satragno, blink-dev, identity-dev
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

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. 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)


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?
--
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.

Nina Satragno

unread,
Mar 1, 2023, 2:35:29 PM3/1/23
to Rick Byers, blink-dev, identity-dev
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

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. 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)


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.

--

I filed bugs for the metrics and max size limiting I talked about as action items.

Hopefully this answers all your questions.
Cheers!


--
Nina Satragno
she/they

Alex Russell

unread,
Mar 2, 2023, 4:36:09 PM3/2/23
to blink-dev, Nina Satragno, blink-dev, identity-dev, Rick Byers
Thanks for the thorough follow-up; LGTM1

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.


--
Nina Satragno
she/they

Yoav Weiss

unread,
Mar 3, 2023, 7:57:33 AM3/3/23
to Alex Russell, blink-dev, Nina Satragno, identity-dev, Rick Byers
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


--
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/18ed2ade-e5d8-47be-8a09-5907048af8d4n%40chromium.org.

Rick Byers

unread,
Mar 3, 2023, 8:09:00 AM3/3/23
to Nina Satragno, blink-dev, identity-dev
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:

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.

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. 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)


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.

Nina Satragno

unread,
Mar 9, 2023, 1:53:42 PM3/9/23
to Rick Byers, blink-dev, identity-dev
For security keys, there is a minimum size 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 to clarify this (regrettably, the repository for CTAP is closed source).


--
Nina Satragno
she/they

polyset

unread,
Oct 13, 2023, 11:20:29 AM10/13/23
to blink-dev, nsat...@chromium.org, blink-dev, identity-dev, rby...@chromium.org
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

Carlos Cabada

unread,
Apr 9, 2024, 12:07:05 PMApr 9
to blink-dev, polyset, nsat...@chromium.org, blink-dev, identity-dev, rby...@chromium.org
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?
Reply all
Reply to author
Forward
0 new messages