Intent to Ship: WebAuthn PRF extension

[Adam Langley]

Contact emails

a...@chromium.org

Explainer

https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension

Specification

https://w3c.github.io/webauthn/#prf-extension

Summary

The PRF extension to WebAuthn allows a pseudo-random function (i.e. HMAC), stored on the security key, to be evaluated when getting a credential. This can be used to derive secret keys used to encrypt user data.

Blink component

Blink>WebAuthentication

Search tags

webauthn, prf, hmac

TAG review

https://github.com/w3ctag/design-reviews/issues/806

TAG review status

Complete

Risks

Interoperability and Compatibility

Support on Windows depends on having a recent version of Windows. Not every security key supports the underlying hmac_secret functionality. Some passkey providers on Android 14 may not support it.

Gecko: No signal

WebKit: No signal

Web developers: We've had several requests to enable this. Hopefully some will reply to this thread in the coming week.

Security

Some platforms may have assumed that the web would not ever be able to access the HMAC oracles in security keys. Therefore the HMAC inputs are hashed with a context string before being used, thus preventing sites from evaluating any HMAC input from the native domain.

WebView application risks

WebAuthn is not currently supported in WebViews. If that changes, this feature isn't expected to cause any specific difficulties. It remains the case that apps need to be authorized by assetlinks.json to access WebAuthn credentials.

Debuggability

This feature is supported by Chromium's simulated security key and can be used by Web Driver tests and, later, could be exposed in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, although support for WebAuthn in WebViews in general is still in the future.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

chrome://flags/#enable-experimental-web-platform-features, although it'll have a separate killswitch flag when default enabled.

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1106961

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5138422207348736

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ

[Alex Russell]

This looks good on the surface, but I'm wondering if there's sample code somewhere that can demonstrate how this would be used?

--
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/CAL9PXLwSTfuePtL9d2BrF%2BPjXkipxY-f4TPCDMHpv5ESwqA1uQ%40mail.gmail.com.

[Rew Islam]

Dashlane would like to see support for this feature. This allows encryption of data without the need for a knowledge based secret, in an easy to use way.

Rew

On 1 May 2023, at 09:26, Alex Russell <sligh...@chromium.org> wrote:



You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/iTNOgLwD2bI/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA44PQhNjhx0jT5f2PZ-T-dG3JFQdh3Bjsb%3DkDSoxJ38bVXqSQ%40mail.gmail.com.

[Adam Langley]

On Mon, May 1, 2023 at 1:25 AM Alex Russell <sligh...@chromium.org> wrote:

This looks good on the surface, but I'm wondering if there's sample code somewhere that can demonstrate how this would be used?

Good point. I've added an example of basic usage to the explainer page: https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension

Cheers

AGL

[Nick Steele]

1 Password is also supportive of this extension being added. Being able to encrypt data alongside a credential would be useful to us and our users.

I'd like some clarification on the contextual string being provided for HMAC hashing. What is the expected context input being provided?

Thanks,

NS

[Adam Langley]

On Mon, May 1, 2023 at 12:47 PM Nick Steele <nick....@agilebits.com> wrote:

1 Password is also supportive of this extension being added. Being able to encrypt data alongside a credential would be useful to us and our users.

I'd like some clarification on the contextual string being provided for HMAC hashing. What is the expected context input being provided?

See https://w3c.github.io/webauthn/#prf-extension:

>  Let salt1 be the value of SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || eval.first).

So any applications with more direct access to security keys have to opt-into being compatible with the Web by picking salts with known pre-images via that function. Existing uses do not get abruptly exposed to the Web via this extension.

Cheers

AGL

[Nick Steele]

Got it, given the phrasing there was a concern that there could be a non-standard addition to the contextual string.
This works for us and we look forward to PRF landing in Chrome. 

-NS

[Caleb Raitto]

I think this was discussed before with mmenke@, but he's ooo: 

How does this feature work in cross-site iframes? What prevents the PRF from acting as a cross site identifier (are credentials usable in cross site iframes)?

Thanks,

-Caleb

[Adam Langley]

On Tue, May 2, 2023 at 8:31 AM Caleb Raitto <cara...@chromium.org> wrote:

I think this was discussed before with mmenke@, but he's ooo: 

How does this feature work in cross-site iframes? What prevents the PRF from acting as a cross site identifier (are credentials usable in cross site iframes)?

WebAuthn works in cross-site iframes if the parent frame explicitly permits it with Permissions Policy, thus the prf extension can work too. A PRF value could be used as a tracking vector, but that would be a bit obtuse because WebAuthn credentials themselves already have a large random ID. The cross-origin iframe would still be limited by the RP ID mechanism so that it could only attempt to assert credentials created within the same eTLD+1, however.

Fundamentally, as an authentication mechanism WebAuthn must be a method of identification. The balance is that WebAuthn requires a ceremony: browser UI plus authenticator activation (e.g. touching a security key). The PRF extension is part of a WebAuthn authentication and thus requires the same ceremony, it can never be triggered silently or anything like that.

Cheers

AGL

[Caleb Raitto]

Thanks, makes sense -- can a note about this be added to the privacy section of the explainer / spec? 

-Caleb

[Yoav Weiss]

On Sat, Apr 29, 2023 at 12:05 AM 'Adam Langley' via blink-dev <blin...@chromium.org> wrote:

Contact emails

a...@chromium.org

Explainer

https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension

Specification

https://w3c.github.io/webauthn/#prf-extension

Summary

The PRF extension to WebAuthn allows a pseudo-random function (i.e. HMAC), stored on the security key, to be evaluated when getting a credential. This can be used to derive secret keys used to encrypt user data.

