parsing error with "invalid Additional Information"
Version(s) affected: 2.1.0
Description Trying to parse a CBOR object (WebAuthN Level 2 - FaceID - Registration - attestationData) fails with a "connot parse".
How to reproduce You would need to register a FaceID with newest iOS credential in WebAuthN context and parse the resulting attestationData CBOR object.
Possible Solution This really looks like the parser having a bug or missing functionality about this ominous "Additional Information". Other WebAuthN authenticators (including older iOS versions of FaceID) do not have this issue. Also, this newest FaceID works on the demo page webauthn.io.
Additional context Here is a debug output with backtrace of the software calling the CBOR decoder:
Caused by: InvalidArgumentException: Cannot parse the data. Found invalid Additional Information "00011110" (30). Backtrace: 8 vendor/spomky-labs/cbor-php/src/Decoder.php:111 (CBOR\Decoder::process) 7 vendor/spomky-labs/cbor-php/src/Decoder.php:142 (CBOR\Decoder::processFinite) 6 vendor/spomky-labs/cbor-php/src/Decoder.php:120 (CBOR\Decoder::process) 5 vendor/spomky-labs/cbor-php/src/Decoder.php:92 (CBOR\Decoder::decode) 4 modules/webauthn/lib/WebAuthn/WebAuthnAbstractEvent.php:423 (SimpleSAML\Module\webauthn\WebAuthn\WebAuthnAbstractEvent::cborDecode)
Hi,
Thank you for reaching me. Can you share the input data so that I can understand what is going on. This library is already working fine with Webauthn and other project.
The Additional Information 30 is not supported with the current specification so either the input data is invalid or you are using another specification I am not aware of.
Here is a bin2hex of attestation objects.
Yubikey 5C, parsing fine: Attestation Object in bin2hex: a363666d74646e6f6e656761747453746d74a068617574684461746158c42321cf6a3d265802762dd143fd886c7474c2e0ed2582d5f8fc0dbc58c4580a4c41000003f20000000000000000000000000000000000401e65dd64feaf2d9040bcb6111c423ac4174e2a6e56297a24e0d2bd25ff1b6d14e08439eae75b795e429539dac23b9517c061f0083a4eeb52b40c73d6ec812666a50102032620012158202ad6d5c4b5574b7425fb5ca94bc6af6609e189daa77de72dfd722aba2e5c5d8b225820b9d869629e1ffd14e0da113f88616fa5c853c62e2e2e2a89d584267d40547c77
FaceID in iOS 16.1.1 (iPhone 14 Pro), not parsing correctly: Attestation Object in bin2hex: 99e86b9e2c
This value is not truncated. Both were extracted at the same line of code, with two registration ceremonies on the two devices.
Many thanks. The second one is clearly not a valid CBOR object. https://cbor.me/ cannot load it either.
Ping @amenophis: you had troubles with the last iOS version. Any though on this?
FWIW, the reg ceremony produced the identical byte sequence in Safari and Chrome. (But as I wrote above, the demo reg on webauthn.io worked with that FaceID which is somewhat unexpected given the byte sequence.)
Is it possible to have both options sent by webauthn.io (response body) and the authenticator response (body request)? (JSON formatted)
Considering that we are talking about an iPhone, the debug options are limited client-side, sorry. (Besides, it's not my phone and I need to pester a colleague to do this). Again FWIW, I just ran a TouchID registration on macOS Ventura and that works fine as expected with a proper CBOR response. I'd strongly suspect a FaceID specific bug, but that doesn't match that it works on webauthn.io.
Is it working with the demo at https://webauthn.spomky-labs.com/ ?
Well, even using a Yubikey Bio does not work there (or somehow). Registration worked after a few attempts but then gave me
GET https://webauthn.spomky-labs.com/profile 500 (Internal Server Error)
😬... OK I got the reason for that bug. Let me fix it first.
So my colleague registered FaceID working(!) with the user identifier testiphone14faceid. I hope you have enough server-side debug to see attestation data...
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.