WebAuthn Response Byte Inspector

How to use WebAuthn Response Byte Inspector

Inspect supplied clientDataJSON and authenticatorData bytes, flag offsets and counters, and compare explicitly entered expected values without authentication. Hash the original client JSON bytes rather than a reserialization. Read AT credential-ID/COSE-map boundaries and ED extension maps through a bounded selected CBOR profile; every trust and signature result stays unverified.

1. Provide optional json byte-bundle file, response byte bundle as json.
2. Choose the supported mode and run the tool. Review its assumptions and any reported errors.
3. Copy the result or download a separate output; reset to clear the current form.

Good to know

• Input is one JSON object with unpadded Base64url clientDataJSON/authenticatorData strings and optional expected {rpId,challenge,origin}. Input source at most 100 KB; each decoded byte array at most 16,384 bytes. Outer and client JSON reject duplicate/prototype-related keys, non-finite numbers and more than 40 levels/100,000 values. No attestationObject, signature, private key, account or browser credential API is used.
• Client JSON must be original strict UTF-8 bytes without a BOM and contain type webauthn.get/create plus string challenge and origin. Challenge is canonical unpadded Base64url of at most 1,024 bytes; optional crossOrigin/topOrigin types are checked. Unknown members are tolerated and only their names reported. Reordered or whitespace-different valid JSON retains a different original-byte hash.
• Authenticator data requires the 37-byte RP-ID hash/flags/big-endian counter prefix and exact AT/ED-described remainder. AT reads the 16-byte AAGUID, a credential ID of at most 1,023 bytes and one COSE map. ED reads one extension map with text identifiers. Reserved flags and inconsistent backup/type hints are reported, not treated as verified claims.
• Each CBOR item is limited to 4,096 encoded bytes, 8 nesting levels and 512 values. Only definite, minimally encoded integers, byte/text strings, arrays, integer/text-keyed maps, true, false and null are supported. Tags, floats, undefined, indefinite forms, duplicate keys and complex map keys are refused. Byte strings retain Base64url; UTF-8 text preserves BOM characters as actual data.
• The COSE inspection profile requires integer labels and present integer kty/alg. Optional common parameters are flagged. It does not validate key-type-specific required/private parameters, algorithm compatibility, canonical map ordering, elliptic-curve points, key strength or cryptographic validity. Passing the parser is not a valid-key or full WebAuthn conformance verdict.
• Expected origin/challenge comparisons are literal and RP-ID comparison hashes the supplied UTF-8 bytes without IDNA, suffix, HTTPS or origin authorization. Missing comparisons remain unassessed. The assertion signature-base bytes are exposed only for get-type data without AT; no signature is checked and this is not an attestation signature-base implementation.
• No authentication, trusted origin/hardware, attestation chain, challenge freshness/replay, stored-counter evolution or ceremony policy is established. Local reports intentionally contain identifiers and supplied origin/challenge data. Reports are capped at 500,000 characters, with 10-second Worker preparation and a separate 2-second computation deadline.
• The formatted report is limited to 500,000 characters. Reduce the source when that output budget is exceeded.
• Inputs are processed on this device and are not automatically saved or uploaded.