Type-Error about webauthn-framework

[Spomky]

Hello @Nevercold,

🤔 Honestly, I do not see any reason to have such weird values.
The library just receive the list of transport and use it as-it-is without modification of any kind.

I suspect a bad encoding or a modification in the way the data is fetch or saved in the DB.

Could you please share the following information?

• The raw PublicKeyCredentialSource field from your DB
• The way/library you use for saving and fetching the data

In addition, when you downgrade to the version 4.6.x, is it working as expected?
Is there any difference between existing data and new authenticators since v4.7.x?

Many thanks.
Regards.

[Nevercold]

Hey!
here is a stored PublicKeyCredentialSource

{
    "publicKeyCredentialId": "...",
    "type": "public-key",
    "transports": [
        "nfc",
        "usY"
    ],
    "attestationType": "basic",
    "trustPath": {
        "type": "Webauthn\\TrustPath\\CertificateTrustPath",
        "x5c": [...]
    },
    "aaguid": "2fc0579f-8113-47ea-b116-bb5a8db9202a",
    "credentialPublicKey": "...",
    "userHandle": "OGNhM2ExOTYtY2UxMy0xMWVkLThiNTctZGU3MzdiZDI1NTIw",
    "counter": 2,
    "otherUI": null
}

I store the data simply via PHP-PDO and write them directly to the database. (collation utf8mb4_general_ci)

$publicKeyCredentialSource = self::authenticatorAttestationResponseValidator()
        ->enableMetadataStatementSupport(new MetadataStatementRepository(), new StatusReportRepository(), new PhpCertificateChainValidator(new Client(), Fido2::Psr17Factory()))
        ->check($authenticatorAttestationResponse,
          PublicKeyCredentialCreationOptions::createFromArray($publicKeyCredentialCreationOptions), $serverRequest);

$publicKeyCredentialSource->jsonSerialize() <-- this saved to database

I just downgraded again to the 4.6.3, and there the output is also with "Y" (usY).
However, the keys were also created in this version. The same is on the 4.7.3.
The problem with the type error also only occurs on Apple devices, on all others this is not a problem, so I probably did not notice it directly when testing.

[Spomky]

😬$publicKeyCredentialSource->jsonSerialize() <-- this saved to database

I think the error comes from this line. As I mentioned in another issue, jsonSerialize is not supposed to be called directly, but used by json_encode.
It should be json_encode($publicKeyCredentialSource) instead -with optional flags if needed (in general, I had at least JSON_THROW_ON_ERROR)-

[Nevercold]

Same problem, json_encode($publicKeyCredentialSource)
just added

I also had it with json_encode at that time,
but had changed it during the upgrade (for whatever reason)

{
   "publicKeyCredentialId":"...",
   "type":"public-key",
   "transports":[
      "nfc",
      "usY"
   ],
   "attestationType":"basic",
   "trustPath":{
      "type":"Webauthn\\TrustPath\\CertificateTrustPath",
      "x5c":[
         "-----BEGIN CERTIFICATE-----....-----END CERTIFICATE-----\n"
      ]
   },
   "aaguid":"2fc0579f-8113-47ea-b116-bb5a8db9202a",
   "credentialPublicKey":"...",
   "userHandle":"OGNhM2ExOTYtY2UxMy0xMWVkLThiNTctZGU3MzdiZDI1NTIw",
   "counter":1,
   "otherUI":null
}

[Spomky]

Many thanks. That is really a strange behaviour. The library does nothing with the list and the DB operations look good.
So it may come from the data received from the client.
Could you please share the options generated by the library and the authentication response as JSON objects?
I would like to make sure there is no decoding issue (maybe CBOR decoding).
Do you use MasterKale/SimpleWebAuthn directly or the stimulus controller from this project?

[Nevercold]

I have found the problem, it has nothing to do with this library.

I had an old function to fix the base64 padding,
that was switched in before the response was processed, and that's what caused the error.
I have now removed it and the problem is solved.

Sorry for the trouble, and thanks for the help.

[Spomky]

Hi,
No problem. I am happy to read that this issue is resolved.

[github-actions]

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.