- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jan 2023 00:08:51 +0000
- To: public-webauthn@w3.org
I think we may need to re-open this @emlun and @sbweeden . After talking to @MasterKale we believe that some android devices when rk=discouraged is set in make credential are respecting that and not creating a resident key.
Where this issue becomes important is that with developers and wg members pushing for discoverable/resident "passkeys" the issue is security keys like yubikeys have finite storage, and many ctap2.0 keys lack credential management. This means that if developers follow guides that state rk=required, they will consume space on those devices. It is not possible for "passkeys" to filter by attachement=platform since hybrid transport exists allowing a platform authenticator to be used over caBLE. This means RP's have to allow both roaming and platform, which means security keys can and will always be possible to use in locations where a developer/RP may have assumed only a phone/platform authenticator would be used.
To assemble the problems in an easier to see way:
```
┌────────────────────┬────────────────────┬────────────────────┐
│ Roaming │ Platform │ Platform │
│ Authenticator │ Authenticator │ Authenticator │
│ (Yubikey) │(Android Behaviour) │ (iOS Behaviour) │
└────────────────────┴────────────────────┴────────────────────┘
┌────────────────────┐ ┌────────────────────┬────────────────────┬────────────────────┐
│ │ │ │ │ │
│ rk=discouraged │ │ RK false │ RK false (!1) │ RK true │
│ │ │ │ │ │
├────────────────────┤ ├────────────────────┼────────────────────┼────────────────────┤
│ │ │ │ │ │
│ rk=required │ │ RK true (!2) │ RK true │ RK true │
│ │ │ │ │ │
├────────────────────┤ ├────────────────────┼────────────────────┼────────────────────┤
│ rk=prefer-if- │ │ │ │ │
│ unlimited │ │ RK false │ RK true │ RK true │
│ │ │ │ │ │
└────────────────────┘ └────────────────────┴────────────────────┴────────────────────┘
```
Currently the controls we have as an RP aren't able to satisfy everyones needs.
Point (!1). If an RP signals RK=discouraged, then yubikeys will work (making a non resident key, and not consuming space), and iOS will work, always forcing RK=true allowing opportunistic discoverability. However, it seems like Android may not make an RK in this case, which means they will not get the same experience.
Point (!2). If an RP signals RK=required then android will create the discoverable credential, as will iOS. However, security keys will also create a resident key, sometimes with very finite space (32 slots on a yubikey) or on devices that don't have credential management (meaning a full device wipe and reset to delete any RK.). This is an awful user experience, and this WG has stated that the goal is any user should be able to use any authenticator.
I think we may need the third option of RK=preferred-if-unlimited. This allows security keys to make non-resident keys, while also signalling to devices like android that they should create an RK since they are able to support unlimited credentials.
Today however, the choice to use rk=discouraged is still preferred since potentially consuming (at worst destroying and blocking users ability to use security keys) is the greater harm to user experience, where for devices that don't make discoverable credentials they simply need to add a username field (that is already required for conditional UI anyway. ).
--
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1370348423 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 January 2023 00:08:53 UTC