Upcoming changes for version "2"?

[dagnelies]

There are a few things I would like to change in a version "2".
It's not really big fundamental changes, but they are "breaking" changes nonetheless requiring a major version bump.

• Make register and authenticate functions accept a single object containing all properties directly instead of "(name/creds, challenge, options)"
• The authenticator.synced property will be moved to credential.synced. I find it belongs there rather than in the authenticator, it's more intuitive/logic.
• The userHandle property during registration will be removed. Instead you will be able to set user as either a string or as {id: ..., name: ..., displayName: ...} like in the original protocol.
• The userHandle from the authentication result will be renamed userId
• Get rid of expected.origin and rely only on the newer expected.domain
• The debug flag will be renamed verbose
• make a triple build (modules, commonjs, browser script)

...I also wonder if I should simply rename the "webauthn v2.0" into "passkeys v1.0" instead.

In case you have something else that you'd like to see changed/improved, now is the time to speak up!

[dagnelies]

Update:

• no change to the debug flag after all. It's not only verbosity, it's also parsed data in results
• moving authenticator.synced to credential.synced is non-trivial because it depends on a flag in the authenticator and not available before parsing. Yet the credential object is used browser-side too.

[dagnelies]

Currently, the implementation favors using the device itself as authenticator (platform) because the UI was smoother. I'm going to revert that tough in v2 because security keys are now the only safe hardware bound option, which has simply higher security guarantees.

Hints will be supported too.

[dagnelies]

Preview of v2 is here: https://webauthn-ciy.pages.dev/

[dagnelies]

TODO:

• add transports to allowCredentials
• adapt response to toJSON

[Kareszrk]

What about users using dynamicImport to use the module via such as NestJS? Will that version be depreaced?

[dagnelies]

What about users using dynamicImport to use the module via such as NestJS?

I'm not familiar with NestJS, I guess it's more of declaring/configuring it accordingly there, right?

The JS ecosystem is so fragmented in platforms (node, deno, bun, CF workers, vercel...), packaging formats (esm, cjs, umd, raw), build tools (esbuild, webpack, vite, rollup, parcel, etc...) and frameworks (next, nuxt, nest, astro...). As a consequence, it's extremely challenging to build something that everyone can integrate seamlessly.

I consider ES modules to be by far the most universal, so that's the way I go. Most ecosystem also have a way (or at least some workaround) to import plain normal modules. What I would prefer is for the community to build such examples in their favourite platform/tool/framework, that would simply be linked here as "getting started with XYZ" examples.

Will that version be depreaced?

You mean the 1.x version? Yes, when the 2.x comes out the older one will be deprecated. You can still use it, it just won't be developed further.

[Kareszrk]

Thank you. Basically NestJS is CommonJS based but with the help of dynamicImport and the current backend structure of the webauthn module of yours it's possible to be used and my question was related to this. I guess even tho you're not familiar with NestJS in any way maybe you still can tell a little information about if this code #35 (comment) still may work or not. It's important to me.

If you still cannot, that's okay and thank you for your time

[Kareszrk]

PS:
DynamicImport is part of NodeJS and it's not NestJS based just for clarification. :)

[dagnelies]

The packaging will be extremely similar, so you should have no issues.

[mstaicu]

make a triple build (modules, commonjs, browser script)

Modules = ES Modules, leaving the consumers' build pipeline to decide how they integrate the sources, enabling static analysis and tree shaking?

[dagnelies]

Yes