Hey all, so I currently have a passkey provider application on iOS that works for every RP except for google. I found this post here saying the AttestationObject needs to be an ordered dictionary and can confirm on https://webauthn.me/debugger that my object is an ordered dictionary in the correct format. However, google fails to create the key every time saying generically the passkey can't be saved at this time. I'm just curious if there is something unique about google, like are they maybe whitelisting providers? Or do they require something extra that I need to send? I can't find any other information for why google wouldn't work while everyone else does. Thanks in advance for any help!

We develop SDKs that are distributed as XCFramework to our clients. We seek clarification regarding the necessity of attaching a Privacy Manifest, especially in instances where our SDK does not interact with data that would typically be covered under such a manifest. Additionally, in the scenario where our SDK's primary function is the transmission and reception of data, which may potentially include personal data, are we required to declare in the Privacy Manifest that we handle personal information? This query persists even when all personal data processing is executed on the server side. From our current understanding, based on the information available at https://developer.apple.com/support/third-party-SDK-requirements/, it appears that SDKs are only obligated to have a signature, and incorporating a Privacy Manifest may not be compulsory. We would appreciate further insight or confirmation on this matter.

For example my app is using Firebase and Alamofire. Still I could find the Manifest files for the above SDKs. What would be impact on app if the above api's is not updated with their Manifests.

Apple documentation is specific about the possible types of email_verified property A string or Boolean value that indicates whether the service verifies the email. The value can either be a string ("true" or "false") or a Boolean (true or false). The system may not verify email addresses for Sign in with Apple at Work & School users, and this claim is "false" or false for those users. Actually we made a mistake by supporting only String type and today had the very bad surprise to notice that we started receiving Bool types for the first time. Do you have any info about changes on the API ? Thanks Julien

Hi Team, 

I am developing a sample authPluggin which should connect to a mobile app via bluetooth connection, 
So here are the scenario

 Authplugin with Bluetooth connection shoould work on lockscreen+login 

I have created mechanism- prepared:privillaged, main, clean:Privilaged Calling corebluetoothmanager initiation at the time of prepared:privilaged mechanism I have to add my auth plugin’s mechanism before loginwindow:success mechanism

 But I always gets unauthorized = 3, from power state of bluetooth

 Note: With App, bluetooth connection is working fine, Its giving error with authPlugin How to achieve my ultimate goal, is this the right way?

Hello, I am creating this post to ask if there is any plan for bringing the Attestation Service support for macOS or any plans for supporting it in macOS. We implemented it in iOS and it increased the security for our users and partners but we are evaluating deprecated macOS and keeping only Windows and linux because of this restriction on the Attestation Service... if you recommend any other provider to attest the device please bring me some recommendations.

Are a privacy manifest and signature required for any SDKs other than those listed on the following page? https://developer.apple.com/jp/support/third-party-SDK-requirements/ We integrate the LINE SDK for Unity (https://developers.line.biz/ja/docs/line-login-sdks/unity-sdk/overview/) in our apps. LINE SDK for Unity uses an API corresponding to the Required Reason API on the following page. https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api Can you please let us know whether a privacy manifest and signature are required for this third-party SDK as well? Thank you in advance for your attention to this matter.

Our company has a library that can be used internally. This is being used as a .a file. The languages are in C and C++. C code contains stat. Is this the same stat as Apple refers to?? How do you solve this??

I am encountering an issue with accessing the system keychain on macOS [macOS 13.6.3]. When running our product, the following error message is logged: [com.apple.securityd:secitemratelimit] Not internal release, disabling SIRL [com.apple.securityd:keychain] System Keychain Always Supported set via feature flag to disabled As a result, our product is unable to access the system keychain, which is impacting functionality. Note: In many other devices this issue is not seen. Steps to Reproduce: The moment pkg is installed it creates a key in keychain. For an affected device SecItemCopyMatching is returning errSecInteractionNotAllowed Question: Is there a way to enable the system keychain access or address the issue with the feature flag being disabled? Are there any suggestions or recommendations for handling this case? Any assistance or guidance on resolving this issue would be greatly appreciated. Thank you in advance for your help.

How to make an APP offer to save access credentials in the iCloud keychain

Hello, I have questions regarding the Privacy Manifest compliance, If I am using an third party SDK's, listed in the document should have their own manifest file? Or in our app manifest we can include the details collected by the SDK's if the SDK's doen't have their manifest file? Do we have any other options if the listed SDK's doesn't conatins the manifest file, can handle with our application manifest? Thanks!

In my project, I am using a third-party SDK called "SwiftyJSON" which is not maintained or updated since April 2019. So in such cases where the third-party SDKs are not updated with a PrivacyInfo.xcprivacy will it affect the app release in Appstore or in such cases is there any way to bypass non-maintained SDK?

