Soweit ich verstehen kann, gibt es basierend auf Adam Langleys Blogbeitrag zwei verschiedene Ebenen:
Das Protokoll (API), das von Websites für den Zugriff auf ein Token über den Browser verwendet wird. Derzeit verwenden Websites die "FIDO U2F JavaScript API" . Diese API wird von WebAuthn ersetzt.
Das von Browsern (und anderer lokaler Software) verwendete Protokoll, um mit dem Token selbst zu kommunizieren. Derzeit verwenden FIDO U2F-Schlüssel das CTAPv1-Protokoll ("Client to Authenticator Protocol"), neue Geräte verwenden jedoch CTAPv2. Wenn Yubico über "FIDO2" spricht, meinen sie dieses Protokoll.
Obwohl die Upgrades aufeinander bezogen sind (CTAPv2 fügt neue Funktionen hinzu, die WebAuthn verwenden wird), sind die Schichten immer noch weitgehend unabhängig und Protokolle meistens abwärtskompatibel. Das ist:
Im Vergleich zu CTAPv1 besteht die Hauptaktualisierung von CTAPv2 darin, dass die Geräte über mehr Speicher verfügen, um sie als Hauptauthentifizierungsfaktor (und möglicherweise auch andere Funktionen) nutzen zu können.
Bestehende U2F-Teile scheinen jedoch die gleichen wie in CTAPv1 zu bleiben (mehr oder weniger muss das Token nur digitale Signaturen ausführen).
Verglichen mit der FIDO U2F-API besteht die wichtigste Änderung in WebAuthn darin, wie Identifikatoren ("AppID") für die "vertrauende Seite", dh die Website, generiert werden.
Token interessieren sich jedoch nicht für die interne Struktur des Bezeichners (er muss nur übereinstimmen), und WebAuthn hat sogar Bestimmungen, um die Verwendung vorhandener FIDO U2F-Registrierungen zu ermöglichen. (Neue Registrierungen über WebAuthn funktionieren jedoch nicht mit FIDO U2F.)
Wenn Sie also nur den zweiten Faktor (U2F) benötigen, scheinen alle vorhandenen Tokenmodelle weiterhin mit WebAuthn zu funktionieren.