Hi. AI isn't enough to answer my question as it doesn't seem to take into account (1) that this sub-flow works as expected on any other browser (2) that the passkey is defined right before we try to use it and (3) the screenshot. Would you have a better idea of what could cause this? https://authtown.slack.com/archives/C07P7AN1EQH/p1776272802745549

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. Domain Binding Passkeys in Descope are domain-specific. The passkey created must match the exact domain where it's being used. If there's any mismatch (e.g.,

www.

vs. non-

www.

, or a redirect happening mid-flow), the passkey won't be recognized — even if it was just set. Browser-Specific WebAuthn Behavior Since the sub-flow works in other browsers, the issue is likely tied to how that specific browser handles the WebAuthn API. Things to check: • Whether the browser has a different passkey manager active (e.g., iCloud Keychain in Safari, Windows Hello in Edge, Google Password Manager in Chrome) • Whether the passkey was stored under a different browser profile than the one currently active • Whether the browser enforces stricter user gesture requirements before invoking WebAuthn Passkey Storage Scope When a passkey is created, it is stored within the browser profile or platform authenticator at that moment. If the flow creates the passkey in one context and then immediately tries to use it, but the browser session or profile is different, it may not recognize the passkey.

Hey @Noel we recently explored similar issues with passkeys on android and added the app's fingerprints to the Descope UI to match those the android app sends you, not sure it's related to what you are facing currently, but we solved this for other customer who ran the flow on the native browser. Due to the fact that android enforces some restrictions iOS does not, such as the domain name. here is a recap of what we instruct: 1. make sure the top level domain is where the asset links.json is served from 2. the descope flow is served from a subdomain of it (in the federated app settings) 3. select the top level domain in the webauthn descope settings 4. add the android apps SHA256 fingerprint to the screen (if you need help extracting it, there is a tooltip there where it shows the command) would it be possible if you check these steps and get back to me?

I'll do that and get back to you. Thx