Re: [webauthn] Privacy across Account IDs

A portion of this issue was fairly recently addressed by PR #651 which formalized the language for matching the items in the [`excludeCredentialDescriptorList`](https://w3c.github.io/webauthn/#op-make-cred) such that an RP can only probe for existing credentials that are mapped to itself. 

This seems to me to address a portion of @yaronf's suggestion of:
> the authenticator could ignore any excludeList entries that are not for the same account ID.

..in that we no longer have a notion of "account ID" and mapping to RP ID (and cred type) narrows what the RP can probe for, and is the best the spec presently can accomplish (i.e., without further changes).

Yes?


That said,  it does seem there is presently an issue of sorts at credential creation time, [as noted by](https://github.com/w3c/webauthn/issues/204#issue-177561011) @yaronf, in that a malicious RP can populate the  [`excludeCredentials`](https://w3c.github.io/webauthn/#dom-makepublickeycredentialoptions-excludecredentials) list with credential IDs it either knows or guesses in order to see if they exist on the user's presently-available authenticator(s). 

Given the way the webauthn protocol works **[1]**, it seems to me (at this time anyway), that @yaronf's suggestion of requiring or recommending that authenticators (and/or client platforms) prompt the user for consent when an RP stipulates a non-empty [`excludeCredentials`](https://w3c.github.io/webauthn/#dom-makepublickeycredentialoptions-excludecredentials) list. If the user does not consent, then a credential is not created. We would need to stipulate timing-related language similar to that now stipulated for the [authentication ceremony case](https://w3c.github.io/webauthn/#sec-assertion-privacy). 

An issue with this is that a user will not be able to a prior discern when an RP is "legitimately" attempting to allow the registration of only one credential with whichever of its accounts this user is mapped to, and when the RP is probing the user's authenticator(s) for existing credentials mapped to it (the RP), for whatever arbitrary purposes. 

So I am not sure what sort of prompt/question the authenticator or client platform ought to pose to the user in such a situation, i.e., what we ought to suggest in the spec.  Perhaps @yaronf's [proposed language](https://github.com/w3c/webauthn/issues/204#issue-177561011) is fairly close?  What if we suggest:
> [RP ID] wishes to detect whether there are other credentials registered with it on this authenticator. Do you wish to proceed?

Am I missing something in all this?  WDYT?

====
**[1]** with the RP initiating the actual credential creation operation through its client-side JS calling into [`navigator.cedentials.create({publickey})`](https://w3c.github.io/webappsec-credential-management/#dom-credentialscontainer-create) (with an [`excludeCredentials`](https://w3c.github.io/webauthn/#dom-makepublickeycredentialoptions-excludecredentials) list) thus invoking [`[[Create]]`](https://w3c.github.io/webauthn/#createCredential), which in turn invokes an authenticator's [authenticatorMakeCredential operation](https://w3c.github.io/webauthn/#op-make-cred) (passing in the `excludeCredentialDescriptorList`).




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

Received on Friday, 19 January 2018 21:42:49 UTC