[webauthn] Clarify relationships between "uv"/"up" of the CTAP spec and "userVerification"/"userPresence" (#1123)

alanwaketan has just created a new issue for https://github.com/w3c/webauthn:

== Clarify relationships between "uv"/"up" of the CTAP spec and "userVerification"/"userPresence" ==
In the CTAP spec (https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html), we have the following tables:

[WebAuthN]authenticatorMakeCredentialoperation | CTAP authenticatorMakeCredential operation
...
requireUserPresence | Not present in the current version of CTAP. Authenticators are assumed to always check user presence.
requireUserVerification | options.uv or pinAuth/pinProtocol
....

[WebAuthN] authenticatorGetAssertion operation | CTAP authenticatorGetAssertion operation
...
requireUserPresence | options.up
requireUserVerification | options.uv or pinAuth/pinProtocol
...

That to me means "userVerification"/"userPresence" = "uv"/"up".

Then we have this in the spec: https://www.w3.org/TR/webauthn/#getAssertion
    Let userPresence be a Boolean value set to the inverse of userVerification.
I interpret this sentence as userVerification includes userPresence. When userVerification is required, userPresence is also required implicitly. Hence, the response from the authenticator will only have the following two valid combinations between uv and up ({uv, up}):
{1, 1}
{0, 1}

However, in the CTAP spec, it looks like requiring uv doesn't necessary mean requiring up.
In section 5.2, Step 7:
    Collect user consent if required. This step MUST happen before the following steps due to privacy reasons (i.e., authenticator cannot disclose existence of a credential until the user interacted with the device):
    - If the "uv" option was specified and set to true:
    --  If device doesn’t support user-identifiable gestures, return the CTAP2_ERR_UNSUPPORTED_OPTION error.
    -- Collect a user-identifiable gesture. If gesture validation fails, return the CTAP2_ERR_OPERATION_DENIED error.
    - If the "up" option was specified and set to true, collect the user’s consent.
    --If no consent is obtained and a timeout occurs, return the CTAP2_ERR_OPERATION_DENIED error.
I interpret the above as the authenticator will check uv and up independently according to the request's parameters.

If user agents send the request as suggested by both spec when userVerification is required from the RP, then an authenticator could send a response that includes the {uv, up} as {1, 0}.

So this really confuses me. I think we need some clarifications on either the WebAuthN spec or the CTAP spec. I will suggest we change the WebAuthN spec to:
"Let userPresence be a Boolean value set to the inverse of userVerification." => "Let userPresence be true."

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

Received on Tuesday, 18 December 2018 00:38:20 UTC