-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API doesn't match WebAuthn #12
Comments
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 I am interested though do you have a strong reason for being closer to the |
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 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. |
Would you accept a breaking-change PR to bring this API closer into conformance with how the actual WebAuthn API behaves?
For example, this library expects:
create({ challenge, pubKeyCredParams, ... })
, but the WebAuthn API expects:create({ publicKey: { challenge, pubKeyCredParams, ... } })
.The text was updated successfully, but these errors were encountered: