API doesn't match WebAuthn about react-native-passkeys HOT 2 OPEN

Hey thanks for the suggestion, personally I lean towards not doing this.

The library is concerned with creating a unified api for using passkeys specifically, not the entire navigator.credential api.
Passkeys are PublicKeyCredentials in the browser API and so will always be publicKey as the first argument which would just add a lot of unnecessary redundancy.

I am interested though do you have a strong reason for being closer to the navigator.credential api?

from react-native-passkeys.

I have a library that wraps around the webauthn API. I wanted that same library code (or with as few changes as possible) to run in react native.

Your library was initially very attractive for that purpose, because I viewed it as providing a sort of polyfill to RN for the underlying credentials API, which my library could then use.

I was dismayed to find this incompatibility in API, because it means I have to make more significant design changes to my library to force it to use wrappers around your API to patch over the incompatibility.

Your assertion that passkeys in the browser are always already having the "publicKey" property... does not match my experience. My library is constructing the object arguments to create() and get() manually itself, and is doing so in the form (with "publicKey") as expected by the API.

From that perspective, your library providing functions that look to be the same API as what the browser provides, but taking an incompatible form of arguments, is inconvenient and dismotivating to use in the way I conceived.

from react-native-passkeys.