Use the same UVPA with discoverable credential support (e.g. Touch ID or Windows Hello) for all the following
steps:
Step #
Action
Expected
Actual
Matches Expected
Details
1.
Simulate an old security key registration
2.
3.
Attempt to register as discoverable passkey
4.
Upgrade security key registration to discoverable passkey
5.
6.
Verify discoverable passkey registration
7.
8.
This journey simulates the following situation:
An RP has historically supported "security keys", and a user has registered a platform authenticator
as
security key (steps 2-3).
The RP has added discoverable passkey functionality.
The user is now registering the same platform authenticator as a discoverable passkey, and the RP needs to
make
sure that this doesn't silently break
the security key registration (steps 4-6).
If the RP did not take care, most major browsers would overwrite the security
key
registration with the passkey registration, but there would be no way to tell. The
user could plausibly think "I can remove
this passkey
registration, it's still registered as a security key", only to find that the security key registration
is
no
longer possible to use at all.
Informally, the RP is "upgrading" is platform authenticator from a security key registration (UVPA/RK
status
potentially unknown) to a discoverable passkey registration in step 6.
Note that this particular flow still has a flaw: there is no guarantee to the RP that that the device
identified in step 5 is the same one registered in step 6. This is not an issue in practice, so long as device
supports at most platform authenticator. However, it would be nice to address this issue while also improving
the UX of this flow, by consolidating steps 4-6.