Greetings, I've working lately with webauthn navigator feature in order to make users registrations and logins with Touch ID or any other sign option that the device might offer. To give a quick context: in my webapp I register users using username + webauthn and store their credentials.id from navigator.credentials.create() and generate a pubKey that it's being store at local storage and in our DB, which is the same for the credential.id. Despite the fact that I can use my device to use my webapp after the creation of this account and using navigator.credentials.get() I'm able to log with my account with no problem but, if I go to settings > safari > clear all browser data & history I can end up destroying my access to my webapp, even though that I have the credentials on my server. Is this an expected behaviour? If I do the same on different devices, this does not happen, in fact accounts are able to log even if the browser does not have data anymore, since it only removes the browser data and not the Credential Manager data. Also, for Mac devices these keys are only accessible per browser, which mean that I have to link those different browsers as secondary devices so the user can login at any browser that they have on their device. Is this expected?

When trying to build an AR app to my Iphone 11 with Xcode (13.2.1) using Mac OS 12.1 the build fails. Codesign wants me to use the Apple Development keychain. No matter which password I use it fails.

The project uses keychain to store data. When kSecAttrAccessible is set to kSecAttrAccessibleAfterFirstUnlock or this property is not set, Apple backs up the system and restores it to the new machine. Will the data stored in the keychain be transferred to the new machine? Will the data in UserDefault be additionally transferred to the new machine?

Regarding the beta feature of storing WebAuthn passkeys in the iCloud Keychain, does anybody know if the unencrypted passkeys ever leave the secure enclave, getting stored in RAM or anything? With traditional WebAuthn on a Yubikey or similar device, my understanding is that the private key never leaves the Yubikey, that the requester just inputs the ID of the passkey they'd like to use and supplies a challenge to sign to the Yubikey, and the Yubikey spits out the signed challenge. That way, even if an attacker has root access to your machine, they still can't get that passkey. I'm hoping it works a similar way for iCloud Keychain passkeys: that the encrypted passkey and the challenge are fed to the secure enclave, which then decrypts the encrypted passkey, and then uses it to sign the challenge and then spits out the result, all with the unencrypted passkey never leaving the secure enclave. But I can't find anything definitively stating this. Anyone know for sure / have sources to back it up?

Hi -- my company built an internal macOS app using the SwiftyDropbox toolkit, which has been working fine... with the one oddity that since we started installing it on Monterey, on some machines (not all) on first run it now asks for permission for keychain access (for the Dropbox token). The bundle ID and so forth are correct; that's not the problem. The issue is just, how is it possible to pre-approve this keychain access? (It's clearly possible, since the dialog never appears on some machines.) Can it be allowed as part of the installer process, after the Administrator password is entered? Or at the very least, is it possible to request access for the app at that point, rather than later when the app is actually run?

Hey Apple-Community, Safari is currently asking to autofill a password for the current domain, is it possible to force Safari asking for an explicit other one? Example User visits https://exaple.com now Apple shows password for the website https://exaple.com but the user has the same password on this website like on https://other.net so Safari should be forced to list up https://other.net passwords on https://exaple.com login form. Thanks for helping me out. Jorit Vásconez Gerlach

