RE: Comments to WD-01

Yaron,

First of all, thank you for the detailed review. I’ve tried to address your questions and comments in more detail below:

  *   The document's title ends with "none".
  *   2.1: the definition of HTML5 has a typo.
These were fixed in the ED minutes after the WD went out.

  *   3: eTLD+1: referring to RFC 7719, the term is highly problematic because public suffixes may change over time. Do such changes create a security or usability issue in our case? For example, if mycompany.uk ever becomes a valid registration (as opposed to mycompany.co.uk), how does it affect the RPID algorithm?
Recent PRs have cleaned up these descriptions a bit. Regardless, it seems to me that the biggest issue is if something that used to be an eTLD+1 (and therefore a valid RP ID) becomes an eTLD (and therefore too broad to be a valid RP ID) since in that case origins that could not previously use a credential are now able to do so. This does not seem likely, and it would also affect behavior of things like cookies, which might be a bigger issue.

  *   4: "Support for deleting credentials is deliberately omitted" - shouldn't we at least specify what the platform should enforce, e.g. user verification? Otherwise any application may be able to downgrade 2FA solutions back to baseline password-only security.
I’m not sure I understand. From a security perspective, it is not clear why deleting credentials should require user verification. Maybe you would do so as a usability measure (to make sure the deletion is not accidental) but that does not seem necessary to mandate. It’s also not clear why deleting credentials would downgrade anything to password-only security. The RP can still ask for 2FA, just a different kind (e.g. automated phone call or SMS code).

  *   4: "user agents MUST only expose this API to callers in secure context" - Script writers will very likely get this requirement wrong, because secure contexts are nontrivial. Shouldn't we say what is the risk in this case? Alternatively, is this something that can be enforced by the browser?
“user agent” == “web browser” in this context. There is nothing left to script writers here.

  *   4.1: When obtaining a WebAuthentication interface, is there a way to choose between multiple Authenticators if more than one is available?
One does not “obtain a WebAuthentication interface”. This is written in WebIDL like all W3C specs are, but web developers will only interact with the Javascript binding of this. Think of the methods as static, if that helps.
Choosing between multiple authenticators is left to the client to mediate, as described later in the spec. Having a website be able to enumerate authenticators in range of your client creates possible privacy leaks.

  *   4.1.1 step #1: this is the first mention of timeoutSeconds - where is it defined?
It should be a clickable link – you can follow it to the definition. Does it now show up as such for you?

  *   4.1.1 step #3, "Let rpId be the lowercase form of this RP ID" - I don't think that this well defined in the presence of internationalized domain names? Is there a modern, authoritative version of nameprep that we can adopt here? (This is probably superseded by issue #167)
You are right, we are doing some work here to align this with the HTML spec.

  *   4.1.1 step #3: if we consider the Mozilla list authoritative for public suffixes, we should say so.
This has been changed in a recent PR to point to the HTML5 spec. We should not be defining such things in a WebAuthn spec but somewhere the whole web platform can track.

  *   4.1.1 step #4: do we define any mandatory-to-implement algorithms or credential types? It's hard to get interoperability if we don't.
I believe the goal was to wait for initial implementations, and then assess the state of algorithm support. Only one credential type is supported for now, so that one is okay.

  *   4.1.1 step #9: calling multiple authenticators in parallel for the same credential means that the user needs to "touch" each one. Is this really what we want? At the very least, this is very confusing to the user. Even more so in conjunction with the proposed authenticatorCancel operations (step #10) which are bound to result in race conditions between the authenticators.
  *   4.1.2, end of section: "the user agent SHOULD show some UI to the user to guide them in the process of selecting and authorizing an authenticator" - this text conflicts with the requirement to send the request to each of the authenticators in parallel.
All potentially usable authenticators are invoked in parallel. This will cause all of them to start blinking (or whatever they do to get attention) but as soon as the user touches any one the others turn off (due to the cancel you mention). In fact, the parallelism is what makes it so the user only has to touch one. If we went through the authenticators one by one, the user would have to touch a number of them. Having the client help the user understand what’s going on does not seem to contradict this.

  *   4.3: Why is Account::id not mandatory? It is the value that is eventually being authenticated, so shouldn't we bind it to the request into the platform? For example, if the user selection is being logged to disk.
