Possibility to filter displayed authenticators by certified level

[JeanDim]

Description

Dear webAuthn community,

I would like to submit this use case: Possibility to filter diplayed authenticators by certified level

The rationale is the following: As several FIDO security levels exist for authenticator, a relying party (a bank for instance) could rely on these to evaluate the level of trust and confidence of user authentication. Many factors can be taken into account such as regulation, requested action sensitivity, user environment, fraud history … Therefore, depending on such factors a relying party may adjust FIDO security level of accepted authenticators for a given user or context.

How a RP could do so? Especially without impacting user experience in a negative way?

One use case could be:

1. A bank, for security reason, only accept authenticator level 3 certified (as example).
2. When the RP (the bank) prompts user for credential creation (enrolment) the browser displays the authenticators detected (platform or roaming) - without any certification-based filtering.
3. Therefore, a user selects an random (or favorite) authenticator (without info regarding authenticator certified level)
4. The authenticator provides the attestation to the RP (the bank)
5. The bank checks authenticator certification level with Fido MDS (or use whitelist / blacklist with authenticator AAGUID)
6. Then bank rejects the enrolment due to security policy

==> The authenticator still have credential created but not usable (as RP rejects it at the end), the user may be confused, there is no way for the user to identify certified level 3 authenticator at this stage

Without the possibility to filter authenticator prior credential creation a bank may fall back with another authentication method, such as banking app, KBA or OTPs (multi-channels).

Would it be possible to considere adding such filtering feature for a relying party, through webAuthn / CTAP protocol?

Related Links

• https://fidoalliance.org/certification/authenticator-certification-levels/

[serianox]

This is a good case for Authenticator Selection Criteria.

Note that in the end, it does not allow the RP not to check the metadata, as the client doesn't validate the authenticator attestation. But it would give overall better user experience.

[Firstyear]

This has come up before in #1739 and #1688

The issue is that there is a conflict between "enterprise" who want this level of control, and "browsers" who are looking at the general population of everyday websites. There is resistance to give this kind of filtering because "everyday websites" will probably abuse/misuse it in some way. But enterprise needs it to improve their UX flows when they have tight regulations.

So IMO this is a "subset" of #1688

[Firstyear]

Anyway to answer your question today, the only way is to pre-filter the fido mds offline, determine the set of AAGUIDs of devices taht conform, then you request attestation and only allow devices with those AAGUIDS to proceed.

[JeanDim]

Thank you for your feedback.
The user experience is key in particular into payment context. Due to too much friction during EMV 3DS authentication flow, merchants complained to EMVCo for a low conversion rate ( cart abandonment, unsuccessful challenge, annoyed consumer, bad experience...). Card networks are putting more stress on banks to improve frictionless experience (by improving silent authentication methods and accept exemption or delegation in largest scale). SPC has been integrated into EMV 3DS latest version (2.3.1) as alternative to current authentication challenges flow. Even if credential enrollment stage is still an ongoing discussion, some ACS choose to add it within payment flow (for convenience. After successful challenge, the ACS asks the consumer if he wants to use biometric for next time, for instance). If the user experience does not reach expectation it could lead to a barrier to SPC adoption.

#1688 contains interesting thoughts, especially issuecomment-1008743434 emphasizing the possibility to use
webAuthn extension authnSel . With this possibility, we could avoid "post" filtering and then, improve user experience.

