Missing credential ID after finished createCredentialAssertionRequest call

I tried to use Passkeys with our own FIDO-Server, but i encountered a problem.

After the user confirmed the authenticationRequest created with createCredentialAssertionRequest you get a ASAuthorizationPlatformPublicKeyCredentialAssertion. When i send the contents of it to our sever it fails, because it doesn't known which credential public key it should use to verify the signature.

The browser webauthn API returns something like this:

{
    "id": "...",
    "rawId": "...",
    "type": "public-key",
    "response": {
        "authenticatorData": "...",
        "clientDataJSON": "...",
        "signature": "...",
        "userHandle": "..."
    }
}

where id is the credential id used to sign the challenge, which our FIDO-Server can use to look up the public-key in its database.

With the current state of the iOS API our server would need to look up all public keys for the user and then try one by one in order to verify the signature.

So my question is, am i missing something? Or is this intended behaviour?

Replies

When you get the ASAuthorizationPlatformPublicKeyCredentialAssertion back you can parse it to get the necessary data like credentialID. Since Swift uses regular base64 strings you will have to convert them to base64URL strings then add them to a httpBody and send it to your server for assertion

case let credentialAssertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
            print("A credential was used to authenticate: \(credentialAssertion)")

            // Verify the below signature and clientDataJSON with your service for the given userID.
            let signature = credentialAssertion.signature
            let clientDataJSON = credentialAssertion.rawClientDataJSON
            let authenticatorData = credentialAssertion.rawAuthenticatorData
            let credentialID = credentialAssertion.credentialID

Yes, this is the intended behavior of the FIDO protocol - the credentialId is not sent in the attestation because the FIDO server is expected to know that. But, FIDO servers can optimize for that.