Re: [webauthn] Include an AuthenticatorTransport when creating a new credential.

>the platform will by default, try to solve the request with the built-in authenticator first (since that allows for the best UX), if there's no credential there, it will then show the dialog to plug in an external authenticator.

Ok, I agree. But as I understand @agl these changes are also meant to enable the RP to tailor _its_ UX around the credentials to be used, and not have to rely completely on the client to do that (see also https://github.com/w3c/webauthn/issues/863#issuecomment-382529972). The issue in this case, then, is that the client can indeed do what you explain above, but the RP cannot since providing instant feedback about platform credentials not being available would be a potentially identifying information leak.

Although I guess the RP could work around that by making multiple `credentials.get()` calls - first one allowing only platform credentials, then one allowing only USB credentials etc. Either that, or first prompt the user for which credential(s) they intend to use. This seems a bit clumsy to me, but perhaps that's how it would have to work if the RP really wants to get specific about instructions like "please type your PIN when your OS prompts for it", "please scan your fingerprint on your phone", "please plug in your USB key" etc.?

Anyway, I agree that the proposed changes do enable the use case where `allowCredentials` has only `transport: "internal"` entries, which allows the client to conclude it should not ask the user for an external key they don't have. To help in the username-less case as @akshayku points out, though, we would also need an `attachment` or `transport` parameter outside `allowCredentials` to enable the same conclusion.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/882#issuecomment-386294498 using your GitHub account

Received on Thursday, 3 May 2018 13:25:45 UTC