Evaluate removal of constraints for platform authenticators

[FlxMgdnz]

Checklist

• I could not find a solution in the existing issues or docs.
• I agree to follow this project's Code of Conduct.

Description

During registration, authenticatorAttachment is set to platform and therefore only platform authenticators can be used to register a passkey. But as the platforms/browsers behave inconsistently (Safari shows hybrid option while chrome does not), this effectively prevents hybrid passkey creation in Chrome (i.e., creating the passkey on a phone instead of on the platform).

There is also a check for isUserVerifyingPlatfomAuthenticatorAvailable in all places where WebAuthn could be triggered for the decision to show or hide the passkey login button / Conditional UI, again unnecessarily restricting usage of the hybrid option for authentication in cases where no platform authenticator is available but the browser is able to do the hybrid flow.

Describe your ideal solution

It should be evaluated if both constraints can be safely removed and leave handling different authenticator types to the client UI and the user. The only necessary check would be the availability of the WebAuthn API.

This way we can always support the hybrid option for registration and authentication.

Workarounds or alternatives

none

Hanko Version

0.2.0

Additional Context

A side effect of the above would be allowing passkey creation on physical Security Keys (SK). The full extent of this change must be thoroughly tested.

The current implementations of passkeys by Apple and Google indicate that passkeys always have to be discoverable credentials (or resident keys, RK), otherwise the UX of Conditional UI and/or a "Sign in with a passkey" button (without entering a username first) does not work.

So creating a passkey on a SK means we'd have to set residentKey: required on credential creation.

One thing we have to be aware of is that today's SKs only support a limited amount of RKs due to small storage space on the keys. That's why the residentKey: preferred option exists. But depending on the SK hardware, if we set (as we do now)

• requireResidentKey: true (WebAuthn L1)
• residentKey: preferred (L2),

the resulting "passkey" stored on the SK may not be a RK and therefore not usable in the typical usernameless passkey authentication flows implemented by the platforms, resulting in bad UX (user successfully creates a "passkey" on a SK, but cannot use it to sign in).

Aside from always requiring RKs, another possible solution for this could be that we continue to say preferred, but let Hanko backend check whether the newly created passkey credential has the RK flag and lets the "Save a passkey" flow fail if not. However, it is necessary to consider whether this approach has any advantages over simply requiring a RK