Hi Apple Community & Apple Team, 
Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : All the above Problems can be solved if the Identity Provider implements Platform SSO , but not being implemented by major Identity Providers Except Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG ( Resource Owner Password Grant ) 
ITS RIGHT THAT PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDENTITY PROVIDER, AND MEANINGFUL ID TOKENS CAN BE ONLY USED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed a Feedback with ID FB23065453

As an iOS developer, what should I make sure of so users can clearly see that privacy is considered in my app?

Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!

We are deploying Platform SSO using the Secure Enclave authentication method. However, users are still being prompted for their username and password during registration. This undermines our goal of going passwordless and is causing deployment friction with customers. Once the Secure Enclave method is deployed and initialized, is there a way to suppress or skip this password dialog so users only authenticate via hardware/biometrics?

We would like to implement Platform SSO with the new web authentication. Where is the protocol documented? I have the documentation from prior versions of PSSO but would like to see the updated documentation.

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.

During PSSO User Registration, we use ASWebAuthenticationSession for OIDC. If the user's default browser isn't Safari (e.g., Chrome), the browser window stays stuck on top of the PSSO UI after authentication. This confuses users because they can't see the final PSSO registration screen. Are there any native macOS window-management APIs we can call inside the session's completion handler to force the PSSO window back to the foreground?

I saw the "Authenticated Guest Mode on iPad" in macOS 27. Is this related to PSSO Authenticated Guest Mode on macOS? Does it require cloud binding for a machine account like on macOS? How is it related to Shared iPad? Shared iPad requires supervised mode. Is there a new profile and keys? Where is this documented? Can you share information about how it works and how it can be tested?

There wasn't any update on the tap to login. Has the spec on tap to login been finalized? Can wallet passes now be issued to authenticate to macOS using tap to login?

Are there current plans to implement Microsoft 365 groups with Platform SSO to control administrator access in macOS 27? If so, would you be able to provide a rough estimate of when we can expect changes to be implemented by identity providers?

When a host app hasn't implemented ATT at all — which is still common in enterprise apps — what's the expected behavior for third-party SDKs that rely on tracking authorization? Should the SDK default to notDetermined handling indefinitely, or is there a recommended fallback experience?

For a third-party ads SDK embedded in host apps: the ATT authorization status is determined at the app level, but our SDK initializes before the host app necessarily calls ATTrackingManager.requestTrackingAuthorization(). What's Apple's recommended pattern for: SDK initialization that's ATT-status-agnostic at launch Receiving a callback or notification when ATT status changes post-initialization, without polling Is there a system notification or delegate pattern for ATT status changes that SDKs should be using in iOS 27? — Divya Ravi, Senior iOS Engineer

Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications? I am not seeing any traffic from Apple for user account changes (e.g., revoking authorization for an app), but the URL that I have configured in my account matches my endpoint, it is available from the public internet, and other SiwA functions are working correctly. Any guidance will be appreciated.

Throughout the years I've done a few integrations at my company with an iOS Application and an identity provider. I've implemented samples with UIWebView, WKWebview, Certificate based authentication through custom URLSession implementations and lastly through ASWebAuthentication. Also I gave the SSO Extension a try, but got stuck at some point (also Apple Forum didn't give me some solution -> https://developer.apple.com/forums/thread/117747) I'm having troubles digging through the Apple resources to find the best approach for big enterprises. We make use of a MDM solution, so I was hoping to find means to 'exploit it' and don't implement any custom authenticationframework anymore. Also, granting SSO between Apps and websites is what my ideal goal would be. Could you point me to some resources that can help me or give me some guidance on which of the frameworks/SDKs to use?

Future of Behavioral Authentication on Apple PlatformsWith the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy and security challenges would need to be solved before such an approach could become practical on Apple platforms?

do you see a future where devices continuously verify a user’s identity through behavioral signals rather than discrete login events?

with the advancement of on-device ai, do you see a future where devices continuously verify a user’s identity through behavioral patterns rather than discrete authentication events such as Face ID or password entry?

With the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy, security, and battery-efficiency challenges would need to be solved before such an approach could become practical on Apple platforms?

Are there any Kerberos feature or behavior changes in macOS 27?

Hey there, I'm trying to building an iOS credential provider (ASCredentialProviderExtension, iOS 17+) that manages passkeys backed by keys generated in the Secure Enclave, attested via App Attest. My question is about the cross-device (FIDO2 hybrid / "passkey on a nearby device") flow, where a phone authenticates a sign-in initiated on a separate client device (e.g. a laptop browser). Specifically, Can a third-party credential provider serve as the authenticator in this flow, signing with its own key — or is the cross-device role reserved for iCloud Keychain? If it can, does the OS handle the BLE advertisement and tunnel/handshake on the provider's behalf? I ask because it seems like CBPeripheralManager.startAdvertising(_:) will not emit raw bytes, so an app can't emit a CTAP hybrid advert itself. If neither is supported, is there any supported API — including MDM-managed/supervised-device capabilities — for an app to act as a cross-device FIDO2 authenticator with a non-iCloud-Keychain key? Thanks!