If RP have already identified the user somehow, RP would include allow credential for the authentication. In case of identified user only has single passkey (which means the transport is internal), and the user tries to authenticate, the allow credential only has one credential entry with internal transport. In this case, I'm thinking that RP is clearly indicates which credential is expected, then browsers or platforms might directly prompt Face ID or Touch ID without showing modal sheet which introduces additional user steps. For other cases, I understand why passkey modal sheet is needed, but in this case, it would be better to present Face ID or Touch ID prompt without modal UI.

When the passkey is generated with user verification required options with macOS (w/ device password and w/o/ touchId), the operation requires user prompt to perform UV with device password. This is an expected behavior. But, after successful registration, when trying to signin with auto-fill feature (conditional mediation), the signin process is failed on the RP side. RP sets UV as required (since the generated credential is protected by UV and RP would like perform MFA with UV) Safari shows the user account (which is registered before) Select the registered user account No UV is performed and Safari returns the assertion response RP rejects the assertion response since the requested options are not respected (expected UV flag is true, but currently UF flag is set as false with no UV performed). When authentication is requested with Modal UI, then the authentication performs the UV and the returned UV flag is set as true. (correct and expected behavior) Expected behavior Safari should respect UV required when handling such request with Auto-fill. FYI, I'm not tested with this scenario with other macOS (w/ touch Id).

Scenario Use Safari on macOS and then trigger Webauthn authentication with non-empty allow list Select QR code authentication flow and use Android passkey by scanning QR code and performing UV Check userhandle field in authenticator response coming from Safari. Issue: currently, the returned userHandle is empty ("") string. As a RP side, we could handle empty string as null, but some server implementation might reject such response since it's not valid value. Exepected behavior: If the authenticator does not return any userHandle to the browser, the userHandleResult (userhandle returned by the browser) should be null rather than empty string. Other observations: Chrome on macOS returns null userHandle for above scenarios which I'm thinking it's correct behavior. Safari on iOS returns populated userHandle (which is not null and empty) even the authentication is requested with non-empty allow credentials. I'm thinking that this is not the problem. See followings: https://w3c.github.io/webauthn/#assertioncreationdata-userhandleresult Also there are related discussions: https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/v6JBaTsNv08

Scenario Use Safari browser on macOS and trigger Webauthn authentication Select QR code authentication flows Use Android phone's passkey (with play service beta) and scan the QR code Perform UV on Android device Check the authentication response coming from the Safari on macOS Issue The authenticatorAttachment in the response is "platform". Expected behavior The authenticatorAttachment should be "cross-platfrom". According to the spec (https://w3c.github.io/webauthn/#dom-publickeycredential-authenticatorattachment), the value should be "cross-platform" since the attachment modality at the time of authenitcation is "cross-platfrom" rather than "platform". Without "cross-platform", RP cannot decide and guide for the user to register the "platform" authenticator on the macOS. I just checked this issue with Safari (16.2) on macOS (13.1). Also, you can refer related issue on the fido-dev-group: https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/XvDWBH6PhQ0

Currently, the title of the passkey modal is always "Signin". It is no doubt to present such titles for signing in user experience. But, there are other use cases to leverage passkeys such as step-up authentication or confirming a transaction. Maybe, the modal title could be something like "Authentication" or others? Or, for the native api, how about adding some parameters for RPs to set such titles?

WebAuthn API returns fully qualified origin of the API requester in the clientDataJSON. In case of passkey native api, which information is returned and how does it look like? I cannot find such information in anywhere. Thanks in advance.

Before promoting passkey registration, I would like to check whether the user device has platform authenticator (or passkey platform authenticator). While trying to search such feature in the docs, I cannot find it anywhere. Is this intended? If there is no such api, how can we know whether the user can register passkey?