- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Dec 2018 12:05:56 +0000
- To: public-webauthn@w3.org
While the text would benefit from some clarification about the terms, here is the situation.
**Basic principles**:
- User presence is **ALWAYS** required from the WebAuthN spec. Silent authentication is NOT allowed as per the spec.
- RP can influence where it requires user verification from the authenticator.
- There are three user verification modes RP can request:
- Required: Client/platform must fail such request if authenticator is not capable of doing user verification.
- Preferred: Client/platform will try to get the user verification if possible, but will not fail if authenticator is not capable of doing user verification.
- Discouraged: Client will try to get the user presence only if possible. If not possible, client will also get user verification. For example, certain authenticators can only allow operations on their authenticator if user verification is performed. It's that authenticators decision. Another example is during MakeCredential, if authenticator is protected, currently, its required to verify the user.
**CTAP options that influence user presence**:
- up: check for user presence
**CTAP options that influence user verification**:
- uv: check for built-in user verification method
- pinAuth/pinProtocol: Do the user verification using pinToken.
**_So the only option RP can influence from WebAuthN is "UserVerificationRequirement" which is applicable for both webauthn create and get methods and controls user verification. User presence is always required from WebAuthN layer._**
So below is the WebAuthN options that RP translates to CTAP: **_In every case below, the actual request that is being sent back to the authenticator MUST have "up" set to true as silent authentication is NOT allowed from the spec currently and user presence is always required._**
- **_WebAuthN Method: Create_**
- **UserVerificationRequirement: Required/Preferred:**
- **_Authenticator state: Not protected either by PIN or by built in method_**
- Platform/Client can try to set the PIN, provision fingerprint inline if authenticator is capable of it. However, if this cannot be done, then Client MUST fail the request.
- **_Authenticator state: protected by PIN_**
- Final request options: **_"up" = true, pinProtocol = 1, pinAuth = <value>_**
- **_Authenticator state: protected by built in user verification method such as fingerprint._**
- Final request options: **_"up" = true, "uv" = true_**
- **_Authenticator state: protected by both PIN as well as built in user verification method._**
- Client/platform is free to choose any method. One strategy can be that first try built in user verification method, and if that doesn't succeed for some reason, try PIN.
- **UserVerificationRequirement: discouraged:**
- **_Authenticator state: Not protected either by PIN or by built in method_**
- Final request options: **_"up = true"_**
- **_Authenticator state: protected by PIN_**
- Important point as of current CTAP spec: Authenticator required user verification for makecredential if authenticator is protected. So WebAuthN choice can't degrade authenticator security currently.
- Final request options: **_"up" = true, pinProtocol = 1, pinAuth = <value>_**
- **_Authenticator state: protected by built in user verification method such as fingerprint._**
- Final request options: **_"up" = true, "uv" = true_**
- **_Authenticator state: protected by both PIN as well as built in user verification method._**
- Client/platform is free to choose any method. One strategy can be that first try built in user verification method, and if that doesn't succeed for some reason, try PIN.
- **_WebAuthN Method: Get_**
- **UserVerificationRequirement: Required/Preferred:**
- **_Authenticator state: Not protected either by PIN or by built in method_**
- Platform/Client can try to set the PIN, provision fingerprint inline if authenticator is capable of it. However, if this cannot be done, then Client MUST fail the request.
- **_Authenticator state: protected by PIN_**
- This is reflected in authenticatorGetInfo via "ClientPIN" set to true. If ClientPIN is set to false, that means that authenticator is capable of being protected by the PIN but, it's not being configured yet.
- Client gathers PIN from the user and then uses pinAuth/pinProtocol to send that information to the authenticator. To protect from cached information on the client, up=true MUST be set.
- Final request options: **_"up" = true, pinProtocol = 1, pinAuth = <value>_**
- **_Authenticator state: protected by built in user verification method such as fingerprint._**
- Whether authenticator is protected by built in user verification method is revealed by authenticaorGetInfo where uv is set to true. If "uv" is set to false, that means that authenticator is capable of user verification but its not configured yet.
- Final request options: **_"up" = true, "uv" = true _**
- **_Authenticator state: protected by both PIN as well as built in user verification method._**
- Client/platform is free to choose any method. One strategy can be that first try built in user verification method, and if that doesn't succeed for some reason, try PIN.
- **UserVerificationRequirement: discouraged:**
- **_Authenticator state: Not protected either by PIN or by built in method_**
- Final request options: **_"up = true"_**
- **_Authenticator state: protected by PIN_**
- Final request options: **_"up" = true_**
- **_Authenticator state: protected by built in user verification method such as fingerprint._**
- Final request options: **_"up" = true_**
- **_Authenticator state: protected by both PIN as well as built in user verification method._**
- Final request options: **_"up" = true_**
--
GitHub Notification of comment by akshayku
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1123#issuecomment-448198487 using your GitHub account
Received on Tuesday, 18 December 2018 12:05:57 UTC