IS-11302: Auto-start WebAuthn ceremonies with a single action

[aleixsuau]

Jira: https://curity.atlassian.net/browse/IS-11302

Summary

When an authentication or registration step renders exactly one WebAuthn client-operation action, automatically trigger the ceremony so the user goes straight to the OS prompt without an extra click. Toggleable via HaapiStepperConfig.webAuthnAutostart (default true).

Auto-start is skipped when:

• The browser doesn't expose the WebAuthn JSON-parsing API.
• The user agent is real Safari (non-Chromium) — matches the legacy Velocity templates' UA sniff.
• A platform-only any-device registration is offered but no platform authenticator is available.
• An any-device step has been split by splitWebAuthnRegistrationAction into both platform and cross-platform actions (the user must pick).

Also extends HaapiWebAuthnAuthenticationArgs with the platformCredentials / crossPlatformCredentials descriptor lists to match the HAAPI data model.

Architecture

• manageWebAuthnAutoStart(step, nextStep) — pure helper, gates and dispatches.
• handleAuthenticationOrRegistrationStep — step handler that formats data and fires the helper when config.webAuthnAutostart && isWebAuthnStep(step).
• WebAuthn predicates and capability checks consolidated in webauthn/utils.ts.

Out of scope (follow-ups)

• Auto-init vs manual-click error handling — when auto-start fails, today the error surfaces as a step error. The follow-up will silence auto-init failures (the action button is already rendered, user can click) and fire errorActions only for user clicks. Plan drafted, will land as a separate PR (likely IS-11252).

Test plan

• WebAuthn registration step on Safari → button rendered, no auto-start
• WebAuthn registration step on Chromium → auto-start fires
• Passkey authentication step on Chromium → auto-start fires
• Any-device registration with both options → two buttons, no auto-start
• Platform-only any-device on a device without platform authenticator → button rendered, no auto-start

[luisgoncalves]

I tested a few combinations locally and this seems to work well 👍

I commented with some concerns, and other smaller things for consideration.

[luisgoncalves]

Ah, right. This was removed in server version 11.0. Since the LWA will released after that, I suggest removing this mention here. The HAAPI docs will be updated at some point.

[luisgoncalves]

The stepper already has "automatic handling" of certain cases, namely redirect steps and OAuth responses. In those cases we either trigger the automatic behavior (e.g. redirect to application), or don't do anything, and the "next step data" goes through to be set on the stepper context.

Here, however, both things are done: trigger the automatic behavior and still set "next step data" on the context, which means it will be rendered, but we have no idea how it will be rendered. An interceptor doesn't get the chance to do something about this, without further change to the config option.

I'm wondering if this wouldn't be better suited in a component - namely in a component specific to each WebAuthn client operation. OTOH here we are in the "transition moment", so we know when to start - that may be a plus, not sure...

Did you consider this?

[luisgoncalves]

This kind of shows the concern in my other comment. This has nothing about webauthn on rendering, but something already started in the background, anyway.

[luisgoncalves]

Somewhat related to the above, in the Velocity version, when there is a "auto start", the UI hides the buttons and shows a spinner (both on authentication and registration). I guess interaction with the page is blocked while the native browser UI is present, but maybe it's good to adjust the UI below, anyway. Question for Urban, maybe.

[urre]

The Register new device screens is missing a page title. Could be it's lacking in Velocity also.
But we should polish this screen a little. Can be done in another PR of course.