Let Office Add-in sign-in on Mac use passkeys (run auth dialogs in ASWebAuthenticationSession)

Office.context.ui.displayDialogAsync on Word, PowerPoint and Excel for Mac runs in a WKWebView. Word's associated-domains entitlement lists webcredentials: only for Microsoft's sign-in hosts (login.microsoftonline.com / .us / .cn, login.microsoft.com; observed in Word 16.113.3). Any other identity provider cannot use passkeys or security keys in an add-in dialog. Google, for example, shows a broken "Make sure Bluetooth is on, and your devices are close to each other" screen.

Organizations that enforce phishing-resistant MFA (FedRAMP 20x KSI-IAM-01, OMB M-22-09) with a non-Microsoft identity provider therefore cannot sign in to add-ins on Mac at all. The only workaround, finishing sign-in in the system browser via openBrowserWindow, has no safe channel back to the add-in (RFC 10027, cross-device session phishing).

Ask (preferred): run add-in auth dialogs in ASWebAuthenticationSession, for example as a displayDialogAsync option. It supports passkeys and the user's existing browser sessions, and macOS returns the result only to the app that opened it, so Office can hand it to the add-in exactly as messageParent does today. This mirrors how Microsoft's own apps now route external-IdP passkeys through the system browser (Microsoft Entra blog, "Sign in to Microsoft apps with passkeys from external identity providers", Sep 29, 2026).

Alternative: obtain the com.apple.developer.web-browser.public-key-credential entitlement for the dialog host, so WebAuthn works for any relying party inside the existing dialog.

Previously closed as feature requests on GitHub: OfficeDev/office-js issues #6822 and #5284.