W3C home > Mailing lists > Public > public-webauthn@w3.org > November 2020

[webauthn] User verification policy leads to ambiguous usage situations. (#1510)

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Mon, 02 Nov 2020 00:08:42 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-734095924-1604275721-sysbot+gh@w3.org>
Firstyear has just created a new issue for https://github.com/w3c/webauthn:

== User verification policy leads to ambiguous usage situations. ==
Hi there,

I have noticed a potential issue in the construction of UserVerificationPolicy with regard to PublicKeyCredentialCreationOptions and PublicKeyCredentialRequestOptions.

During the generation of a credential, this uses the UserVerificationPolicy (UVP) given to the AuthenticatorSelectionCriteria and embedded into PublicKeyCredentialCreationOptions. This creates a relationship between the UVP and the registered credential.

However, during an authentication, PublicKeyCredentialRequestOptions embeds the UVP in the top level dictionary, and the set of allowCredentials contains the set of credential ids that can proceed. This creates a relationship where the UVP is related to the authentication operation.

This can lead to a situation where a credential that was registered with verification, can then be used as an unverified credential in future operations. Additionally, one could register a credential with UVP::Required, and another with UVP::Discouraged, but in a future authentication this creates an ambiguity - do you require UVP::Required, and have the credential with discouraged now require verification? Or do we do the authentication with UVP::Discouraged, making the verified credential "un-verified". In the situation you use UVP::Preferred, this still creates ambiguity such as with CTAP1/2 where the credential can now become verified in some browsers, and remains unverified in others.

A possible solution is to treat the UserVerificationPolicy as "per user" and applies blanket to all tokens associated to the user, but this also reduces flexibility. Consider that an U2F token which was UVP::Discouraged at registration may be used with a password, but the user may also have a verified token that use used a sole source of MFA. The authentication flow should be that the user conducts a webauthn authentication first, and then based on that result and which credential was used we choose to request the password or not. But if we use UVP::Preferred, we now are verifying the U2F token adding an unnecessary step to the workflow. 

I'm sure that it may be difficult to achieve now, but I would suggest that UVP should be moved to PublicKeyCredentialDescriptor so that in the set of allowedCredentials the browser/client, is able to determine based on which credential we are selecting the method to proceed for verification of that individual token. 

Alternately, it would be potentially beneficial to consider this situation and how a diverse array of webauthn tokens can be associated to a single account, and how that interacts with the UVP and to provide recommendations accordingly. As webauthn exists in conjunction with other authentication mechanisms it should be considered how this is assembled into complete MFA systems such as a UVP::Required Token for a user, and a UVP::Discouraged Token + Password that can co-exist and have policies able to express this.


5.4 https://www.w3.org/TR/webauthn/#dictdef-publickeycredentialcreationoptions
5.4.4 https://www.w3.org/TR/webauthn/#dictdef-authenticatorselectioncriteria
5.5 https://www.w3.org/TR/webauthn/#dictdef-publickeycredentialrequestoptions 
5.10.3 https://www.w3.org/TR/webauthn/#dictdef-publickeycredentialdescriptor 

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1510 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 November 2020 00:08:44 UTC

This archive was generated by hypermail 2.4.0 : Monday, 2 November 2020 00:08:45 UTC