The call stack is followed: Incident Identifier: 5DBD18B5-29DD-48E1-8BE5-A648BD4E8CE3 CrashReporter Key: 4006fd6d63831c08be5068429b9892f633d41735 Hardware Model: iPhone12,5 Process: *** Path: /private/var/containers/Bundle/Application/FD114B6F-9C45-4546-9924-082A2CF546B8/***.app/*** Identifier: com.***.*** Version: 2.0.0 (2.0.0.3) AppStoreTools: 13A227 AppVariant: 1:iPhone12,5:13 Code Type: ARM-64 (Native) Role: Unspecified Parent Process: launchd [1] Coalition: com.***.*** [2761] Date/Time: 2021-09-28 14:24:03.8329 +0800 Launch Time: 2021-09-28 14:24:03.5890 +0800 OS Version: iPhone OS 15.0 (19A346) Release Type: User Baseband Version: 3.00.00 Report Version: 104 Exception Type: EXC_GUARD Exception Subtype: GUARD_TYPE_USER Exception Message: namespc 18 reason_code 0x0000000000000002 Exception Codes: 0x6000000000000012, 0x0000000000000002 Exception Note: SIMULATED (this is NOT a crash) Termination Reason: LIBSYSTEM; [2] Thread 3: Crashed 0 libsystem_kernel.dylib 0x1b80a2ae8 os_fault_with_payload + 7382641384 ((null)) 1 libsystem_trace.dylib 0x000000019bd941b4 _os_log_impl_flatten_and_send + 6909673908 ((null)) 2 libsystem_trace.dylib 0x000000019bd90b70 _os_log + 6909660016 ((null)) 3 libsystem_trace.dylib 0x000000019bd98cac _os_log_fault_impl + 6909693100 ((null)) 4 SyncedDefaults 0x1ad034c90 -[SYDRemotePreferencesSource initWithApplicationID:storeID:shared:additionalSource:containerPath:storeType:].cold.1 + 52 5 SyncedDefaults 0x1ad027210 -[SYDRemotePreferencesSource initWithApplicationID:storeID:shared:additionalSource:containerPath:storeType:] + 1400 6 Foundation 0x182ff5d58 -[NSUbiquitousKeyValueStore initWithBundleIdentifier:storeIdentifier:additionalStore:storeType:] + 348 7 Foundation 0x182fd8e84 __41+[NSUbiquitousKeyValueStore defaultStore]_block_invoke + 24 8 libdispatch.dylib 0x000000018140194c _dispatch_client_callout + 6463428940 ((null)) 9 libdispatch.dylib 0x00000001814031d4 _dispatch_once_callout + 6463435220 ((null)) 10 Foundation 0x182fe0668 +[NSUbiquitousKeyValueStore defaultStore] + 64 ... // omit insignificant call stack of the app 14 libdispatch.dylib 0x00000001813ffc00 _dispatch_call_block_and_release + 6463421440 ((null)) 15 libdispatch.dylib 0x000000018140194c _dispatch_client_callout + 6463428940 ((null)) 16 libdispatch.dylib 0x0000000181413064 _dispatch_root_queue_drain + 6463500388 ((null)) 17 libdispatch.dylib 0x0000000181413764 _dispatch_worker_thread2 + 6463502180 ((null)) 18 libsystem_pthread.dylib 0x00000001f12c5170 _pthread_wqthread + 8341180784 ((null)) 19 libsystem_pthread.dylib 0x00000001f12c4f4c start_wqthread + 8341180236 ((null)) What's mean the Exception Note: SIMULATED (this is NOT a crash)? It's not a crash? And then, is it possible a bug in iOS 15？because no crash reports before iOS 15. Thanks.

After upgrading to iOS 15, when I open the app after a couple of hours, we are not able to retrieve keychain data in didFinishLaunchingWithOptions delegate method. For each new launch we are facing the same issue of of not retrieving keychain data. We need to relogin to process further in the application. But for iOS 14 and below we are not facing this issue, we are able to retrieve the keychain data in didFinishLaunchingWithOptions delegate. Is anyone facing the same issue in their application?

I'm the IMAP maintainer for Mozilla Thunderbird. I've been looking into adding QRESYNC imap extension to Thunderbird which currently only supports CONDSTORE extension. The icloud server returns these in its capabilities response: CONDSTORE ENABLE QRESYNC indicating complete support for enabling CONDSTORE and QRESYNC. But when I try to enable them, I get no "ENABLED" untagged response as required by imap ENABLE rfc: Tbird sends: 33 ENABLE CONDSTORE QRESYNC UTF8=ACCEPT icloud sends: 33 OK ENABLE completed The correct imap ENABLED response is like this: Tbird sends: 33 ENABLE CONDSTORE QRESYNC UTF8=ACCEPT icloud sends: * ENABLED CONDSTORE QRESYNC icloud sends: 33 OK ENABLE completed Since icloud doesn't support the UTF8=ACCEPT imap extension, it should just be excluded from the untagged ENABLED response. Several other imap servers I've tested (Dovecot, Cyrus and Zimbra) respond correctly when Thunderbird attempts the ENABLE but icloud responds in a non-standard manner. There are other problems too with the icloud response to imap SELECT with the QRESYNC parameter in that it produces an imap FETCH response for all messages in the folder with a sequence number of minus 1 (sequence numbers are supposed to be positive, 1 to number of messages in folder, never negative). Note: This seems to require a tag. Couldn't find one relevant to my question so just picked one with "icloud" in name.

Hi Developers, I am wondering how is it possible for other smartphone-based FIDO authenticators to use the same iCloud Keychain storage as Passkey does so those credentials can be used on non-apple devices too, and also on the smartphone at the same time. There are some other iOS authenticators that have implemented BLE and are working on all devices including Windows, but the problem is that those apps cannot support signing in to the website on the smartphone itself (neither in apps nor inside the browser) using the previously registered credential of 'cross-platform' type.

I saved my customized identifier into the KeyChain on iOS.It will be shared in devices that using the same appleid? I've tryed with three iPhones, they are diffrent device type.I use my appleid to Login in iCloud.First step, I save one customized identifer by objective-c codes.Then debug on the other iPhones,but i can't get the identifer that saved in the first iPhone. But my some users found that they use a new iOS device,their new devices can use the old customized identifier directly while they use thire appleid to active new device.I need to know why?

Hey! This is my first question on the developer forums so please bare with me incase I'm doing something wrong. To cut to the chase, my team recently updated their iOS devices to iOS 15 and we've encountered a strange issue. If our app is left backgrounded for a while (couple of hours), KeychainStorage is clearing out the stored values. We've confirmed this only happens on iOS 15+ devices since users with iOS 14 are not facing any issues. We are storing the access token/refresh token of the user in Keychain and basically, if the user doesn't open the app for a while, they automatically get logged out (definitely not a nice UX). I've checked online, and many people were suggesting that Keychain data requires time to be decrypted but I made sure I'm not accessing the data prior to the decryption. Also, I made sure that nothing is called before didFinishLaunchingWithOptions. Our kSecAttrAccessible is set to kSecAttrAccessibleWhenUnlockedThisDeviceOnly if that's of any use. I've seen other posts regarding this issue but all other cases seemed to be resolved by waiting for a notification that data became available, again, I'm not facing that problem. If any more info is required, please let me know and I'll be sure to reply ASAP.

When I open the app after a couple of hours, all of. the app data is getting wiped out (UserDefaults, keychain password). I'm on iOS 15 public beta 3. Has anyone faced similar issue, or how to debug and get it fixed?

Hello. Since I updated the system to Monterey 12.0.1, my Microsoft apps and Chrome/Safari navigator doesn't allow me to select a third party certificate from the Keychain when access to a LDAP. I mean, the window to select certificate to enter isn't appear. It gets stucked in the screen to select certificate.

Hello, some of our users are facing a problem after the update on iOS 15. The app stores some sensitive information in keychain. Everything works properly when app is in foreground and moreover when the user is active with this across a short time frame. However they complain that after some time (random time) that app is in background and they return to it, it has lost the keychain items and the app asks for a new registration. Moreover we don’t do anything before didFinishLaunching. We also tried some other approaches that are proposed to some other threads in order to move some code that is related with user defaults or keychain in applicationProtectedDataDidBecomeAvailable but the issue wasn’t fixed. The app in prior to iOS 15 versions works as expected without any problems. Is there anything else that we can do? Thank you in advance.