Re: [webauthn] Privacy across OS accounts

@emlun: Hm, I'm guessing that the spec has changed out from under your assertions above (https://github.com/w3c/webauthn/issues/96#issuecomment-343227613)... 
> If an authenticator supports user verification, it must be used when **creating a credential**.

Does that hold if the RP has set `options.authenticatorSelection.userVerification` to "discouraged" ?  See step 19.2 in [5.1.3 #createCredential](https://w3c.github.io/webauthn/#createCredential)

> When **making an assertion with no `allowCredentials`**, user verification must be performed and the authenticator will not give up any information about credentials owned by other users.

I am not sure this is presently the case in webauthn's [6.2.3 authenticatorGetAssertion operation](https://w3c.github.io/webauthn/#op-get-assertion), because it appears [IIUC](https://en.wiktionary.org/wiki/IIUC), that in step 19.2 in [5.1.3 #createCredential](https://w3c.github.io/webauthn/#createCredential) an RP can cause |userVerification| to be false, and then in webauthn's the [authenticatorGetAssertion operation](https://w3c.github.io/webauthn/#op-get-assertion), in steps 4 & 5 all creds on the authnr are filtered by only `rpId`.

Similarly, [CTAP says](https://fidoalliance.org/specs/fido-v2.0-ps-20170927/fido-client-to-authenticator-protocol-v2.0-ps-20170927.html#authenticatorGetAssertion):
> If an allowList is not present, locate all credentials that are present on this authenticator and bound to the specified rpId.

[the CTAP editor's draft appears to have the same behavior]

Also, in webauthn's [6.2.3 authenticatorGetAssertion operation](https://w3c.github.io/webauthn/#op-get-assertion), in step 17.4, when `options.allowCredentials` is empty (down at the step bottom), the Note says:
> Note: In this case, the Relying Party did not supply a list of acceptable credential descriptors. Thus, the authenticator is being asked to exercise any credential it may possess that is bound to the Relying Party, as identified by rpId.

WRT your third point:
> User verification is not required if allowCredentials is given, but then the RP must already know the credential ID to use.

Presently, the value of `userVerification` (that is subsequently passed to the authenticator(s)) is set in webauthn's [6.2.3 authenticatorGetAssertion operation](https://w3c.github.io/webauthn/#op-get-assertion), in step 17.2 and appears to be independent of whether `options.allowCredentials` is empty or not. 

Given all this, I'm thinking that @levangongPayPal's [original](https://github.com/w3c/webauthn/issues/96#issue-154577449)..
> Could we ... recommend an implementation approach that would allow to link a credential to an OS account?

..is the way to go, which begs the question of having an "implementation considerations" section(s), along with the other issues we've labeled with [subtype:impl-cons](https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+label%3Asubtype%3Aimpl-cons).

for this we could possibly presently stipulate something like:
> In the case of [=authenticators=] [=bound authenticators|bound=] to platforms having a multiuser operating system, the authenticator and the platform SHOULD work together such that a platform user's webauthn credentials are not visible to other platform users.

WDYT?










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

Received on Thursday, 19 April 2018 18:37:45 UTC