Google participants are amenable to the addition of a network transport for after-pairing communication, provided that the initial client/authenticator pairing takes place over a channel that ensures proximity
Our current plan is to submit a PR on top of the caBLE v2 PR, fido-alliance/fido-2-specs#724. Since this PR will be on top of Google's branch, we'll also open an issue on the FIDO2 specs repo.
We are currently hammering out some details of how communication will actually happen via the network transport. We are leaning toward, but not settled on, sticking with the caBLE model of a channel established via Noise handshake that then passes CTAP2 messages.
We hope to have a PR submitted in the next month or so, and will certainly be ready to discuss the transport ahead of the member plenary colocated with the FIDO Authenticate conference.
Please let me know if you have any questions!
The text was updated successfully, but these errors were encountered:
@nickmooney explained the rationale on the call - thanks! In short, the client and authenticator will set up a cryptographically secured channel for future communications. I think where I got hung up was that I read the "initial pairing" part to mean just a Bluetooth pairing, rather than setting up a cryptographic channel. I think I even described the latter scenario in an earlier draft of #1333.