PR#196 makes this mandatory.

  *   4.5: The excludeList allows an RP to tie different identities, i.e. to check if Alice and Bob are both used as identities on the same authenticator. This is because each of the CredentialDescription structures can contain a different id value, whereas if we only wanted to prevent multiple credentials for the same account, we would simply use the id value of the Account structure. Is this an attack we are willing to live with? Why not require (or allow) user consent for this step, e.g. "RP X wants to see other identities you have with it, do you allow that?"
One issue is that there are authenticators which have no local storage, but encode the entire credential and all its metadata into the credential ID. So for these authenticators, a credential ID is required. However, you make a good point that the authenticator could ignore any excludeList entries that are not for the same account ID. Would you please open a new issue?

  *   4.6: both authenticatorData and clientData are sent to the RP as serialized JSON. This creates a potential security vulnerability, because parsing of JSON dictionaries that contain duplicate occurrences of the same key is undefined (RFC 7159, Sec. 4), so one parser can pick the first value for a key and a different parser, the last value. As a result with a maliciously crafted string, the authenticator could authenticate one identity, while the RP would think another identity was authenticated.
I would like to understand your attack better. It seems like the only way to end up with this problem is to send two signatures, one from each authenticator. But in that case both identities are in fact authenticated, so allowing any one of them to be authenticated is not bad.

  *   4.8 (WebAuthnExtensions): the last paragraph refers to 5.2 (signature format) and should probably link elsewhere.
Please open a new issue.

  *   5.1: to maintain isolation between sessions it is insufficient to allow "one session to exist at any particular time", you also need to ensure that no information is leaked between the sessions.
Are you referring to this text: “This connection defines an authenticator session. An authenticator must maintain isolation between sessions. It may do this by only allowing one session to exist at any particular time, or by providing more complicated session management.”? If so, it seems to say exactly what you want.

  *   5.1.1: when we require user consent, we should specify what information must be available (displayed) to the user. E.g. the reDisplayName and the displayName values. Maybe also the RP ID.
An authenticator may not even have a display. Alternatively, an authenticator could be configured so it only accepts requests for a specific RP ID.These seem to be implementation issues for an authenticator to sort out.

  *   5.1.2: "The identifier of the credential used to generate the signature" is returned to the client, but AFAICT it is not actually signed. I'm not sure there's a direct vulnerability because of that, but I think including the ID in the signed material is a best practice.
Good point. I do not see an attack either, or at least no attack that does not also require the signature scheme to be broken in the first place. Interesting discussion point though.

  *   5.2.1: The explanation why the hash of the RP ID is not agile is correct for roaming authenticators with the *same* RP ID. But there's no reason why a new RP should not use SHA-512 with all of its authenticators, so crypto agility still makes sense in this context. I suggest to prefix the hash with a one byte version number.
But how would the client know which version to use? The authenticator is expecting the same version it saw when creating the credential, and the client does not know what this version was.

  *   5.3.1: "Relying Parties can always decide what attestation types are acceptable to them by policy." Is there a way for the RP to communicate this policy to the authenticator, so that the authenticator can choose its preferred type, or at least understand why the authentication failed?
Authentication will not fail if attestation is broken, only registration will. That said, RPs are free to treat such an authenticator as unattested, and use it anyways. It’s still better than a password.
In general we’d like RPs to always accept the WebAuthn assertions they get, and figure out ways to augment that with other factors if needed.

  *   7.3: "Clients SHOULD ignore extensions with an invalid client argument." Why not reject obviously malformed extensions?
Ignoring an extension amounts to rejecting it, since the authenticator won’t see it and therefore won’t respond. Extensions are optional so we don’t want to break core functionality just because the options are not perfect – we’d rather do the core function without the extra option.

  *   8.2 Authenticator Selection: The text is unclear. Instead of "If the client supports the Authenticator Selection Extension, it MUST use the first available authenticator whose AAGUID is present in the AuthenticatorSelectionList" I would suggest: "If the client supports the Authenticator Selection Extension, it MUST use the first authenticator from the AuthenticatorSelectionList that is available in the system".
Good point. Please open an issue.

  *   8.5: The Location Extension seems to conflict with privacy constraints in mobile operating systems, where a user can allow location information to each application. How do we allow the user to give consent to each RPID separately to access location data?
Managing this is left up to the clients. Clients can strip this extension from sites that do not have permissions to location data.

  *   8.6: please provide a reference to the "FIDO Registry of Predefined Values".
Jeff was working on this IIRC.