Web Authentication's PublicKeyCredential signal methods

[nsatragno]

こんにちは TAG-さん!

I'm requesting a TAG review of Web Authentication's PublicKeyCredential signal methods.

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.

• Explainer¹: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer
• Specification: https://w3c.github.io/webauthn/#sctn-signal-methods
• WPT Tests:
  • https://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
• User research: N/A
• Security and Privacy self-review²: https://github.com/w3c/webauthn/wiki/Security-&-privacy-self-review:-PublicKeyCredential-signal-methods
• GitHub repo: https://github.com/w3c/webauthn/
• Primary contacts:
  • Nina Satragno (@nsatragno), Google, author
• Organization/project driving the specification: Google & the WebAuthn Working Group
• Multi-stakeholder support³:
  • Chromium comments: we would love to ship this thank you very much <3 -- signed: chromium
  • Mozilla comments: mozilla/standards-positions#1075
  • WebKit comments: WebKit/standards-positions#400
  • The signal methods address common concerns from RPs that have been voiced since the early days of WebAuthn. See w3c/webauthn#1967 and the issues linked from there, e.g. w3c/webauthn#1967 (comment)
• Status/issue trackers for implementations⁴: https://chromestatus.com/feature/5101778518147072

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: WebAuthn WG
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google

[maxpassion]

Hi @nsatragno - thanks for sending this our way. It would help us to review better if the explainer were more clear about the user need you're trying to service. You've described the problem statement and objective in low level terms but it's not clear the UX issue you're trying to tackle here. If you can describe start with user need, that would be helpful. It's good to see support from Webkit.

[jyasskin]

@maxpassion The explainer includes

1. If a relying party stops accepting a credential, e.g. as a result of revoking it from an account or by completely deleting an account, the credential is still presented by clients during discoverable flows.
2. Even if relying parties allow a user to change their username or display name on the account, such changes are not reflected in the display of credentials during discoverable flows.

Those seem like the high-level UX issues that this feature is designed to tackle?

[maxpassion]

Thanks for the clarification @jyasskin , the use case of not presenting invalid credentials to clients looks useful, and the API shape looks reasonable. We're also happy to see the widespread stakeholder support on w3c/webauthn#2093.