evaluatedPolicyDomainState unique per app identifier

I have an app and extension (Siri) that I am trying to use TouchID to authenticate an action. The main app has an enrollment process that stores off the evaluatedPolicyDomainState hash value for comparison to ensure the figerprint storage has not changed. This works great for the main app. However in the extension when trying to validate the hash with a stored hash in group storage the hash comes back differently. So it appears that the evaluatedPolicyDomainState hash is different per bundle id. Is that correct. I would have assumed that apps in the same appgroup entitlement would get the same DomainState back. That is the evaluatedPolicyDomainState would be based off of the enclave and app group id and not just app bundle id. Has anyone else run accross this?

Up vote post of erolf Down vote post of erolf
981 views
Posted by
erolf
Reply
Add a Comment

Replies

Same with custom keyboard extension

Posted by
AvihaiTS
Up vote reply of AvihaiTS Down vote reply of AvihaiTS
Add a Comment

So it appears that the evaluatedPolicyDomainState hash is different per bundle id. Is that correct.

I don’t know. If you need a definitive answer to this I recommend that you open a DTS tech support incident and talk to our Touch ID expert.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • (s. 689628168)

    —
    eskimo
Add a Comment

DTS got another incident about this recently and, as the above-mentioned Touch ID expert is no longer with us [1], I thought I’d share some of the things I’ve learnt.

To start, I can confirm that evaluatedPolicyDomainState is different for each app. This was a deliberate design choice based on privacy concerns. I’ve filed a bug requesting that we cover this limitation in the evaluatedPolicyDomainState docs (r. 107051460).

One potential workaround is to use a biometric protected keychain item in a shared keychain access group. If you specify the .biometryCurrentSet flag, the system will invalidate that item if the biometrics change. I haven’t actually tested this technique myself but I believe that other developers are using it successfully. The main drawback is that you’re limited to the features provided by the keychain.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] He retired to pursue his other passions. Lucky him!

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment