Comments to WD-01

Dear Webauthn folks,

Here are some comments on the latest protocol draft. I suppose the 
proper way to comment is to open issues on the tracker, but as a 
newcomer, I'd like to first run them on the list and get initial 
feedback and guidance.

Summary

The list below is very long, but I think the most important issues are:

  * The behavior in the presence of multiple authenticators is
    confusing, with the user potentially getting multiple prompts
    simultaneously which are then rescinded with "cancel" commands.
    There are hints in the document about local storage and/or
    extensions being used to remedy this situation, but I think it is
    important enough to be clarified in the main body of the protocol.
  * I can see two privacy issues, one around the excludeList which is
    defined in a too flexible manner and thus allows the RP to link
    multiple user identities even when they are for different accounts;
    another privacy problem is the Location extension. Both issues are
    explained in detail below.

Details

  * The document's title ends with "none".
  * 2.1: the definition of HTML5 has a typo.
  * 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?
  * 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.
  * 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?
  * 4.1: When obtaining a WebAuthentication interface, is there a way to
    choose between multiple Authenticators if more than one is available?
  * 4.1.1 step #1: this is the first mention of timeoutSeconds - where
    is it defined?
  * 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)
  * 4.1.1 step #3: if we consider the Mozilla list authoritative for
    public suffixes, we should say so.
  * 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.
  * 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.
  * 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.
  * 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?"
  * 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.
  * 4.8 (WebAuthnExtensions): the last paragraph refers to 5.2
    (signature format) and should probably link elsewhere.
  * 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.
  * 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.
  * 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.
  * 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.
  * 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?
  * 7.3: "Clients SHOULD ignore extensions with an invalid client
    argument." Why not reject obviously malformed extensions?
  * 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".
  * 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?
  * 8.6: please provide a reference to the "FIDO Registry of Predefined
    Values".

Thanks,

     Yaron