Re: [webauthn] #getAssertion alg needs to pass authenticator selection requirements to authenticatorGetAssertion operation

Let's separate silent behavior from "uv" discussion. We don't want that ever to happen for our keys. and corresponding option is "up" and not "uv". We won't be able to support any design which cannot achieve this requirement.

"UV" caching is different and I don't think we are ready for it in this version and we should target next version for this.

Regarding "uv", conversation is slightly complex.  As I said in #629, one workflow where RP can decide whether they care or not about "uv"  or not is when they receive the signature. In another workflow, where RP always want it, it can reject that signature if authenticator is not capable of doing it. Only case where RP does not really need user verification to happen, current API does not support that semantics when a UV capable authenticators comes along. This also is tricky, as RP does not know what kind of authenticator user will plug it in, when RP just asks for assertion without providing any credential ID (without any userID knowledge flows). In that sense, RP is just asking me tell me what you have (what credential, whether UV is set or not etc). RP cannot decide in advance what kind of user it is and what kind of authenticator he/she has and correspondingly does not provide any allowed credentialID list .

Anyway, looks like current design does not support one use case where RP does not want user verification to happen every-time it asks for assertion. For all other cases, signature reflects what you got and RP can act on it. If people really care about that scenario, below proposal IMO achieves all above cases.

enum name of `userVerificationRequirement` with values of `Required`, `NotRequired` and `AuthenticatorBehavior`, with default value being `AuthenticatorBehavior`.

- `Required`: Authenticator MUST enforce user verification and signature MUST
have `UV` bit set.

- `NotRequired`: Authenticator MUST not ask for user verification even if authenticator is capable of it. This if for scenario where touch is enough for RP and it does not want UI pops on authenticator or platform for ClientPin Case. May be in case it wants to use the authenticator as a second factor device.

- `AuthenticatorBehavior`: Platform performs the default behavior of authenticator and signature reflects that. It is kind of RP saying, tell me what you have and I will decide what level of authentication you can have or RP does not care about user verification but OK if it receives it as it ignores it. For Authenticators, which don't support user verification, it will not set "UV" bit set. For authenticators that can support user verification, platform will send such a request and signature will reflect "UV" bit.



-- 
GitHub Notification of comment by akshayku
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/644#issuecomment-339449751 using your GitHub account

Received on Wednesday, 25 October 2017 19:48:57 UTC