Füge eine serialisierte Registrierungs- oder Anmeldeantwort ein, um Client- und Authenticatordaten zu lesen. Signaturen, Attestierung und Server-Challenge werden dabei nicht verifiziert.
Läuft lokal in deinem BrowserDer Server muss Challenge, Origin, RP-ID-Hash, Präsenz oder Verifikation, Signatur, Algorithmen, Attestation und Zähler prüfen.
Diese Seite liest eine serialisierte PublicKeyCredential — das JSON, das eine Relying Party von navigator.credentials.create() oder navigator.credentials.get() erhält — und macht beide Hälften als Felder lesbar — meist der schnellste Weg zu sehen, was eine fehlschlagende Registrierung oder Assertion tatsächlich enthielt. clientDataJSON wird aus Base64URL dekodiert und geparst, die Authenticator-Daten werden in RP-ID-Hash, Flags-Byte, Signaturzähler und, bei einer Registrierung, in AAGUID, Credential-ID und COSE-Public-Key zerlegt.
Alles läuft im Browser. Die Seite ruft navigator.credentials nicht auf, kontaktiert keine Relying Party und überträgt die Credential nirgendwohin. Dekodieren ist nicht Verifizieren: Signatur, Attestation-Statement und der Vergleich der Challenge gehören auf Ihren Server.
Das Flags-Byte beschreibt die Zeremonie, nicht die Credential. UP meldet einen anwesenden Nutzer, UV eine Verifikation per PIN oder Biometrie, BE dass die Credential auf einen anderen Authenticator kopiert werden darf und BS dass sie es gerade ist — ein synchronisierter Passkey setzt beide. AT kennzeichnet die attestierten Credential-Daten (AAGUID, Credential-ID und Public Key), die es nur in einer Registrierung gibt, ED markiert Erweiterungsdaten.
Der Signaturzähler ist eine 32-Bit-Ganzzahl ohne Vorzeichen, die der Authenticator bei jeder Assertion erhöht. Der Vergleich mit dem gespeicherten Wert ist die klassische Klon-Prüfung, doch ein Zähler, der sich nie bewegt, beweist allein nichts: viele Plattform-Authenticatoren liefern dauerhaft Null. Der RP-ID-Hash ist der SHA-256 der Relying-Party-ID, für die die Credential angelegt wurde; der Vergleich mit dem erwarteten Wert zeigt, dass eine auf einer Website erbeutete Credential nicht auf einer anderen wiederverwendet wird.
clientDataJSON ist Base64URL-kodiertes JSON, das der Browser aus Challenge, Origin und Zeremonie-Typ (webauthn.create oder webauthn.get) zusammensetzt. Die Seite dekodiert und parst es und meldet crossOrigin, wenn der Browser den Ablauf als eingebettet markiert hat. Danach folgt eine kompakte Binärstruktur: 32 Byte RP-ID-Hash, ein Flags-Byte, vier Byte Zähler und anschließend nur bei gesetztem AT-Flag die attestierten Credential-Daten.
Eine Registrierungsantwort enthält ein attestationObject, eine CBOR-Map, die dieselben Authenticator-Daten unter authData trägt; die Seite geht die CBOR-Map durch, um sie zu erreichen. Attestation-Format und -Statement daneben werden hier weder angezeigt noch geprüft. Felder, die der Browser um die Antwort legt, etwa transports und clientExtensionResults, gehören ebenfalls nicht zum Bericht.
Eine dekodierte Credential ist ein Indiz, kein Beweis. Die Relying Party muss die Challenge mit der für diese Sitzung ausgegebenen vergleichen, die Origin gegen die eigene prüfen, den RP-ID-Hash mit der erwarteten RP-ID abgleichen und die Signatur über die Authenticator-Daten und den SHA-256 von clientDataJSON mit dem bei der Registrierung gespeicherten Public Key verifizieren.
Sie muss außerdem ihre eigene Nutzerverifikations- und Attestation-Richtlinie anwenden, die akzeptierten Algorithmen einschränken und entscheiden, was Signaturzähler und Backup-Flags für ihr Bedrohungsmodell bedeuten. Diese Seite benennt die COSE-Werte, die sie kennt — ES256, EdDSA, ES384, ES512, PS256, PS384, PS512, RS256, RS384, RS512 mit den Kurven P-256, P-384, P-521, Ed25519 und Ed448 — und zeigt jeden anderen Wert als rohe Zahl; das ist eine Beschriftung und keine Richtlinienentscheidung.