Create user account before authentication during signup?
79 views
Skip to first unread message
Vipul Kapoor
Jun 1, 2024, 10:12:17 AMJun 1
to FIDO Dev (fido-dev)
In webauthn, you're supposed to provide a user id to `navigator.credentials.create` however when a user is signing up, they don't have an ID in my database. So does that mean that I should create their account as soon as they enter their name and email in the form and press Signup? Then I will have the user id and proceed with registering their device? Is this the correct flow?
Or do I create a random id?
My1
Jun 1, 2024, 11:00:14 AMJun 1
to Vipul Kapoor, FIDO Dev (fido-dev)
the userid should be random anyway, so you first create one randomly and store it together with the user.
Am Sa., 1. Juni 2024 um 16:12 Uhr schrieb Vipul Kapoor <vi...@glowingstonewebsites.com>:
In webauthn, you're supposed to provide a user id to `navigator.credentials.create` however when a user is signing up, they don't have an ID in my database. So does that mean that I should create their account as soon as they enter their name and email in the form and press Signup? Then I will have the user id and proceed with registering their device? Is this the correct flow?Or do I create a random id?
--
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/ebb75843-21c0-460d-9704-0fba025e502dn%40fidoalliance.org.
Ye Htut
Jun 1, 2024, 3:02:19 PMJun 1
to Vipul Kapoor, FIDO Dev (fido-dev)
On Sat, 1 June 2024, 8:42 pm Vipul Kapoor, <vi...@glowingstonewebsites.com> wrote:
In webauthn, you're supposed to provide a user id to `navigator.credentials.create` however when a user is signing up, they don't have an ID in my database. So does that mean that I should create their account as soon as they enter their name and email in the form and press Signup? Then I will have the user id and proceed with registering their device? Is this the correct flow?Or do I create a random id?
--
Vipul Kapoor
Jun 2, 2024, 5:46:11 AMJun 2
to Arshad Noor, FIDO Dev (fido-dev)
Thanks for your input. I'm talking about the publicKeyCredentialCreationOptions.user.id here
Guide to Web Authentication (webauthn.guide)
I'm planning to use the unique id (primary key) from the user table of my database. For that I'll have to create user's account before starting the webauthn registration process.
I'm planning to use the unique id (primary key) from the user table of my database. For that I'll have to create user's account before starting the webauthn registration process.
On Sun, 2 Jun 2024 at 15:06, Arshad Noor <arsha...@strongkey.com> wrote:
A lot depends on the purpose of the "ID", Vipul.
If you are in a regulated environment (fintech, health, etc.), then you
have to do some levels of "know your customer" (KYC) verification before
you on-board that user and create a FIDO credential.
If you are in an unregulated environment, where you pretty much don't
care what user ID they choose (as long as it is unique), then you can
prompt them for something, check if it exists within your FIDO database
and proceed from there.
Recognize that "ID" can be confusing in the FIDO ecosystem - there is
something called a "credential ID", generated by Authenticators and used
internally by its firmware to manage credentials (key-pairs). There is a
lot written about "discoverable credentials" where users can
authenticate without even providing a "user ID" - but what they're
referring to is the "credential ID" known to the Authenticator.
But IMO, it is a good idea to still ask the user to provide an ID
recognizable to them, and then go through the registration flow - you
can see this in the StrongKey Discover webapp at
https://demo.strongkey.com - which you can also download to review its
source code as an example.
Arshad Noor
StrongKey
> --
> 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
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ebb75843-21c0-460d-9704-0fba025e502dn%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ebb75843-21c0-460d-9704-0fba025e502dn%40fidoalliance.org?utm_medium=email&utm_source=footer>.
My1
Jun 2, 2024, 6:14:55 AMJun 2
to Vipul Kapoor, Arshad Noor, FIDO Dev (fido-dev)
yeah I expected that you mean that. here some W3C stuff about that:
specifically the third link recommends to just use 64 bytes of random data and be done with it.
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/CAFJ%2B-2BfsBhgda2F7AUkVVKEA2V062wfMA-P9TY8MmAFT6hMJQ%40mail.gmail.com.
Arshad Noor
Jun 2, 2024, 10:38:24 AMJun 2
to Vipul Kapoor, FIDO Dev (fido-dev)
A lot depends on the purpose of the "ID", Vipul.
If you are in a regulated environment (fintech, health, etc.), then you
have to do some levels of "know your customer" (KYC) verification before
you on-board that user and create a FIDO credential.
If you are in an unregulated environment, where you pretty much don't
care what user ID they choose (as long as it is unique), then you can
prompt them for something, check if it exists within your FIDO database
and proceed from there.
Recognize that "ID" can be confusing in the FIDO ecosystem - there is
something called a "credential ID", generated by Authenticators and used
internally by its firmware to manage credentials (key-pairs). There is a
lot written about "discoverable credentials" where users can
authenticate without even providing a "user ID" - but what they're
referring to is the "credential ID" known to the Authenticator.
But IMO, it is a good idea to still ask the user to provide an ID
recognizable to them, and then go through the registration flow - you
can see this in the StrongKey Discover webapp at
https://demo.strongkey.com - which you can also download to review its
source code as an example.
Arshad Noor
StrongKey
On 5/31/24 11:51 PM, Vipul Kapoor wrote:
If you are in a regulated environment (fintech, health, etc.), then you
have to do some levels of "know your customer" (KYC) verification before
you on-board that user and create a FIDO credential.
If you are in an unregulated environment, where you pretty much don't
care what user ID they choose (as long as it is unique), then you can
prompt them for something, check if it exists within your FIDO database
and proceed from there.
Recognize that "ID" can be confusing in the FIDO ecosystem - there is
something called a "credential ID", generated by Authenticators and used
internally by its firmware to manage credentials (key-pairs). There is a
lot written about "discoverable credentials" where users can
authenticate without even providing a "user ID" - but what they're
referring to is the "credential ID" known to the Authenticator.
But IMO, it is a good idea to still ask the user to provide an ID
recognizable to them, and then go through the registration flow - you
can see this in the StrongKey Discover webapp at
https://demo.strongkey.com - which you can also download to review its
source code as an example.
Arshad Noor
StrongKey
On 5/31/24 11:51 PM, Vipul Kapoor wrote:
Reply all
Reply to author
Forward
0 new messages