Discussion at in-person meeting on 8/31.
The desire is to avoid scenarios where individuals are subjected to server side biometric matching by RPs due to insufficient indications of what authentication occurred. This could be achieve a number of ways, but the intent is to allow for a request and response model where the RP can indicate a preference for a specific holder authentication type. The wallet will then indicate what authentication type occurred or whether the preference was met. If a wallet cannot achieve the desired authentication level the RP can then decide what to do with the information.
This was substantially informed by feedback from US financial institutions over concerns around having no visibility into how the holder is authenticating at transaction time.
Discussion at in-person meeting on 8/31.
The desire is to avoid scenarios where individuals are subjected to server side biometric matching by RPs due to insufficient indications of what authentication occurred. This could be achieve a number of ways, but the intent is to allow for a request and response model where the RP can indicate a preference for a specific holder authentication type. The wallet will then indicate what authentication type occurred or whether the preference was met. If a wallet cannot achieve the desired authentication level the RP can then decide what to do with the information.
This was substantially informed by feedback from US financial institutions over concerns around having no visibility into how the holder is authenticating at transaction time.