Creating passkey

hetin k

unread,

Nov 8, 2022, 12:07:22 AM11/8/22

to FIDO Dev (fido-dev)

Hi all,

1) is it mandatory to check ConditionalMediation availability before making navigator.credentials.create() call? Reason for asking this is explainer article state that "Credential registration is out of scope for this feature and will happen through the existing WebAuthn flow".

2) is it mandatory to pass value "required" to " residentKey " and " userVerification" or we can pass "preferred"

Thanks

Tim Cappalli

unread,

Nov 8, 2022, 12:36:40 AM11/8/22

to hetin k, FIDO Dev (fido-dev)

I'd recommend you read through https://passkeys.dev/docs/use-cases/bootstrapping/ instead of that explainer.

1) Conditional Mediation, aka Autofill UI, is only used for getAssertion

2) If you're trying to create a passkey, residentKey needs to be required. For user verification, preferred or required can be used, but you need to ensure your server-side logic can handle the response and treat it appropriately in your business logic.

Tim

Get Outlook for Android

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of hetin k <het...@gmail.com>
Sent: Tuesday, November 8, 2022 12:07:22 AM
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Creating passkey

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4eb5ab90-69d7-41c0-85c0-65958b134430n%40fidoalliance.org.

Message has been deleted

hetin k

unread,

Nov 8, 2022, 1:29:03 AM11/8/22

to FIDO Dev (fido-dev), Tim Cappalli, hetin k

Thanks for reply tim.

1) Even Passkey.dev suggest to check PublicKeyCredential.isConditionalMediationSupported() before making navigator.credentials.create() call. As you said checking PublicKeyCredential.isConditionalMediationSupported() is not needed, right?

2) Currently we set residentKey to "preferred" for better user experience(android fail webauthn call when it set residentKey to " required " ) and even if we pass residentKey to "discouraged", window and mac create residentKey. Does calling navigator.credentials.create() with residentKey to "preferred" provide better user experience (because it support both android with and without resident key support) or we need to change residentKey to " required " when making passkey request.
In short, what value should be passed to " residentKey " to support both before passkey and passkey ecosystem?

Shane Weeden

unread,

Nov 8, 2022, 1:49:10 AM11/8/22

to FIDO Dev (fido-dev), het...@gmail.com, Tim Cappalli

Things are moving rapidly in this space. To be honest, there is not one pattern that works everywhere at the moment, and you are likely going to need to employ some client side user-agent detection to tailor the experience to the capabilities of the device.

Emil Lundberg

unread,

Nov 8, 2022, 8:07:41 AM11/8/22

to FIDO Dev (fido-dev), het...@gmail.com

Hi hetin,

1) The isConditionalMediationSupported() call is needed if you intend to use the autofill UI in your WebAuthn implementation. It's not strictly necessary to check before the navigator.credentials.create() call, but you might run into a confusing user experience if you create credentials intending to primarily use the autofill UI flow, and then that turns out to not be supported by the user's device or browser.

If you do not intend to use the autofill UI flow, or if you intend to support both the autofill UI and the modal UI flow, then you do not need to check isConditionalMediationSupported().

2) Again, it depends on what UI flows you intend to use.

If you intend to only support username-less flows, then you need the credentials to be discoverable (resident), so you need to set residentKey: "required".
If you intend to support a user flow where the user first types a username and then is prompted for a WebAuthn credential, then discoverable keys are not required and you can set residentKey: "preferred" or "discouraged". With residentKey: "preferred", users with compatible devices and browsers will able to use the autofill UI as well as username-less flows, and users with incompatible devices can fall back on typing their username. With residentKey: "discouraged", assume that most users will need to type a username during the login flow.
If you do not intend to use autofill UI or username-less flows, you can set residentKey: "discouraged".

Hope that helps.

Emil Lundberg

Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/03681d4b-3818-4ccf-b528-48a1d60d5ac5n%40fidoalliance.org.

Philipp Junghannß

unread,

Nov 8, 2022, 8:23:03 AM11/8/22

to Emil Lundberg, FIDO Dev (fido-dev), het...@gmail.com

Putting Passkeys aside for a second, is there a way to potentially ask for RKs only on devices which either have no effective storage limit or RK management (CTAP2.1)?

because I would not want to waste one of the 25 slots of an early model yubikey 5, where the only way to get rid of a credential is to just CLEAR EVERYTHING.

Regards

My1

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CANMnvkyZfmd3EQb0DHC%3D%3D4GaceviLvphjsKuGcdyzug0nG3RxA%40mail.gmail.com.

Tim Cappalli

unread,

Nov 8, 2022, 9:28:06 AM11/8/22

to Philipp Junghannß, Emil Lundberg, FIDO Dev (fido-dev), het...@gmail.com

@My1, can you please create a new thread for your questions so we can keep the discussion on the original topic? Thanks!

@Hetin

You're right that the docs say that you may want to check whether the autofill UI is supported. This is not a hard requirement but is helpful as you're adapting experiences to the user's current environment. For example, in the case you want to show a follow up screen after creation, you may have different screenshots/examples for the user is autofill is not supported.
If your goal is to support passkeys (i.e. the entire passkey experience) in your service, residentKey needs to be required.

Emlun's detailed response is correct, but I'm addressing this holistically for the passkey experience, as the question was specific to "creating a passkey" which has multiple components and requirements.

tim

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Philipp Junghannß <teamhyd...@gmail.com>
Sent: Tuesday, November 8, 2022 08:22
To: Emil Lundberg <em...@yubico.com>
Cc: FIDO Dev (fido-dev) <fido...@fidoalliance.org>; het...@gmail.com <het...@gmail.com>
Subject: Re: [FIDO-DEV] Creating passkey

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNo7bezeN29iWvkD_RUi1KGHxCMNvL-fYCyG5c9NTJN4Bw%40mail.gmail.com.

hetin k

unread,

Nov 9, 2022, 2:41:01 AM11/9/22

to FIDO Dev (fido-dev), Tim Cappalli, FIDO Dev (fido-dev), hetin k, My1, Emil Lundberg

Thanks for help @tim and @emil

Emil Lundberg

unread,

Nov 9, 2022, 5:54:06 AM11/9/22

to Philipp Junghannß, FIDO Dev (fido-dev)

Re: ask for RKs only when not limited -

There is no way to express that preference at the moment, but I think one could be added, since the client can detect whether the authenticator supports CTAP2.1 credential management. Let's continue that discussion in the WebAuthn issue tracker: https://github.com/w3c/webauthn/issues/1822.