Hi, I'm looking for best practices for unlocking TouchID in a Mac app when using canEvaluatePolicy. Documentation says: Biometric authentication will get locked after 5 unsuccessful attempts. After that, users have to unlock it by entering their account password. The password can be entered either at login window or in the preference sheets or even in application by the means of LAPolicyDeviceOwnerAuthentication. The system unlock is preferred user experience because we generaly don't want users to enter their account password at application's request. So if we shouldn't manage Mac's password in the app, how to invite user to unlock ? Explaining he must lock/unlock the session or open any preference panel isn't a fluent experience and would definitely seems weird. I tried adding an 'Unlock' button in an alert and locking the screen automatically but this raises extras complexities: pmset can put the screen to sleep but won't lock in case of grace period sending an cmd-ctl-Q AppleEvent to System Events could fit but it depends on user acceptance for AEs and fails when System Events isn't running. Any ideas ?

The type of the email_verified (standard) claim is STRING. According to the specification [1] it should be BOOLEAN. Current Example Returned by Apple: "email_verified": "true" OpenID Standard Should Ve: "email_verified": true [1]openid.net/specs/openid-connect-core-1_0.html#StandardClaims

Hello, I am going to use endpoint security framework in my application. Unfortunately, I have not found any clear cut explanation about how to use endpoint security in multithread applications. Can we say the handler block (es_handler_block_t), which is the parameter of es_new_client(), is running in separate thread? Does es_new_client() create new thread? Should I synchronize a handler block and the code which calls es_delete_client()? Should I protect the handler block by mutex? Thank you in advance.

Apple will enforce Privacy Manifest starting this spring. Apple said it would inform you through e-mail before then. I think a lot of developers should have already received mail. But it's harder to find mail-related content than I thought. Has anyone received an email? If so, what is it about??

Hi everyone, We are building an application on macOS (and iOS) that can install client certificates for mTLS handshake. This part is working great and the certificates are imported into login keychain. The problem comes when a user tries to use those certificates from the browser. Then he is presented with the Keychain access dialog to be able to use the private key from the installed certificate. We would like to hide this dialog so that the user flow is as streamlined as possible. We succeeded in hiding the Keychain dialog in Safari by importing the private key with a flag that allows all applications access to it. This is enough for Safari since Apple applications are part of the key's partition list by default. This, however, doesn't work for, e.g., Chrome. We've experimented with calling the security set-key-partition-list command, but that still requires the Keychain password (shows the dialog) and it seems impossible to select just our private key with it. So my question is, how can we hide the Keychain dialog when using our certificate from Chrome? Would maybe working with the Objective-C methods SecKeychainItemSetAccess or the newer SecItemUpdate allow us to set the partition-list without a Keychain dialog window? Is there another option that doesn't set the key partition list? Best regards, Marek Vinkler

If my app utilizes ASWebAuthenticationSession or SFSafariViewController, do I need to add all potential tracking domains that users may access within the session? There is virtually no way to limit the URLs or domains that users can access within the ASWebAuthenticationSession or SFSafariViewController, so how can I know all the potential domains?

If someone in Apple WWDR sees this, please take the feedback to heart and report it up the chain: When you announce that a technology is being deprecated — such as CGDisplayStream — and also publish WWDC sessions about the intended replacement — ScreenCaptureKit — then you also need to give third-party developers a clear deadline by which this technology will be deprecated so that they can plan engineering efforts around implementing the new feature, and have ample time to communicate this to their customers. If it's important for third-party developers to get on board with this change, you should use every available means to communicate this to them, including multiple email alerts to their registered email address. Additionally, if you plan to make a BREAKING change in a framework that results in a wildly different user experience, you should probably hold that off until the summer release for the next major OS. What you should definitely NOT do is roll out a new privacy prompt in a mid-year release of macOS; or give your developers, customers, and AppleSeed program participants zero advance notice that this alert is coming, ignore your own Human Interface Guidelines when designing said prompt, and perform no user experience design testing (aka "putting on your customer hat") during a presumed internal alpha testing cycle to refine the experience and still find the most effective and least annoying way to present this additional prompt and spur change with your third-party developers. Oh, wait, you've done exactly all those things the wrong way with respect to ScreenCaptureKit. Right now, a host of Apple device administrators and client platform engineers are sending mountains of feedback to you, and they're also scrambling to contact third-party developers to let them know this is coming. Most of the vendors being discussed in private forums are said to be caught off guard by this change. We anticipate that users are not going to like this, and there is no way we can manage it with MDM or configuration profiles. In short, the current experience is a ghastly mess. WE, the administrators, will get blamed for this, not the third-party developers. WE will have to explain to our leadership why this experience is terrible and cannot be managed. Engineers need deadlines to help plan their work and prioritize tasks. In this case, vendors have had no firm deadline for this effort. There's already precedence for Apple announcing estimated deadlines for deprecations and feature removals. You do your developers and customers a great disservice by not communicating schedules to them. Please do better. P.S.: Feedback filed as FB13619326.

I'm following the steps outlined to be able to email users that have used Apple Sign-in that is listed here and I have a green check for SPF status. I used my email <my_email_here>@gmail.com, but when I try to send an email from the email address configured to the private relay email I don't see my test email coming through. I also tried sending an email from a non configured email and I don't back any sort of error message, not sure if I should though. Is there a delay in how quickly the email is received?