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?
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?