However, it has been removed on Level2 specification for lack of client implementations (refer to #1386 )
But if this extension is still available on authenticators (as still present into IANA available webAuthn extension) , and solve the user experience issue on RP side, maybe we could considere reintroduce it into the spec ?

[emlun]

But if this extension is still available on authenticators (as still present into IANA available webAuthn extension) , and solve the user experience issue on RP side, maybe we could considere reintroduce it into the spec ?

As you note, the extension is still there in the IANA registry and clients are free (but not required) to implement it if they wish (note that it's clients (browsers) that would need to implement support, not authenticators). Re-introducing it in the spec would not change anything, you would instead have to convince browser vendors to implement the extension.

[Firstyear]

@emlun The problem was that in a previous ticket chrome developers stated "no one else implemented it so we didn't" but they have a virtual monopoly on browsers, so we need to get chrome to implement it. And firefox has effectively stalled on webauthn completely. So it seems we have a chicken/egg problem to start here, that's not easily solved.

[nicksteele]

Thomas has it, the current way to check for any assurance initially is through the Auth selection criteria. This would require implementation by browsers and as per the bi-weekly call, there isn't much impetus to include it.

[Firstyear]

@nicksteele But you can't check these through auth selection criteria - you had to perform a registration and then reject it once it fails the aaguid check.

There is a clear and well described desire for this which has been raised multiple times.

[JeanDim]

As SPC is now a key feature of EMV 3DS (version 2.3.1), and webAuthn also included for merchant delegation, this subject can grow in scope. Having such capacity would help FIDO2 adoption and implementation from banks.
We can raise this topic in WPSIG or WPWG.

[nicksteele]

This has come up before many times, and while there is a desire to have it understandably, there is a lack of browser vendor desire to implement it, the reasons for which can be read in myriad prior issues regarding the same topic. I would refer you to @agl's statement from a prior issue discussion, which discusses the authenticator selection extension (and by extension, this topic)

About the authenticator selection extension itself: We have never implemented it because we don't feel that authenticator discrimination is broadly a good thing. Multiple different RPs might each have locally valid reasons for wanting to select the authenticators that are permitted on their site, but the sum of this is that users need to have multiple authenticators to span the set of different site policies that they encounter, they have to remember which goes with each site, and they can't have the expectation that a given security key will broadly work where they want to use it.

This is a fair point, and one I agree with. Giving the outright ability to discriminate authenticators upon registration could end up being a broad negative and source of frustration for users, and there are ways of handling filtration after a registration attempt that allow for better UX, for example:

1. A user comes to the site with an excluded authenticator (one of many excluded from the given RP)
2. User attempts to register. If this was excluded prior to registration verification, the client would tell the user this was one of the excluded authenticators, but probably wouldn't have insight into which.
3. User's registration attempt fails after attempted verification, but the RP now has insight into which authenticator failed.
4. RP informs user with how to remediate.

Either way, I don't think we shouldn't be limited general consumer user authenticator enrollment, and again, there's no desire by platforms on this topic.

[Firstyear]

@nicksteele The thing is, as an RP we already have the ability to discriminate authenticators by rejecting attestations. We already are in exactly the situation described.

The difference is where the UI/UX onus is placed - on the RP to "post attestation failure" document "hey, we don't support that device". Or if we can provide hints to a browser to say "hey just don't show that authenticator as being allowed to participate in this ceremony".

This isn't about allowing RP's to discriminate authenticators - we can already do that.

This is about having browsers display a nicer UI/UX that an authenticator is about to be rejected during a ceremony - and thus we never start that ceremony at all.

[JeanDim]

The subject has been discussed during last WPSIG meeting. The UI/UX concern, resumed by @Firstyear in previous comment, has been shared by payment stakeholders. As the SPC adoption in payment ecosystem also depends on UI/UX. If the user journey generates too much friction, banks may not adopt the solution. Let's see if this new trend on Fido2 usage will change browser's providers position regarding this topic.
In another hand (for this very use case on authenticator filtering by certified level), Windows hello and Android Safetynet authenticators are level 1 certified and, so far, SPC cannot be used with roaming authenticators.
It is then the moment to discuss furthermore about this topic before enabling cross-platform authentication in SPC.

[nicksteele]

This approach remains a non-starter for the WG, the issue continues to be that while yes, you can discriminate against authenticators, there shouldn't be an ability for RPs to preemptively deny a user's authenticator from creating a credential. Yes, the onus should be on the RP to dissuade the user from attempting to use a certain authenticator, I think primarily because the browser has no onus towards remediation.

What would be a compelling topic is better transport and authenticator hinting, which would allow the RP to present a different UX/UI depending on the information inferred from these hints.