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
Is there any current thinking about how software-based OTP applications would be supported with this specification? I'm imagining a scenario, as is common today, in which a user scans a QR code to create a new OTP on their favorite authenticator app.
Obviously, in order to facilitate auto-filling by the browser, the application would have to have some sort of transport (bluetooth, internal, etc) to connect with the browser. This transport may even be a way to create an OTP in the application, rather than having to scan a QR code.
That being said, it is conceivable that the web app will not know which transports are available (unlike SMS or email, which require server involvement in creating/delivering the OTP). Is it expected to define transports for such cases? Or leave the transport unspecified?
The text was updated successfully, but these errors were encountered:
Is there any current thinking about how software-based OTP applications would be supported with this specification? I'm imagining a scenario, as is common today, in which a user scans a QR code to create a new OTP on their favorite authenticator app.
Obviously, in order to facilitate auto-filling by the browser, the application would have to have some sort of transport (bluetooth, internal, etc) to connect with the browser. This transport may even be a way to create an OTP in the application, rather than having to scan a QR code.
That being said, it is conceivable that the web app will not know which transports are available (unlike SMS or email, which require server involvement in creating/delivering the OTP). Is it expected to define transports for such cases? Or leave the transport unspecified?
The text was updated successfully, but these errors were encountered: