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.

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

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

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

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.

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?

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.

Ah, that's unfortunate

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

I believe this is resolved by #1755.