Addition of a network transport

[nickmooney]

This issue is to track progress on the addition of a network transport, which is mostly happening in FIDO world. Here is a summary of progress so far:

• @arnar, @nicksteele and I discussed the issue at the FIDO plenary in Lisbon
• 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!

[nickmooney]

We have submitted a PR on top of the caBLE v2 PR. Please see this issue on the FIDO 2 specs repo, as well as the PR itself.

The PR has been made against Adam's fork of the fido-2-specs repo since caBLE v2 has not yet landed.

[equalsJeffH]

on 2020-03-11 call, noted that we may need to add another transport enum value. @emlun requested clarification of need for proximity, @nickmooney described the threat model (see minutes).

[emlun]

@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.

[nickmooney]

Here are our updated thoughts on the network transport as of early May. This document should explain most of what we're thinking. In short:

• caBLE pairing can happen via BLE or mDNS
• authenticators may provide a FQDN/port of a network relay during the pairing process
• if provided, the authenticator can be contacted via the network relay using the HTTPS protocol outlined in the document

The Network Transport, May 2020.pdf

[zbot473]

Why does the google chrome flag for caBLE v2 say pairingless?

Also how does one handle the fido:// url scheme? Nevermind, this was in the PDF you sent.

[zbot473]

Also another question, how do you use gatt to advertise the EID? Are there any libraries (for android at least) or would I have to implement this on my own?

[equalsJeffH]

changed milestone to L3-WD-01 because caBLEv2 https://github.com/fido-alliance/fido-2-specs/pull/724 likely will not be in CTAP 2.1.

[zbot473]

Ah, that's unfortunate

[equalsJeffH]

on 2021-01-06 call: keep this in-scope. likely addressed at webauthn abstraction layer by adding transport enum member(s).