Hybrid flow in CTAP2.2 draft unnecessarily prescriptive

[Bryan Jacobs]

Dear FIDO devs,

I understand that the hybrid flow was designed for a smartphone scanning
a platform-presented QR code.

But fundamentally the flow is:

1. Side A presents a QR code containing <keyPart1>
2. Side B chooses <keyPart2> and advertises it over BLE
3. Side A receives BLE data containing <keyPart2>
4. Sides A and B combine <keyPart1> and <keyPart2>
5. Sides A and B rendezvous through an Internet tunnel server

Why does the standard require that Side A be a Platform and Side B be an
Authenticator?

I have a smartwatch that's capable of displaying QR codes and doing all
the necessary cryptography for the Authenticator side of an interaction,
and can read BLE adverts. I have a phone, and a laptop, that are each
capable of scanning a QR code and sending BLE adverts.

Why not change the wording slightly in the hybrid transport to allow
either a Platform or an Authenticator to initiate by displaying a QR
code, and the opposite side to response by scanning it and advertising?
The "unspecified transport" to the tunnel server would be on the
responder side instead of on the Authenticator specifically, and the
well-defined standard websocket connection would be on the initiator
side instead of always being the Platform.

What do y'all think?

Bryan Jacobs

[Isaiah Inuwa]

I think this is because the QR code contains two keys: a short-term symmetric secret key used for this particular session, and a long-term asymmetric identity key that is used to identify the client platform to the tunnel service for future sessions (e.g. to ask the tunnel service to wake up the authenticator and start another BLE advertisement without the user having to scan a QR code). The platform needs to prove ownership of the private key to the tunnel service, and the tunnel service and authenticator need to agree that they're talking about the same public key for the platform.

So the platform needs to generate the identity keypair, and the authenticator needs to attest to the public key to the tunnel service. That wouldn't work if the QR code was generated by the authenticator or another third device.

Hope that's helpful,

Isaiah Inuwa