- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Jul 2021 14:21:12 +0000
- To: public-webauthn@w3.org
Below is the our view on above proposal. This view is from RP, platform and platform authenticator perspective as we acts in all three categories. ### Background Most of the above proposal is after consultations between platforms/browser vendors on how to improve webauthn, go passwordless and address some pain points in adoption. There are important situations where there are disagreements and we have different viewpoints, but most of the places we have agreement. I will try to go through each point and hopefully explain those points in more detail. Overall point is we want RPs to go passwordless while addressing their various levels of security needs. Hopefully these are steps in right direction and we encourage RPs to present their view points in this issue especially if they disagree with the direction. ### Section: Possible experiences in a future WebAuthn #### At-Scale Adoption For wider at-scale adoption in relatively quick time, we have to meet where user is. And that is phone/PC/Tablets as of today. Most of them don't have security keys as of now. While security keys adoption will grow and we stand behind it's security properties and have plans to further enhance it's security, we also realize that it will take time. In the meanwhile, we want to move hopefully quickly and solve platforms experience for a user. Hence, most of the discussion below is about platform authenticators here. In situations where a user wants to have more security, security keys is the best we have. We also hope that security keys will be fully supported in all the platforms like we support them on Windows, especially resident/discoverable credentials support for full passwordless. #### Goals - Go passwordless with only unphishable credentials. - Remove password from the RP's server. - Support RP's security needs - Support User's usability needs #### Syncing Keys, Recoverability and Security This requires it's own topic. Hence I opened a new issue around it. See #1640. #### Overall flow may be something like this. - User creates a credential on the phone via either on the browser/app on the phone or via caBLE on desktop. - First time on a new desktop, user will login with phone via cable. - Transport will be not be "internal" for above GetAssertion response. - If IUVPAA is true, then RP suggests creating platform authenticator on the device. - When user chooses to register a credential, appropriate options as below mentioned will be passed to create a credential. - If response is either InvalidStateError or a MakeCredential, a platform authenticator credential exists on the device and RP stores a local state that a platform credential exists for that user. - Whenever authenticating for a known user, get all the credentials from the server and passes that info to the getAssertion. ### Section: Conditional UI Conditional UI is a proposal to solve problem where RP does not know whether that device/or a near by device has a credential for that RP. It happens when cookie gets cleared. or you are not a new desktop and may be you have paired your phone with that desktop. We support this idea. #### Discoverable vs Non-Discoverable credentials Important point for above conditional UI is credential has to be discoverable. Hence, any RP who wants to leverage these features must create discoverable credentials. ### Section: Assertion Transports We support this idea. It helps RP decide on whether it wants to show registration flow when there does not exist a local platform credential. ### Section: Preventing unintended credential overwrites We definitely support this idea because a authenticator only supports one discoverable credential for a given (RP, UserID) pair. And if RP does not pass all the credentials, existing credentials get's overwritten, which creates problems between various browsers on the same machine. Hence, always pass all the credentials in exclude list. UI will be similar between creating a new credential or telling RP that a credential already exists. ### Section: Reauthentication We are OK with the proposal however, Rp should not prompt this too frequently without the need. Just only when you really have to, say for payments, RP should follow this pattern. ### Section: Upgrading to WebAuthn We support this idea. ### Section: Durable signal We support this idea. Durable signal is useful to see whether the credential is going to be available even after device loss and will help RP in probably dropping the password from its database. There are other ways RP can offer dropping passwords from its database. For example, if a user has multiple security keys enrolled for the website. Logic to offer password dropping will evolve over time and this durable signal seems like is needed for that determination. ### Section: Credential management We think that it makes sense. Platforms should be providing ways for managing credentials on their respective platforms. We, on Windows side are already working on this. ### Section: Report signaling Not sure at the moment. We get back on here after more thinking. Overall these are corner cases which we need to pay attention to at some point. -- GitHub Notification of comment by akshayku Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1637#issuecomment-874804170 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 July 2021 14:21:14 UTC