Hi Paul,
Try a couple of different registration flows we've setup:
1)
https://demo.strongkey.com
2)
https://demo.strongkey.com/fidopolicy (please be patient - its on a
low-horsepower machine for now)
The second URL is more interesting. It demonstrates a capability in our
open-source FIDO Certified server, which allows you to configure unique
policies and enforce that within the application without having to code
anything into the application - if the registration/authentication
conforms to the policy, you're in.
Because this is a demonstration, there is no ID&V process involved. The
first URL sign-up requires an e-mail to send you a link to register, and
a mobile number to get an OTP before you're in.
Hope it provides some insights.
Arshad Noor
StrongKey
On 10/5/21 2:52 AM, Paul McNamara wrote:
> I posted this on StackOverflow originally but figured this place would
> be a bit more active when it comes to FIDO2 questions. I think there's
> only 4 or 5 regular answer posters on there (but thankyou Yuriy for your
> reply).
>
> This is more of a philosophical question/request for comment rather than
> a technical one but I think it's still relevant even if it boils down
> more to UX design than anything else.
>
> It's 2021, hardly anyone has a Yubikey or similar but nearly everyone
> has a phone, tablet or desktop/laptop with a TPM and an OS or browser
> that supports FIDO2 & WebAuthn. Therefore I'd like to explore ways to
> make the built-in authenticator enrollment process as slick as possible
> and not require them to have conventional password auth in place (even
> temporarily) to allow it to be done.
>
> Is anyone aware of an approach out in the wild similar to the OpenID
> Connect device flow whereby someone could go to a public enrollment
> endpoint, do the credential creation ceremony for their device and then
> use a resulting unique code to link it to an account on another already
> enrolled device?
>
> I'd see it working something like this:
>
> 1. User visits
https://idp.mycompany.com/enroll
> 2. They hit the "enroll this device" button and trigger the create
> credential interaction (would likely need to prompt for the user ID
> here as we'd need it to set up the resident key)
> 3. We store the resulting credential in the backend and exchange for a
> unique code (e.g. ABC123)
> 4. User visits
https://idp.mycompany.com/enroll/ABC123
> 5. User is prompted to authenticate using the resident key on their
> already enrolled device
> 6. Once the user is signed in the stored credential is added to the
> user account in question and they receive a visual confirmation
> 7. User is able to sign in using the credential on their newly enrolled
> device
>
> This feels to me to be pretty secure as even if a code could be guessed
> the worst you could do would be to add someone else's credential to your
> account and since this is happening in an authenticated context we can
> implement rate limiting easily. The user would be free to manage their
> credentials after the fact however they see fit via a management UI.
>
> Step 2 is probably the bit that's least clear for me but my thinking is
> that it doesn't really matter if the user provides garbage user details
> for the resident key as we'll be linking based on the credential ID in
> the backend anyway. If they put nonsense in then they're just impacting
> their own UX and nothing else and will be free to correct the mistake if
> they wish.
>
> Thoughts?
>
>
>
> --
> 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>.
> <
https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org?utm_medium=email&utm_source=footer>.