#996: Web Authentication's PublicKeyCredential signal methods

Visit on Github.

Opened Sep 19, 2024

こんにちは 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.

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

Discussions

Discussed Nov 1, 2024 (See Github)

Max: 2 comments - 1st one - looking at the explainer, although they have given some examples (examples section) it could be better to give examples from the real user experience perspective. 2nd comment - other stakeholders - webkit seems supportive but mozilla hasn't got back yet. Cross-browser is very important for this feature.

Dan: they're talking about credentials but not the user experience of using passkeys. The objective is very low level, user experience they're trying to service is unclear. We should ask for user needs.

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.

max to post

Discussed Nov 1, 2024 (See Github)

Max: there is an answer from Jeffrey... But no response from the requestor yet so we should wait.

Dan: OK I will bump.

Comment by @maxpassion Nov 13, 2024 (See Github)

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.

Comment by @jyasskin Nov 13, 2024 (See Github)

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