Thanks @KivancG, I was also affected by this issue, your answer helped. Have you submitted a feedback? Xref (probably the same issue) https://developer.apple.com/forums/thread/679098?answerId=673107022

Hi @mervyn.ong, If I am not mistaken, for security reasons, the file is not accessed or validated by the device, but Apple backend infrastructure (CDN) as such the file must be accessible via the internet. There is a way to temporarily tweak this behaviour by using query parameter ?mode= during development, it's nicely explained in the documentation https://developer.apple.com/documentation/xcode/supporting-associated-domains.

I had CFBundleName set to $(PRODUCT_NAME), but no CFBundleDisplayName as the name inferred by Xcode from the bundle identifier seemed to be enough. I explicitelly set CFBundleDisplayName and now the messaging includes the display name, no more "". Thank you very much!

It means the user needs to interact with the website via gesture, e.g. touch. It's nicely explained on https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/. Something like this should work: function login() { // use navigator.credentials.get  } document.addEventListener("DOMContentLoaded", e => { document.querySelector('#login-button').addEventListener('click', login); }

Thank you both. I am aware of DriverKit, however, the tool I am signing is coming from our vendor, and as you can imagine, my influence is slightly limited : ). I will send them a reminder about the future of KEXT in case they've missed it.

We've encountered the same problem. @spindel, have feedback/DTS helped you find the root cause of the issue and if so do you mind sharing your findings here?

Thanks @eskimo, we used to use .biometryCurrentSet (for internal users in the beta phase long before making the app available in AppStore), but stopped when "Face ID with a Mask" was introduced as it was invalidating the enrollments. Current set of flags: let access = SecAccessControlCreateWithFlags( kCFAllocatorDefault,     kSecAttrAccessibleWhenUnlockedThisDeviceOnly,     [.privateKeyUsage, .biometryAny],     nil )

Many thanks @eskimo for the very insightful and honest answer. In the latest 30 days the issue affected ~0.05% of our users, it's a fraction of the whole population, but still a significant number. We will try to add some workaround to help users to re-generate and re-enroll the key if we see this issue happening, currently it's treated as a transient error so users can retry, but as you mentioned, it will never work again. Do you have enough data i.e. sysdiagnose reports to debug it? I can help to get more reports. We get info about this issue almost in real time and have infrastructure/processes in place to follow up with users and collect diagnostics (including sysdiagnose) if needed.

We've also noticed some errors yesterday (29 June 2023 between ~21:00 and 23:00 UTC). Hope it gets resolved and the service becomes more stable.