You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use case to implement where user needs to login on web app opened in desktop/laptop using passkey stored in smartphone following FIDO2 specs.
What I can get from the resources available over internet that by leveraging FIDO UAF + push notification we can achieve the mentioned use case. But with FIDO2, we can't as of now. That's why Google came up with CaBLE extension.
Is it true? If yes is there any tracking issue? If not, than can anyone please help out to provide details around it like implementation example or library to use etc.
For confirmation purpose, is the below mentioned flow for Smartphone as a FIDO2 roaming authenticator via BLE is correct?
Authentication flow:
a) User access a protected web app on browser and needs to sign-in.
b) User selects passwordless authentication mechanism.
c) User submits the username & clicks "sign-in passwordless". Here WebAuthn API is invoked.
d) RP receives the request & prepares a "challenge + policy" sends this to browser.
e) Browser detects that it needs to get the passkey sign-in from roaming authenticator. it starts looking out for device to pair first.
f) User enables the smartphone bluetooth, post this laptop & smartphone gets paired first. After this a QR code is displayed on the browser embedded with "challenge + policy" received from RP.
g) User scans the QR code from his smartphone (lets say from authenticator app) & completes the biometric verification.
h) User smartphone prepares the packet to be sent to the user browser over BLE, this have the response encrypted with private key.
i) On receiving the response from user smartphone, browser prepares the request using WebAuthn API sends this to RP for verification.
j) RP verifies the encrypted message using public key of the user. And allows the user to access the protected app.
The text was updated successfully, but these errors were encountered:
chunsfire
changed the title
Smartphone as a FIDO2 roaming authenticator via BLE
CTAP2.1 - Smartphone as a FIDO2 roaming authenticator via BLE
May 20, 2024
I have a use case to implement where user needs to login on web app opened in desktop/laptop using passkey stored in smartphone following FIDO2 specs.
What I can get from the resources available over internet that by leveraging FIDO UAF + push notification we can achieve the mentioned use case. But with FIDO2, we can't as of now. That's why Google came up with CaBLE extension.
Is it true? If yes is there any tracking issue? If not, than can anyone please help out to provide details around it like implementation example or library to use etc.
For confirmation purpose, is the below mentioned flow for Smartphone as a FIDO2 roaming authenticator via BLE is correct?
Authentication flow:
a) User access a protected web app on browser and needs to sign-in.
b) User selects passwordless authentication mechanism.
c) User submits the username & clicks "sign-in passwordless". Here WebAuthn API is invoked.
d) RP receives the request & prepares a "challenge + policy" sends this to browser.
e) Browser detects that it needs to get the passkey sign-in from roaming authenticator. it starts looking out for device to pair first.
f) User enables the smartphone bluetooth, post this laptop & smartphone gets paired first. After this a QR code is displayed on the browser embedded with "challenge + policy" received from RP.
g) User scans the QR code from his smartphone (lets say from authenticator app) & completes the biometric verification.
h) User smartphone prepares the packet to be sent to the user browser over BLE, this have the response encrypted with private key.
i) On receiving the response from user smartphone, browser prepares the request using WebAuthn API sends this to RP for verification.
j) RP verifies the encrypted message using public key of the user. And allows the user to access the protected app.
The text was updated successfully, but these errors were encountered: