WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must : Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]). When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.

We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?

Hi, how can you authenticate a User through Biometrics with iPhone Passcode as Fallback in the Autofill Credential Provider Extension? In the App it works without a problem. In the Extension I get "Caller is not running foreground" Yeah, it isn't, as it's just a sheet above e.g. Safari. I'd like to avoid having the user setup a Passcode dedicated to my App, especially because FaceID is way faster. Does anybody know how to achieve iOS native Auth in the extension? Please let me know, a code sample would be appreciated. Regards, Mia

I am working on implementing mTLS authentication in my iOS app (Apple Inhouse & intune MAM managed app). The SCEP client certificate is deployed on the device via Intune MDM. When I try accessing the protected endpoint via SFSafariViewController/ASWebAuthenticationSession, the certificate picker appears and the request succeeds. However, from within my app (using URLSessionDelegate), the certificate is not found (errSecItemNotFound). The didReceive challenge method is called, but my SCEP certificate is not found in the app. The certificate is visible under Settings > Device Management > SCEP Certificate. How can I make my iOS app access and use the SCEP certificate (installed via Intune MDM) for mTLS requests? Do I need a special entitlement, keychain access group, or configuration in Intune or Developer account to allow my app to use the certificate? Here is the sample code I am using: final class KeychainCertificateDelegate: NSObject, URLSessionDelegate { func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate else { completionHandler(.performDefaultHandling, nil) return } // Get the DNs the server will accept guard let expectedDNs = challenge.protectionSpace.distinguishedNames else { completionHandler(.cancelAuthenticationChallenge, nil) return } var identityRefs: CFTypeRef? = nil let err = SecItemCopyMatching([ kSecClass: kSecClassIdentity, kSecMatchLimit: kSecMatchLimitAll, kSecMatchIssuers: expectedDNs, kSecReturnRef: true, ] as NSDictionary, &identityRefs) if err != errSecSuccess { completionHandler(.cancelAuthenticationChallenge, nil) return } guard let identities = identityRefs as? [SecIdentity], let identity = identities.first else { print("Identity list is empty") completionHandler(.cancelAuthenticationChallenge, nil) return } let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession) completionHandler(.useCredential, credential) } } func perform_mTLSRequest() { guard let url = URL(string: "https://sample.com/api/endpoint") else { return } var request = URLRequest(url: url) request.httpMethod = "POST" request.setValue("application/json", forHTTPHeaderField: "Accept") request.setValue("Bearer \(bearerToken)", forHTTPHeaderField: "Authorization") let delegate = KeychainCertificateDelegate() let session = URLSession(configuration: .ephemeral, delegate: delegate, delegateQueue: nil) let task = session.dataTask(with: request) { data, response, error in guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { print("Bad response") return } if let data = data { print(String(data: data, encoding: .utf8)!) } } task.resume() }

I am developing a daemon-based product that needs a cryptographic, non-spoofable proof of machine identity so a remote management server can grant permissions based on the physical machine. I was thinking to create a signing key in the Secure Enclave and use a certificate signed by that key as the machine identity. The problem is that the Secure Enclave key I can create is only accessible from user context, while my product runs as a system daemon and must not rely on user processes or launchAgents. Could you please advise on the recommended Apple-supported approaches for this use case ? Specifically, Is there a supported way for a system daemon to generate and use an unremovable Secure Enclave key during phases like the pre-logon, that doesn't have non user context (only the my application which created this key/certificate will have permission to use/delete it) If Secure Enclave access from a daemon is not supported, what Apple-recommended alternatives exist for providing a hardware-backed machine identity for system daemons? I'd rather avoid using system keychain, as its contents may be removed or used by root privileged users. The ideal solution would be that each Apple product, would come out with a non removable signing certificate, that represent the machine itself (lets say that the cetificate name use to represent the machine ID), and can be validated by verify that the root signer is "Apple Root CA"

Hi Team, We are trying to understand deep sleep behaviour, can you please help us clarifying on the below questions: When will we configure Hibernate 25, is it valid for M series MacBooks? Is Hibernate 25 called deep sleep mode? What are the settings I need to do on Mac, to make my Mac go in to deep sleep? When awakening from deep sleep , what would be macOS system behaviour? If we have custom SFAuthorization plug in at system.login.screensaver, what would be the behaviour with deep sleep?

I recently turned on the enhanced security options for my macOS app in Xcode 26.0.1 by adding the Enhanced Security capability in the Signing and Capabilities tab. Then, Xcode adds the following key-value sets (with some other key-values) to my app's entitlements file. <key>com.apple.security.hardened-process.enhanced-security-version</key> <integer>1</integer> <key>com.apple.security.hardened-process.platform-restrictions</key> <integer>2</integer> These values appear following the documentation about the enhanced security feature (Enabling enhanced security for your app) and the app works without any issues. However, when I submitted a new version to the Mac App Store, my submission was rejected, and I received the following message from the App Review team via the App Store Connect. Guideline 2.4.5(i) - Performance Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issue before resubmitting a new binary. Entitlement "com.apple.security.hardened-process.enhanced-security-version" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions" value must be boolean and true. When I changed those values directly in the entitlements file based on this message, the app appears to still work. However, these settings are against the description in the documentation I mentioned above and against the settings Xcode inserted after changing the GUI setting view. So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions?

Hi, I am using CryptoKit in my app. I am getting an error sometimes with some users. I log the description to Firebase but I am not sure what is it exactly about.  CryptoKit.CryptoKitError error 2  CryptoKit.CryptoKitError error 3 I receive both of these errors. I also save debug prints to a log file and let users share them with me. Logs are line-by-line encrypted but after getting these errors in the app also decryption of log files doesn't work and it throws these errors too. I couldn't reproduce the same error by myself, and I can't reach the user's logs so I am a little blind about what triggers this. It would be helpful to understand what these errors mean. Thanks

Hi Apple Team and Community, We encountered a sudden and widespread failure related to the App Attest service on Friday, July 25, starting at around 9:22 AM UTC. After an extended investigation, our network engineers noted that the size of the attestation objects received from the attestKey call grew in size notably starting at that time. As a result, our firewall began blocking the requests from our app made to our servers with the Base64-encoded attestation objects in the payload, as these requests began triggering our firewall's max request length rule. Could Apple engineers please confirm whether there was any change rolled out by Apple at or around that time that would cause the attestation object size to increase? Can anyone else confirm seeing this? Any insights from Apple or others would be appreciated to ensure continued stability. Thanks!

Hello, I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure. I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work. When the system warning box pops up, I can see some error log information through the console application, including an error related to Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179) as shown in the screenshot. The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution

Dear Apple Developer Support Team, We are experiencing a recurring issue with the DeviceCheck API where the following error is being returned: com.apple.devicecheck.error 0 Upon analyzing our logs, we have noticed that this error occurs significantly more often when users are connected to Wi-Fi networks, compared to mobile networks. This leads us to suspect that there might be a relationship between Wi-Fi configuration and the DeviceCheck service’s ability to generate or validate tokens. We would like to know: Is this error code (0) known to be caused by specific types of network behavior or misconfigurations on Wi-Fi networks (e.g., DNS filtering, firewall restrictions, proxy servers)? Are there any recommended best practices for ensuring reliable DeviceCheck API communication over Wi-Fi networks? Additionally, could you please clarify what general conditions could trigger this com.apple.devicecheck.error 0? The lack of specific documentation makes debugging this issue difficult from our side. Any guidance or internal documentation on this error code and its potential causes would be greatly appreciated. IDE: Xcode 16.3 Looking forward to your support. Best regards,

While I was submitting a new feedback today for an iPhone/iPad storage issue, I saw a new log called “iOS storage log”. I could find no reference to this when I searched online. It made me wonder if it was new and if it contained personal data? Most of us only have one device, with all our personal data. Therefore, I’d appreciate any input on what personal data these logs contain.

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

I am developing a background program that is included in the app as an extension. I would like to include logic to check the teamID and code signature validity of the program I created to ensure that it has not been tampered with. Is this possible?

Hello! I do know apple does not support electron, but I do not think this is an electron related issue, rather something I am doing wrong. I'd be curious to find out why the keychain login is happenning after my app has been signed with the bundleid, entitlements, and provision profile. Before using the provision profile I did not have this issue, but it is needed for assessments feature. I'm trying to ship an Electron / macOS desktop app that must run inside Automatic Assessment Configuration. The build signs and notarizes successfully, and assessment mode itself starts on Apple-arm64 machines, but every single launch shows the system dialog that asks to allow access to the "login" keychain. The dialog appears on totally fresh user accounts, so it's not tied to anything I store there. It has happened ever since I have added the provision profile to the electron builder to finally test assessment out. entitlements.inherit.plist keys &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; entitlements.plist keys: &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.automatic-assessment-configuration&lt;/key&gt; &lt;true/&gt; I'm honestly not sure whether the keychain is expected, but I have tried a lot of entitlement combinations to get rid of It. Electron builder is doing the signing, and we manually use the notary tool to notarize but probably irrelevant. mac: { notarize: false, target: 'dir', entitlements: 'buildResources/entitlements.mac.plist', provisioningProfile: 'buildResources/xyu.provisionprofile', entitlementsInherit: 'buildResources/entitlements.mac.inherit.plist', Any lead is welcome!

Is there any particular reason why ASWebAuthenticationSession doesn't have support for async/await? (example below) do { let callbackURL = try await webAuthSession.start() } catch { // handle error } I'm curious if this style of integration doesn't exist for architectural reasons? Or is the legacy completion handler style preserved in order to prevent existing integrations from breaking?

We are using ASWebAuthenticationSession with apps on IoS to achieve SSO between apps. The IdP for authentication (OIDC) is an on-premise and trusted enterprise IdP based on one of the leading products in the market. Our problem is that the user is prompted for every login (and logouts) with a consent dialogue box: “AppName” wants to use “internal domain-name” to Sign In This allows the app and website to share information about you. Cancel Continue” I have read in various places that Apple has a concept of “Trusted domains” where you can put an “Apple certified” static web-page on the IdP. This page needs to contain specific metadata that iOS can verify. Once a user logs in successfully a few times, and if the IdP is verified as trusted, subsequent logins would not prompt the consent screen. Question: I struggle to find Apple documentation on how to go about a process that ends with this “Apple certified web-page” on our IdP”. Anyone who has experience with this process, or who can point me in some direction to find related documentation?

Issue Summary I'm encountering a DCError.invalidInput error when calling DCAppAttestService.shared.generateAssertion() in my App Attest implementation. This issue affects only a small subset of users - the majority of users can successfully complete both attestation and assertion flows without any issues. According to Apple Engineer feedback, there might be a small implementation issue in my code. Key Observations Success Rate: ~95% of users complete the flow successfully Failure Pattern: The remaining ~5% consistently fail at assertion generation Key Length: Logs show key length of 44 characters for both successful and failing cases Consistency: Users who experience the error tend to experience it consistently Platform: Issue observed across different iOS versions and device types Environment iOS App Attest implementation Using DCAppAttestService for both attestation and assertion Custom relying party server communication Issue affects ~5% of users consistently Key Implementation Details 1. Attestation Flow (Working) The attestation process works correctly: // Generate key and attest (successful for all users) self.attestService.generateKey { keyId, keyIdError in guard keyIdError == nil, let keyId = keyId else { return completionHandler(.failure(.dcError(keyIdError as! DCError))) } // Note: keyId length is consistently 44 characters for both successful and failing users // Attest key with Apple servers self.attestKey(keyId, clientData: clientData) { result in // ... verification with RP server // Key is successfully stored for ALL users (including those who later fail at assertion) } } 2. Assertion Flow (Failing for ~5% of Users with invalidInput) The assertion generation fails for a consistent subset of users: // Get assertion data from RP server self.assertRelyingParty.getAssertionData(kid, with: data) { result in switch result { case .success(let receivedData): let session = receivedData.session let clientData = receivedData.clientData let hash = clientData.toSHA256() // SHA256 hash of client data // THIS CALL FAILS WITH invalidInput for ~5% of users // Same keyId (44 chars) that worked for attestation self.attestService.generateAssertion(kid, clientDataHash: hash) { assertion, err in guard err == nil, let assertion = assertion else { // Error: DCError.invalidInput if let err = err as? DCError, err.code == .invalidKey { return reattestAndAssert(.invalidKey, completionHandler) } else { return completionHandler(.failure(.dcError(err as! DCError))) } } // ... verification logic } } } 3. Client Data Structure Client data JSON structure (identical for successful and failing users): // For attestation (works for all users) let clientData = ["challenge": receivedData.challenge] // For assertion (fails for ~5% of users with same structure) var clientData = ["challenge": receivedData.challenge] if let data = data { // Additional data for assertion clientData["account"] = data["account"] clientData["amount"] = data["amount"] } 4. SHA256 Hash Implementation extension Data { public func toSHA256() -> Data { return Data(SHA256.hash(data: self)) } } 5. Key Storage Implementation Using UserDefaults for key storage (works consistently for all users): private let keyStorageTag = "app-attest-keyid" func setKey(_ keyId: String) -> Result<(), KeyStorageError> { UserDefaults.standard.set(keyId, forKey: keyStorageTag) return .success(()) } func getKey() -> Result<String?, KeyStorageError> { let keyId = UserDefaults.standard.string(forKey: keyStorageTag) return .success(keyId) } Questions User-Specific Factors: Since this affects only ~5% of users consistently, could there be device-specific, iOS version-specific, or account-specific factors that cause invalidInput? Key State Validation: Is there any way to validate the state of an attested key before calling generateAssertion()? The key length (44 chars) appears normal for both successful and failing cases. Keychain vs UserDefaults: Could the issue be related to using UserDefaults instead of Keychain for key storage? Though this works for 95% of users. Race Conditions: Could there be subtle race conditions or timing issues that only affect certain users/devices? Error Recovery: Is there a recommended way to handle this error? Should we attempt re-attestation for these users? Additional Context & Debugging Attempts Consistent Failure: Users who experience this error typically experience it on every attempt Key Validation: Both successful and failing users have identical key formats (44 character strings) Device Diversity: Issue observed across different device models and iOS versions Server Logs: Our server successfully provides challenges and processes attestation for all users Re-attestation: Forcing re-attestation sometimes resolves the issue temporarily, but it often recurs The fact that 95% of users succeed with identical code suggests there might be some environmental or device-specific factor that we're not accounting for. Any insights into what could cause invalidInput for a subset of users would be invaluable.

we can get token but when send to verity from apple. it reture Error : {"responseCode":"400","responseMessage":"Missing or incorrectly formatted device token payload"}

What Has Been Implemented Replaced the default loginwindow:login with a custom authorization plugin. The plugin: Performs primary OTP authentication. Displays a custom password prompt. Validates the password using Open Directory (OD) APIs. Next Scenario was handling password change Password change is simulated via: sudo pwpolicy -u robo -setpolicy "newPasswordRequired=1" On next login: Plugin retrieves the old password. OD API returns kODErrorCredentialsPasswordChangeRequired. Triggers a custom change password window to collect and set new password. Issue Observed : After changing password: The user’s login keychain resets. Custom entries under the login keychain are removed. We have tried few solutions Using API, SecKeychainChangePassword(...) Using CLI, security set-keychain-password -o oldpwd -p newpwd ~/Library/Keychains/login.keychain-db These approaches appear to successfully change the keychain password, but: On launching Keychain Access, two password prompts appear, after authentication, Keychain Access window doesn't appear (no app visibility). Question: Is there a reliable way (API or CLI) to reset or update the user’s login keychain password from within the custom authorization plugin, so: The keychain is not reset or lost. Keychain Access works normally post-login. The password update experience is seamless. Thank you for your help and I appreciate your time and consideration