- From: Matthew Miller via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jan 2023 00:49:04 +0000
- To: public-webauthn@w3.org
To add some more data to this conversation, I did some experimentation today with Android's "opt-in" model for RP's to leverage passkeys in Google's ecosystem. I'm adding `"preferred"` here to the table above because it highlights further the need for such a "`preferred-if-unlimited`" option for `"residentKey"` option:
```
┌────────────────────┬────────────────────┬────────────────────┐
│ Roaming │ Platform │ Platform │
│ Authenticator │ Authenticator │ Authenticator │
│ (Yubikey) │(Android Behaviour) │ (iOS Behaviour) │
└────────────────────┴────────────────────┴────────────────────┘
┌────────────────────┐ ┌────────────────────┬────────────────────┬────────────────────┐
│ │ │ │ │ │
│ rk=discouraged │ │ RK false │ RK false (!1) │ RK true │
│ │ │ │ │ │
├────────────────────┤ ├────────────────────┼────────────────────┼────────────────────┤
│ │ │ │ │ │
│ rk=preferred │ │ RK true (!2) │ RK true │ RK true │
│ │ │ │ │ │
├────────────────────┤ ├────────────────────┼────────────────────┼────────────────────┤
│ │ │ │ │ │
│ rk=required │ │ RK true (!2) │ RK true │ RK true │
│ │ │ │ │ │
├────────────────────┤ ├────────────────────┼────────────────────┼────────────────────┤
│ rk=prefer-if- │ │ │ │ │
│ unlimited │ │ RK false │ RK true │ RK true │
│ │ │ │ │ │
└────────────────────┘ └────────────────────┴────────────────────┴────────────────────┘
```
On Android, `"residentKey": "preferred"` will also create a `be:1` credential (due to a lack of support for `credProps` extension on Android we can probably interpret this to mean that Android creates a discoverable credential, and it shows the same, new "passkeys" UI flow as `"residentKey": "required"` compared to the "old" UI that appears when you specify `"residentKey": "discouraged"`)
And I observed today that some newer YubiKeys (like a YubiKey 5 Bio) choose to create a discoverable credential when they encounter `"preferred"` too (confirmed via `{ credProps: { rk: true } }` in client extension results)
For some context, I was coming at this from a library maintainer's perspective trying to determine a good **passwordless** default for registration options. Passwordless UX is arguably more permissive about which WebAuthn credentials are suitable for such use cases, compared to strictly **passkey**-focused use cases. It would have been convenient for security keys to choose _not_ to create discoverable credentials when encountering `"preferred"` but alas, we do not live in that world.
> Closing, as WG agreed on 30 Nov call that giving this option to RPs would not solve the problem.
@sbweeden Do you or anyone else remember what we landed on for why this wouldn't work for RP's?
--
GitHub Notification of comment by MasterKale
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1370371471 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:49:06 UTC