What is the proper Passkey Discoverable Credentials flow?

[justincrosbie]

Hi, apologies, newbie question. I'm not clear on what the flow is for discoverable credentials with Passkeys.

1. Does the registration need to return a challenge with requireResidentKey set to true, and if so, how can that be done, since start_passkey_registration has it false always?
2. I am presuming it can be achieved with start_discoverable_authentication - identify_discoverable_authentication - finish_discoverable_authentication - but can this be done with a registration done simply with start_passkey_}registration/finish_passkey_registration,, or does it need to be registered with start/finish_attested_resident_key_registration?

The simple flow with start/finish_passkey_registration/authentication works great but discoverable credentials might be great for when the user jumps on a different device that they own so they can get straight in.

Thanks, apologies if I'm missing the basics

[Firstyear]

We intentionally do not force a way to set require RK true because this can damage some security keys irreversibly. Discoverability is an opportunistic property of Webauthn, not a strict requirement contrary to some popular opinions.

As a result you would do "start_passkey_registration" as you have mentioned.

Then, when you want to allow the optional conditional mediation flow, you perform "start_discoverable_authentication" and then pass that to conditional UI. If conditional UI sends a response meaning the user engaged with that flow, then you call "identify_discoverable_authentication" which gives you the uuid of the user that wants to begin the flow, then you can proceed with finish_discoverable_authentication.

If the user chooses NOT to engage with conditional UI, then you need to offer the standard "start_passkey_authentication" when the user enters their username.

Key residency is orthogonal to to synchronised credentials. If I register against webauthn-rs on my iPhone, then it will "sync and work" on my iPad (apple wiping keychains periodically not withstanding).

The exception is Android, which has completely botched all their settings and requires a highly specific set of work arounds found in the function start_google_passkey_in_google_password_manager_only_registration which requires you to detect android as a user agent and the pre-request from the user what kind of device they want to enroll (security key, screen unlock or google passkey stored in google password manager) and then you need to call the correct registration to match.

In the attested cases, this requires you to limit to attested devices which only includes certain FIDO certified credentials, generally security keys. Almost no phones support attestation. As a result, this is intended only for "high security" environments where only specific certified devices should be used. Generally attestation completely precludes any synchronised credentials.

[justincrosbie]

Thanks! That clears a lot up - glad to hear it's simpler than I thought it was, and I can just use start/finish_passkey_registration. I think I have most of it figured out - where I'm stuck is the finish_discoverable_authentication function - it requires a &DiscoverableKey, and I'm not sure where to get that, as from registration, I only have a Passkey. Thanks for the fast reply!

…

On Mon, Jun 17, 2024 at 11:33 AM Firstyear ***@***.***> wrote: We intentionally do not force a way to set require RK true because this can damage some security keys irreversibly. Discoverability is an *opportunistic* property of Webauthn, not a strict requirement contrary to some popular opinions. As a result you would do "start_passkey_registration" as you have mentioned. Then, when you *want* to allow the optional conditional mediation flow, you perform "start_discoverable_authentication" and then pass that to conditional UI. If conditional UI sends a response meaning the user engaged with that flow, then you call "identify_discoverable_authentication" which gives you the uuid of the user that wants to begin the flow, then you can proceed with finish_discoverable_authentication. If the user chooses NOT to engage with conditional UI, then you need to offer the standard "start_passkey_authentication" when the user enters their username. Key residency is orthogonal to to synchronised credentials. If I register against webauthn-rs on my iPhone, then it will "sync and work" on my iPad (apple wiping keychains periodically not withstanding). The exception is Android, which has completely botched all their settings and requires a highly specific set of work arounds found in the function start_google_passkey_in_google_password_manager_only_registration which requires you to detect android as a user agent and the pre-request from the user what kind of device they want to enroll (security key, screen unlock or google passkey stored in google password manager) and then you need to call the correct registration to match. In the attested cases, this requires you to limit to attested devices which only includes certain FIDO certified credentials, generally security keys. Almost no phones support attestation. As a result, this is intended only for "high security" environments where only specific certified devices should be used. Generally attestation completely precludes any synchronised credentials. — Reply to this email directly, view it on GitHub <#442 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPISGF2VGG7JVAKJC4ZQTZHY4F3AVCNFSM6AAAAABJMNRJBKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOOBZGI4TS> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Justin Crosbie Software Developer 0456160772 https://justincrosbie.com

[Firstyear]

The API docs hide it a bit, but https://docs.rs/webauthn-rs/latest/webauthn_rs/prelude/struct.DiscoverableKey.html#impl-From%3C%26Passkey%3E-for-DiscoverableKey

[justincrosbie]

That's it exactly! Good old hindsight, I should have spotted that 😅 Thanks a million!

…

On Mon, Jun 17, 2024 at 1:07 PM Firstyear ***@***.***> wrote: The API docs hide it a bit, but https://docs.rs/webauthn-rs/latest/webauthn_rs/prelude/struct.DiscoverableKey.html#impl-From%3C%26Passkey%3E-for-DiscoverableKey — Reply to this email directly, view it on GitHub <#442 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPISAQ43BE6U7SFZDUJJDZHZHHTAVCNFSM6AAAAABJMNRJBKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOOBZG4ZDM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Justin Crosbie Software Developer 0456160772 https://justincrosbie.com

[Firstyear]

No problem at all, the rust docs layout doesn't make it easy to find - I know I've missed it in other libraries.