What is the point of allowCredentials?

[subyraman]

My understanding, reading the spec, was that allowCredentials provides a means for the RP to filter registered authenticators, eg request the browser to "wink" a single selected authenticator (like a Yubikey). As an RP, this would be useful (essential?) for providing a good UX, so that the user is not confused by several authentication notifications, only one of which is valid.

I think there are differences of opinion on this as noted on this discussion in the Chromium bug board; there is a stance that that allowedCredentials is a list used to fail authentications only after a ceremony takes place (if I understand it correctly).

If that is the case, I don't understand why it is useful at all; the RP themselves can reject the authentication on our end given that we receive the credentialId .

Can we get some clarification on this, and perhaps emphasize it in the spec if it isn't there?

[herrjemand]

@subyraman allowCredentials is used to provide authenticator with exact credential you want assertion from, and it is essential as FIDO2 supports 2FA-only mode, as it requires exact credID to be presented. Same applies for U2F.

[emlun]

@subyraman Your understanding of the spec is correct, in addition to what @herrjemand points out.

What the Chrome team is pointing out is that they want to allow the RP to detect if the user attempts to authenticate with an authenticator that does not have one of the allowed credentials, so the RP can inform the user that they need to use a different authenticator. In order to do that, they need the user to first confirm the attempt to authenticate - otherwise there's no way to know that the user won't plug in a different authenticator a few seconds into the future. I'm guessing this could be solved better by instad showing a browser popup when the user plugs in an authenticator without any of the allowCredentials, rather than returning an error to the RP. I added a comment on that to the Chrome thread too.

This issue stands in opposition to #863.

[equalsJeffH]

shall we map this issue to the same milestone as issue #863?

[emlun]

Maybe, but I feel like this deserves some discussion on a WG call now that we've seen confusion between RPs and browsers in CR implementations. I think #863 might need to be moved to PR since it seems to be something Chrome is already testing implementation of. @equalsJeffH WDYT?

[equalsJeffH]

@emlun

I feel like this deserves some discussion on a WG call now that we've seen confusion between RPs and browsers in CR implementations

might you explain further?

[emlun]

@subyraman has clearly made a different interpretation of the spec than what's currently implemented in Chrome.

[kpaulh]

I'd say our interpretation is that of @herrjemand's response - allowCredentials is necessary for the authenticator to make an assertion for second-factor use cases, and that the list could be used to influence UX, but that is not its primary purpose.

[agl]

Closing based on discussion on the call today.