Blink component

Blink>WebAuthentication

Search tags

webauthn, prf, hmac

TAG review

https://github.com/w3ctag/design-reviews/issues/806

TAG review status

Complete

Risks

Interoperability and Compatibility

Support on Windows depends on having a recent version of Windows. Not every security key supports the underlying hmac_secret functionality. Some passkey providers on Android 14 may not support it.

Gecko: No signal

WebKit: No signal

Have we asked? If not, can you file for positions according to https://bit.ly/blink-signals?

 

Web developers: We've had several requests to enable this. Hopefully some will reply to this thread in the coming week.

Security

Some platforms may have assumed that the web would not ever be able to access the HMAC oracles in security keys. Therefore the HMAC inputs are hashed with a context string before being used, thus preventing sites from evaluating any HMAC input from the native domain.

WebView application risks

WebAuthn is not currently supported in WebViews. If that changes, this feature isn't expected to cause any specific difficulties. It remains the case that apps need to be authorized by assetlinks.json to access WebAuthn credentials.

Debuggability

This feature is supported by Chromium's simulated security key and can be used by Web Driver tests and, later, could be exposed in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, although support for WebAuthn in WebViews in general is still in the future.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

chrome://flags/#enable-experimental-web-platform-features, although it'll have a separate killswitch flag when default enabled.

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1106961

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5138422207348736

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ

--

[Adam Langley]

On Tue, May 2, 2023 at 9:55 AM Caleb Raitto <cara...@chromium.org> wrote:

Thanks, makes sense -- can a note about this be added to the privacy section of the explainer / spec? 

I think the Privacy section covers that now. If you see gaps, please do let me know.

Cheers

AGL

[Adam Langley]

On Wed, May 3, 2023 at 4:07 AM Yoav Weiss <yoav...@chromium.org> wrote:

WebKit: No signal

Have we asked? If not, can you file for positions according to https://bit.ly/blink-signals?

I've spoke to Apple people directly, but happy to file a request too:

https://github.com/mozilla/standards-positions/issues/798

https://github.com/WebKit/standards-positions/issues/183

Cheers

AGL

[Caleb Raitto]

I was thinking we should have some language specifically about the cross-origin iframe case -- I didn't see that in the explainer or spec when I checked just now? Basically something like your previous response would be sufficient, I think?

Also, I wanted to clarify:

> The cross-origin iframe would still be limited by the RP ID mechanism so that it could only attempt to assert credentials created within the same eTLD+1, however.

IIUC, this means that the PRF value is more akin to a first party cookie than a third-party cookie?

Thanks, 

-Caleb

 

Cheers

AGL

[Morgaine (de la faye)]

Hello. I don't have any present use cases as a web developer here, but I'm very excited & thrilled to see this extension. Giving users ways to secure their data is a very significant win & this seems like a straightforward low-level capability to enable that. Thanks.

[Mike West]

LGTM1, with the suggestion that following up on Caleb's comments about the spec's privacy section would be appreciated.

-mike

On Fri, May 12, 2023 at 9:16 AM Morgaine (de la faye) <rek...@gmail.com> wrote:

Hello. I don't have any present use cases as a web developer here, but I'm very excited & thrilled to see this extension. Giving users ways to secure their data is a very significant win & this seems like a straightforward low-level capability to enable that. Thanks.

--

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/605d0dee-68a5-4b09-9483-23d6f887a4f4n%40chromium.org.

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdWHXvHoK2cfFP6dcZ6b-wnDv%3DyY4aeMa-b_4JcxoZpAw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/427228ad-4183-fbc6-7b77-ab3eac94cb79%40chromium.org.

[Hugo Dias]

Fission would love to see PRF extension shipped, we are tracking support here https://github.com/oddsdk/passkeys/issues/13.

[Adam Langley]

On Fri, May 5, 2023 at 11:00 AM Caleb Raitto <cara...@chromium.org> wrote:

On Thursday, May 4, 2023 at 6:11:17 PM UTC-4 Adam Langley wrote:

On Tue, May 2, 2023 at 9:55 AM Caleb Raitto <cara...@chromium.org> wrote:

Thanks, makes sense -- can a note about this be added to the privacy section of the explainer / spec? 

I think the Privacy section covers that now. If you see gaps, please do let me know.

I was thinking we should have some language specifically about the cross-origin iframe case -- I didn't see that in the explainer or spec when I checked just now? Basically something like your previous response would be sufficient, I think?

Ah, got it, thanks. I've edited the explainer to that effect.

Cheers

AGL 

[Caleb Raitto]

Looks good, thanks.

-Caleb

[Vivek Bhupatiraju]

Are there any updates on this Intent To Ship? I would also love this extension as it allows for an amazing UX for encryption.

[Adam Langley]

On Sat, Jul 22, 2023 at 2:15 PM Vivek Bhupatiraju <trifo...@gmail.com> wrote:

Are there any updates on this Intent To Ship? I would also love this extension as it allows for an amazing UX for encryption.

Default-enabled in Chrome M116, so you should be able to experiment with it on Beta channel ahead of the M116 release.

Cheers

AGL

 

[Vivek Bhupatiraju]

Amazing! When can we expect to see this in stable Chrome releases? And are there any updates on this feature in other browsers? 

[Mike Taylor]

This will hit stable in M116.

I don't see any movement on https://github.com/mozilla/standards-positions/issues/798 or https://github.com/WebKit/standards-positions/issues/183, but there may be bugs in their public trackers you can find and follow.

--

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/f188db04-9f77-45c3-b3d4-efea6acd6793n%40chromium.org.