Thanks Quinn, the loctable was basically what I was looking for.

Sorry Quinn, I'll try to be more specific: We want the key to be usable with either biometry or device passcode - hence .userPresence - but we want to be able to decide whether to allow biometry in some cases or not. With .userPresence this does not seem to be possible out of the box since this always seems to prefer biometry if available. We tried passing a LAContext which has been used to access a (different) keychain item protected with .devicePasscode, but to no avail.

FB15438273

Thanks Quinn; I'll file this under "think first, ask later"

We have a custom implementation of HTTP Public Key Pinning on top of App Transport Security. The code in question tests this implementation (i.e. that given a valid trust object performing pin validation either lets our custom trust evaluation fail or succeed).

So, the code under test takes a trust object (SecTrust) and returns an allow / deny decision based on the public keys in the certificates in the chain? Exactly If so, you could solve this problem by having you test hardness create the trust object using the basic X.509 policy (SecPolicyCreateBasicX509()) rather than TLS policy (SecPolicyCreateSSL(::)). We are in fact using SecPolicyCreateSSL(_:_:). I'll try SecPolicyCreateBasicX509() and report back. ps You’re probably aware of this, but ATS supports public key pinning via the NSPinnedDomains property. If that works for you, it’s a lot easier than doing this in code. I know (and I've lobbied for it), but we are required to support HPKP.