Extensibility of navigator.credentials.get({otp: true})

[wicg]

Extensibility of navigator.credentials.get({otp: true})

[samuelgoto]

The only extension point that I can think off of the top of my head is in terms of transport mechanisms. So something like this would suffice:

navigator.credentials.get({otp: {transport: ["sms"]}}).then((credentials) => {
    // .... 
});

It also leaves the door open to other things in case we need. It is also consistent with the WebAuthn API, so kinda of nice. Open to other extensibility points too.

[mikewest]

Would you expect the user agent to do anything different based on the transport types provided to the user? I assume we'd be relying on an underlying platform-exposed API that handled some set of transports, but I can imagine the user agent might render different UX depending on the options available?

For the OTPCredentialRequestOptions, I think I'd suggest erring on the side of something extensible to give yourself options in the future. Treating it as a dictionary with a single transport member sounds fine to me.

(I'd note, though, that you'll likely want to expose in some way (perhaps a static transports attribute on OTPCredential?) whether or not a specific set of transports is available so that developers know how they can send an OTP. (And you'll need to think about the fingerprinting surface that exposes.))

[samuelgoto]

Would you expect the user agent to do anything different based on the transport types provided to the user? I assume we'd be relying on an underlying platform-exposed API that handled some set of transports, but I can imagine the user agent might render different UX depending on the options available?

Yes. Listening to SMS messages isn't free (e.g. it creates a Task<> on Android), so if we were expecting an "OTP by email" we wouldn't want to kick off the SMS retrieval process.

For the OTPCredentialRequestOptions, I think I'd suggest erring on the side of something extensible to give yourself options in the future. Treating it as a dictionary with a single transport member sounds fine to me.

SGTM.