- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jan 2022 21:26:07 +0000
- To: public-webauthn@w3.org
> How will this be avoided? How can the WebAuthN spec help solve? The relying parties will use attestations, gathered at credential registration time, to make a decision on whether or not to accept an authenticator. If an authenticator is implemented in a way their policy cannot accept, such as having an authenticator defined to use cloud hosting and synchronization rather than encrypted flash storage, the relying party will tell the user to register a different authenticator, possibly providing a list or instructions on how to get a supported cross-platform hardware fob. If the authenticator might meet policy if certain extensions were used, like devicePubKey, the relying party will have to decide if they are willing to do the implementation work of supporting those extensions. An implementation of devicePubKey arguably requires a risk-aware authentication system and authentication flows. If an existing software authenticator changes their implementation such that it starts issuing credentials that the policy will not accept, the relying party will stop accepting credentials from that authenticator and potentially revoke existing ones, telling users that they must use another form of authentication or go through account recovery. I imagine most would say that this would be a very poor business decision from an authenticator vendor. For the 90%+ of relying parties that don't care, don't have acceptable authenticator policy, and don't ask for attestations, they will do absolutely nothing. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1018876008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 January 2022 21:26:09 UTC