Intent to Ship: WebAuthn signal API
Nina Satragno
Contact emails
nsat...@chromium.org, identi...@chromium.orgExplainer
https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainerSpecification
https://pr-preview.s3.amazonaws.com/nsatragno/webauthn/pull/2093.html#sctn-signal-methodsSummary
Allow WebAuthn relying parties to report information about existing credentials back to credential storage providers, so that incorrect or revoked credentials can be updated or removed from provider and system UI. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer
Blink component
Blink>WebAuthenticationTAG review
https://github.com/w3ctag/design-reviews/issues/996TAG review status
PendingRisks
Interoperability and Compatibility
None, this is a new API.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1075). I'll update here once that changes.
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/400). I'll update here once that changes.
Web developers: Positive (https://github.com/w3c/webauthn/issues/1967#issuecomment-1848433321) The signal methods address common concerns from RPs that have been voiced since the early days of WebAuthn. See https://github.com/w3c/webauthn/issues/1967 and the issues linked from there.
Other signals:
Ergonomics
Omitting a valid credential ID from `signalAllAcceptedCredentials` can result in the user no longer being able to sign in with that passkey. This is explicitly called out in the spec [1]. The spec recommends that authenticators hide (instead of removing) passkeys to mitigate this issue. Chrome will ship a first version that removes credentials, and a follow-up will hide them instead. This is because removing credentials requires a lot less coordination from multiple products than hiding them, and lets us ship and iterate on the API faster. [1] https://w3c.github.io/webauthn/#sctn-signalAllAcceptedCredentials
Security
Relying parties can only update or remove credentials that are bound to their relying party ID.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A, this is a new API.
Debuggability
Chrome supports signal* methods through the WebAuthn devtools panel [1]. signal* methods are also supported through webdriver's WebAuthn API [2], with a small change in the works [3] specifically to be able to debug `signalCurrentUserDetails`. [1] https://developer.chrome.com/docs/devtools/webauthn [2] https://w3c.github.io/webauthn/#sctn-automation [3] https://github.com/w3c/webauthn/pull/2148
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
NoInitially, this feature will be supported on Chrome desktop only, and on Chrome only for Google Password Manager (GPM) credentials. Support for iCloud keychain and Windows Hello will depend on macOS and Windows updates respectively. Android support requires an update to the Android Credential Manager API that is being worked on. For GPM credentials, we also need to update Google Play Services accordingly. Once the Android Credential Manager API is launched, other credential providers will be able to hook to the API.
Is this feature fully tested by web-platform-tests?
Yeshttps://wpt.fyi/results/webauthn/signal-all-accepted-credentials.https.html https://wpt.fyi/results/webauthn/signal-current-user-details.https.html https://wpt.fyi/results/webauthn/signal-unknown-credential.https.html
DevTrial instructions
https://github.com/w3c/webauthn/wiki/Experimenting-with-the-Signal-API-on-ChromeFlag name on chrome://flags
chrome://flags#enable-experimental-web-platform-featuresFinch feature name
CredentialManagerReportRequires code in //chrome?
TrueTracking bug
https://crbug.com/361751877Measurement
https://chromestatus.com/metrics/feature/timeline/popularity/5104 https://chromestatus.com/metrics/feature/timeline/popularity/5105 https://chromestatus.com/metrics/feature/timeline/popularity/5106Availability expectation
We expect this feature to be generally available on desktop for M131. Android will follow after.Adoption expectation
The feature can be adopted right away, as while the functionality provided significantly improves the UX of WebAuthn, it's provided as a "best-effort" and can safely be unimplemented.Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
* Android Credential Manager for Android support * Apple's browser passkey APIs for macOS and iOS support. * Windows webauthn.dll for Windows Hello credentials.Sample links
https://signal-api-demo.glitch.me
Estimated milestones
| DevTrial on desktop | 130 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No changes.Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5101778518147072?gate=5111131065286656
Alex Russell
- The TAG review is new, and I strongly suspect that there will be feedback on the API naming and consistency here
- The Explainer is incomplete. I don't see end-to-end code samples outlining how this feature solves a problem that was tricky to work around before (i.e, the before vs. after state), or considered alternatives to this design, or even considered alternatives to this choice of naming. Explicit non-goals are also conspicuous by their absence.
Tim Cappalli
Hey Nina,This is an exciting feature! The API OWNERS decided to let this Intent ride this week for a couple of reasons:
- The TAG review is new, and I strongly suspect that there will be feedback on the API naming and consistency here
- The Explainer is incomplete. I don't see end-to-end code samples outlining how this feature solves a problem that was tricky to work around before (i.e, the before vs. after state), or considered alternatives to this design, or even considered alternatives to this choice of naming. Explicit non-goals are also conspicuous by their absence.
Our top-line goal at I2S stage is to judge if a proposal is solving an important problem well. Having an RP weigh in last year is helpful, but doesn't seem to speak to this specific design. Is there more signal from developers that this is the right API?Thanks,Alex
On Friday, September 20, 2024 at 9:09:55 AM UTC-7 Nina Satragno wrote:
--
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/cc140654-60b8-4102-9b9f-1ae970073de2n%40chromium.org.
Alex Russell
Yoav Weiss (@Shopify)
Amazing; thanks for letting us know!
On Thu, Sep 26, 2024 at 10:22 AM Tim Cappalli <tim.ca...@okta.com> wrote:
Okta, a very large WebAuthn Relying Party, is excited about this feature. It addresses one of the top complaints we hear about passkeys which is "orphaned passkeys" in authenticators when they are deleted from the user account at the RP.tim
On Wed, Sep 25, 2024 at 2:26 PM Alex Russell <sligh...@chromium.org> wrote:
Hey Nina,This is an exciting feature! The API OWNERS decided to let this Intent ride this week for a couple of reasons:
- The TAG review is new, and I strongly suspect that there will be feedback on the API naming and consistency here
- The Explainer is incomplete. I don't see end-to-end code samples outlining how this feature solves a problem that was tricky to work around before (i.e, the before vs. after state), or considered alternatives to this design, or even considered alternatives to this choice of naming. Explicit non-goals are also conspicuous by their absence.
Our top-line goal at I2S stage is to judge if a proposal is solving an important problem well. Having an RP weigh in last year is helpful, but doesn't seem to speak to this specific design. Is there more signal from developers that this is the right API?Thanks,Alex
On Friday, September 20, 2024 at 9:09:55 AM UTC-7 Nina Satragno wrote:
SummaryAllow WebAuthn relying parties to report information about existing credentials back to credential storage providers, so that incorrect or revoked credentials can be updated or removed from provider and system UI. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer
Blink componentBlink>WebAuthentication
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/996
TAG review statusPending
Risks
Interoperability and CompatibilityNone, this is a new API.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1075). I'll update here once that changes.
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/400). I'll update here once that changes.
Web developers: Positive (https://github.com/w3c/webauthn/issues/1967#issuecomment-1848433321) The signal methods address common concerns from RPs that have been voiced since the early days of WebAuthn. See https://github.com/w3c/webauthn/issues/1967 and the issues linked from there.
Other signals:
ErgonomicsOmitting a valid credential ID from `signalAllAcceptedCredentials` can result in the user no longer being able to sign in with that passkey. This is explicitly called out in the spec [1]. The spec recommends that authenticators hide (instead of removing) passkeys to mitigate this issue. Chrome will ship a first version that removes credentials, and a follow-up will hide them instead. This is because removing credentials requires a lot less coordination from multiple products than hiding them, and lets us ship and iterate on the API faster. [1] https://w3c.github.io/webauthn/#sctn-signalAllAcceptedCredentials
SecurityRelying parties can only update or remove credentials that are bound to their relying party ID.
WebView application risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A, this is a new API.
DebuggabilityChrome supports signal* methods through the WebAuthn devtools panel [1]. signal* methods are also supported through webdriver's WebAuthn API [2], with a small change in the works [3] specifically to be able to debug `signalCurrentUserDetails`. [1] https://developer.chrome.com/docs/devtools/webauthn [2] https://w3c.github.io/webauthn/#sctn-automation [3] https://github.com/w3c/webauthn/pull/2148
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?NoInitially, this feature will be supported on Chrome desktop only, and on Chrome only for Google Password Manager (GPM) credentials. Support for iCloud keychain and Windows Hello will depend on macOS and Windows updates respectively. Android support requires an update to the Android Credential Manager API that is being worked on. For GPM credentials, we also need to update Google Play Services accordingly. Once the Android Credential Manager API is launched, other credential providers will be able to hook to the API.
Is this feature fully tested by web-platform-tests?Yeshttps://wpt.fyi/results/webauthn/signal-all-accepted-credentials.https.html https://wpt.fyi/results/webauthn/signal-current-user-details.https.html https://wpt.fyi/results/webauthn/signal-unknown-credential.https.html
DevTrial instructionshttps://github.com/w3c/webauthn/wiki/Experimenting-with-the-Signal-API-on-Chrome
Flag name on chrome://flagschrome://flags#enable-experimental-web-platform-features
Finch feature nameCredentialManagerReport
Requires code in //chrome?True
Tracking bughttps://crbug.com/361751877
Measurementhttps://chromestatus.com/metrics/feature/timeline/popularity/5104 https://chromestatus.com/metrics/feature/timeline/popularity/5105 https://chromestatus.com/metrics/feature/timeline/popularity/5106
Availability expectationWe expect this feature to be generally available on desktop for M131. Android will follow after.
Adoption expectationThe feature can be adopted right away, as while the functionality provided significantly improves the UX of WebAuthn, it's provided as a "best-effort" and can safely be unimplemented.
Non-OSS dependenciesDoes the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
* Android Credential Manager for Android support * Apple's browser passkey APIs for macOS and iOS support. * Windows webauthn.dll for Windows Hello credentials.
Sample links
https://signal-api-demo.glitch.me
Estimated milestonesDevTrial on desktop130
Anticipated spec changesOpen questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No changes.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5101778518147072?gate=5111131065286656
--
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+unsubscribe@chromium.org.
Nina Satragno
On Thursday, September 26, 2024 at 10:26:35 PM UTC+2 Alex Russell wrote:Amazing; thanks for letting us know!On Thu, Sep 26, 2024 at 10:22 AM Tim Cappalli <tim.ca...@okta.com> wrote:Okta, a very large WebAuthn Relying Party, is excited about this feature. It addresses one of the top complaints we hear about passkeys which is "orphaned passkeys" in authenticators when they are deleted from the user account at the RP.timOn Wed, Sep 25, 2024 at 2:26 PM Alex Russell <sligh...@chromium.org> wrote:Hey Nina,This is an exciting feature! The API OWNERS decided to let this Intent ride this week for a couple of reasons:
- The TAG review is new, and I strongly suspect that there will be feedback on the API naming and consistency here
- The Explainer is incomplete. I don't see end-to-end code samples outlining how this feature solves a problem that was tricky to work around before (i.e, the before vs. after state), or considered alternatives to this design, or even considered alternatives to this choice of naming. Explicit non-goals are also conspicuous by their absence.
Joel Antoci
Domenic Denicola
Alex Russell
LGTM1
On Saturday, September 21, 2024 at 1:09:55 AM UTC+9 Nina Satragno wrote:
--
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/e4f40ad6-8ee2-4822-a658-3aba5d3487a2n%40chromium.org.
Yoav Weiss (@Shopify)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQhynTnP1tbOQw5_c%2BiaV8c7etBiS%2Bmbkmru4PLWfard8A%40mail.gmail.com.