Re: [webauthn] Add notion of forbidding resident credential creation (#1149)

I think talking about how the key is stored is not really the heart of the issue.

I think the proper thing to consider is if the credential requires an allow list. 

Now with the credprotect extension, the RP can create a credential that must be used in get with a allow list or a pin is required if the credential is used without an allow list.   That is independent of how the credential is stored.

The issue Christian has is being able to suppress the prompting for a UV factor separate from UP.
I think everyone is OK with the make credential behavior of U2F, and removing the current requirement to always do UV even if UV discouraged is sent during make credential if UV (or PIN) is set on the device.

Perhaps we should look at the reasons people have for requiring UV for credentials that can be used without an allow list,  before we mess too much with trying to prohibit resident keys and perhaps unintended consequences from adding more flags.

One way to do it might be that if the RP sends UV discouraged in the make credential request, the browser would know that it needs make a CTAP request for a non resident credential without prompting for PIN. 

Or with an authenticator that supports credprotect would setting userVerificationOptionalWithCredentialIDList also be OK to create without requiring a PIN for Make Credential.

I think the desired behavior is probably more along the lines of make a credential with UV = Discouraged and let the WebAuthn client decide how best to do that if it is a non resident credential or a resident credential that can only be used with an allow list based on the authenticators available. 

Our problem is more that UV = discouraged is overridden.

RP that send UV = discouraged just need to be willing to accept credentials that may be non resident.
If we report back if the credential can be used without an allow list, or not I don't see much of a problem.

If the RP asks for resident = true and UV = discouraged then that would just be an invalid combination.

Perhaps it is UV that we need an extra state for,  Forbidden, Discouraged, Preferred, Required?  That might be a better way to get at what I think Christian is looking for.  Or just change the interpretation of discouraged for make credential. 





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

Received on Thursday, 13 June 2019 16:25:27 UTC