Allow moving between transports

[iinuwa]

We should make it so that we can move back and forth between different transports/authenticators.

Right now, once you select an authenticator (scan the QR code, touch a USB security key, etc.), you have to finish the ceremony with that authenticator, or cancel the whole thing. I'd like the user to be able to start with a USB key, click the back button (e.g. because they realized it was the wrong one), select a different USB key, or select hybrid.

(I think scanning the hybrid QR code should probably lock you into finishing, but that's sort of a design question, and credentialsd doesn't need to make that decision; we can defer it to the UI.)

[iinuwa]

I think this is where I'm landing on this (more unedited notes below):

Handlers should report AuthenticatorError for "active" authenticators that fail. Inactive authenticators should just log and be restarted/ignored. (Active authenticator means different things to different transports, but basically, for Hybrid, if the QR code has been scanned, for USB, if the device has been selected and the channel is stable/the authenticator has accepted the make/get request (if we do this too early, flaky USB authenticators could block all the other ones available, NFC, if the device has been scanned.) If they are able to restart themselves, they should.

CredentialService should not terminate on error, but instead wait for the caller to cancel the session if they wish (e.g., they might want to terminate or not on errors from Hybrid or credential providers, since they may take long enough to make going through the ceremony again surpass the RP's timeout), or the request times out. If the error is CredentialExcluded, then we should terminate. (We should also terminate if either the user or client cancels, or if the request times out.)

I think that the backend can imply which transport is active based on the existing events: HybridConnecting, NfcConnected, UsbConnected. I don't think we need any new BackgroundEvents. We will need to re-send HybridStarted if that QR code is consumed to start a new one.

One other consideration is that I think we will need to be able to send events to the UI after the credential is released, for example to set up a linked device after hybrid QR flow. But that's a separate concern for another issue.

---

(notes)

Thinking about this some more, there are a few levels of cancellation:

• authenticator cancellation: when a particular authenticator experiences an error.
  • This should not abort the ceremony in most cases, except when CredentialExcluded is returned from an authenticator
  • examples (non-exhaustive):
    • NoCredentials: if there are no credentials found on a particular authenticator, it might be better to allow the user to try again on a different authenticator, or cancel
    • TransportError: something went wrong with the transport (Wi-Fi or BLE is flaky, USB device was unplugged, credential provider returns unknown error)
• ceremony cancellation: when the whole ceremony should be aborted and an error returned back to the caller.
  • I think this is just credential completed, credential excluded, user or client cancelled, or timeout.

Ceremony cancellation is straightforward, just return that to the caller.
Another thing to consider is that we could keep retrying various authenticators, but eventually, the RP will timeout the request and a returned response won't be useful anymore.