Secure storage fails when no biometrics are present

[mdhornet90]

I've been tracking an issue in our pretty much identical to the one mentioned here: https://stackoverflow.com/questions/66577841/keychain-secitemadd-fails-when-using-secaccesscontrol-with-passcode-biometry

The root cause is related to the following code in this repo:

            if behindBiometrics {
                if #available(iOS 11.3, *) {
                    biometryAndPasscodeFlags.insert(SecAccessControlCreateFlags.biometryCurrentSet)
                } else {
                    biometryAndPasscodeFlags.insert(SecAccessControlCreateFlags.touchIDCurrentSet)
                }
                biometryAndPasscodeFlags.insert(SecAccessControlCreateFlags.or)
                biometryAndPasscodeFlags.insert(SecAccessControlCreateFlags.devicePasscode)
            }

I made a fork + branch with the suggested fix in the accepted SO answer (here: https://github.com/okta/okta-storage-swift/compare/master...ootp-io:okta-storage-swift:biometrics-fix)

That said, I was hoping someone could give me some background around the current use of biometrics. Was the expectation that or flag was going to allow the option of either one, because Apple confirmed that's not intention of the or flag (it's only meant for read operations). And was the use of currentSet meant to guard against the case where biometric prints were added or removed?

[epitaphmike]

Bump