User Profile

Hi, I'm currently trying to generate and store Private Key and protect this key with Local Authentication using Security framework (not CryptoKit; unfortunately, needed to support below iOS 13 still). To be more precise, I am trying to generate Secure Enclave private key protected by local authentication (using access control with biometryAny), but I'm not able to trigger Local Authentication when retrieving the key. Secure Enclave key is successfully generated (that I confirmed), and I also confirmed that if I create a key without kSecAttrTokenID, exactly same code triggers the Local Authentication when reading the generated key. Following is what I'm doing in my code: // Key generation query var query = [String: Any]() query[String(kSecAttrKeyType)] = String(kSecAttrKeyTypeEC) query[String(kSecAttrKeySizeInBits)] = 256 query[String(kSecAttrAccessGroup)] = "accessGroup" query[String(kSecAttrTokenID)] = String(kSecAttrTokenIDSecureEnclave) // Key Attributes var keyAttr = [String: Any]() keyAttr[String(kSecAttrIsPermanent)] = true keyAttr[String(kSecAttrApplicationTag)] = "applicationTag" let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, nil)! keyAttr[String(kSecAttrAccessControl)] = accessControl query[String(kSecPrivateKeyAttrs)] = keyAttr // Generate Key var error: Unmanaged<CFError>? let privateKey = SecKeyCreateRandomKey(query as CFDictionary, &error) If I remove "query[String(kSecAttrTokenID)] = String(kSecAttrTokenIDSecureEnclave)" this line of code which basically tells the system to generate the key using Secure Enclave, when retrieving the generated key, it triggers the Local Authentication, but with that Secure Enclave flag, Local Authentication is never triggered. Is it not triggering the local authentication because the Secure Enclave key already protected with same level of security? or am I missing something here? By the way, I tried with .userPresence and .biometryCurrentSet for Secure Enclave, but still had no luck.. :( Any advice would be greatly appreciated. Thanks,

I'm currently testing SWIA implementations, and found some interesting behavior related to scope in the authorization flow. Situation that I'm facing right now is: User signs in with his/her Apple Id through the mobile app's or website's SWIA feature for the vert first time without email scope. User will be granted JWT without email claim as expected. Later, we changed to add email scope for the authorization process. User (from #1) signs in again, and goes through SWIA with email scope User will be granted JWT without email claim Unless otherwise user manually de-authorize the app from their Apple ID portal (or in the mobile app), updated scope will not be reflected It also happens in the opposite way (i.e. having email scope for the very first request, and then later remove email scope. This will still grant JWT with email claim) Is this something expected from Apple's OIDC server? or am I doing something wrong? I've tested it with both native iOS SWIA and on the web client as well, and both produce the same result. Not quite sure if this is as per OIDC specification. Any insight or help would be greatly appreciated.

In regards to Apple Developer Program License Agreement, section 3.3.9, it says that the app may not collect user or device data without prior user consent ... I would like to clarify whether or not this is only applicable for advertising purpose or applies to all of the apps submitted to App Store. I use similar techniques for security purpose as part of the authentication journey in the mobile application to collect some information like device model, OS version, locale, timezone, location information and etc, but not IDFA. And I do not generate a unique identifier based on the collected information, and just generate the identifier based on my own logic (combined with device vendor identifier). Of course, with all the information that I'm collecting, I adhere the privacy consent setting as per those APIs requirement (such as location, or BLE usage). I am not sure whether this section 3.3.9 was newly introduced as part of Apple's effort to increase security of user information that will be released in the next iOS version (together with IDFA). But would like to see if such activity that I'm doing would also be flagged and will eventually be rejected. Any thoughts?

Hi,I have a question in regards to iOS privacy setting with camera, location, BLE, and etc in the application's info.plist.To get to the point, I am building framework for iOS application, and within the framework, there are some features check authorization status of location / BLE / camera, and if the permission is granted, framework's code is invoking iOS APIs requesting location information, to access BLE, and Camera.The question is, as I'm building framework, and these privacy setting in info.plist is set in the application layer, let's say that app developer don't use those features within my framework invoking location APIs, and/or BLE APIs, and don't declare the privacy consent in their app's info.plist.In that case, even if the app itself is not explicitly invoking, or using those APIs, and none of their application code uses those feature, because that the app has my framework which contains set of code invoking those APIs, will the app be rejected in the app store review process for not having the privacy consent in info.plist?By simply having set of code invoking those APIs, should the app have to define the settings? or does the app actually have to invoke and use those APIs?Thanks,