Usability Issue: Server Challenge timeout

[equalsJeffH]

Originally submitted by: rlin1, on: Monday Oct 19, 2015 at 15:00 GMT

---

Scenario:

• Attempt 1:
    o   User starts registration of an authenticator:  
         The App retrieves the server challenge (the server assigns a maximum time 
           to live of X minutes to it).
         The App calls makeCredential and receives the response (i.e. the attestationStatement).

    o   Connection drops (e.g. user is on train entering a tunnel, battery dead, 
         provider outage, …)

    o   App cannot send the response to the server and returns an error to the user.

    o   Connection is restored after X+1 (or more) minutes and server will not accept the 
         registration response.

• Attempt 2:
    o   User re-starts registration of the same authenticator for same account:
         The App retrieves new challenge from the server.
         The App calls makeCredential and receives the fresh response
            (i.e. the attestationStatement).  

    o   Note 1: re-using the old credential from Attempt 1, i.e. skipping makeCredential 
         and first trying sign doesn’t help as the server won’t accept it without a fresh 
         attestationStatement.

    o   Note 2: at this time we don’t specify whether makeCredential MUST create a new key 
         for the same account or re-use the old one.  

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 15:00 GMT

---

Proposal: We SHOULD specify that the authenticator SHALL re-use the old key if accountInfo is identical to an existing credential on a makeCredential call.

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 15:20 GMT

---

Comment from Dirk (via email):
(1) (Restricting authenticators to one credential per account): I think we could do that. I remember in an early version of the FIDO 2.0 APIs we had a parameter called "purpose" (or something like that), which was supposed to allow the RP to have multiple credentials for a user account for different purposes. Presumably, an authenticator would only ever create one credential for a given account and purpose. Anyway, the parameter is gone now, but we said that the user id we now have when generating credentials can be used by the RP for the same purpose.

So, as an RP, I would call:

window.fido.makeCredential({
rpDisplayName: “Paypal”,
displayName: “John P. Smith”,
name: “johnpsmith@gmail.com”,
id: “1098237235409872”,
imageUri: “https://pics.paypal.com/00/p/aBjjjpqPb.png”
},{
type: "FIDO", algorithm: "ES256"
},
"LKASJSIUklsajasahhhhhh" /* attestation challenge */
);

...to create a credential, and if I really wanted multiple credentials for the same account (for different purposes), I could do something like:

window.fido.makeCredential({
...,
id: “1098237235409872-purpose1”,
...
},...);

etc.

I think that might work.

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 15:24 GMT

---

Comment from Arshad (via Email):
I've always wondered: what is the rationale for preventing the generation and storage of multiple key-pairs for the same User on the same Authenticator? If each key has a unique key-identifier, and they're tied to the same account, and if multiple keyids came back for signing, does it matter whether there's one or more keys for the user on the token? The server is going to accept the first valid signature in any case.

In the world of digital certificates, it is possible to have multiple digital certificates for the same user on the same smartcard accessing a single application; if its a non-issue with key-pairs wrapped by a certificate, why is it an issue with a key-pair identified by a unique keyid? Am I missing something?

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 15:24 GMT

---

Comment from Arnar (via email):
For one example, consider this case:

1. User registers a key on foo.com
2. User finds herself abroad, phone (authenticator) is lost and off, so she does account recovery and revokes the credential. (since phone is off, even with a delete API the key on the phone will not be deleted).
3. Phone is found and returned, so the user re-enables and re-registers another key.

Now there are two key pairs on the phone for foo.com and the same account - but the server only knows one public key. If the phone happens to pick the wrong key for signing, login fails.

We think a delete API is a fragile solution to this problem, and that one-keypair-per-account-identifier is a better one.

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 15:25 GMT

---

Comment from Arshad (via email):
Thanks for that use-case, Arnar. But, that sounds drastic - like using a shotgun to kill a fly.

Why not allow the user to deactivate the public key as part of the account recovery flow, so they have the option to activate it again if they find their phone/token again? This will then eliminate the need to have a hard-rule that a user may only have one key-pair registered to an RP-site on a token. I imagine the firmware for the authenticator will be a little simpler without that rule. The user can always be given the option to delete the key when they've authenticated with the authenticator, thus ensuring that the key is deleted on the server and the authenticator in the transaction.

[equalsJeffH]

Original poster: rlin1, on: Monday Oct 19, 2015 at 16:42 GMT

---

Using this approach for multiple purposes (see Dirk's comment above) also leads to the issue #155, i.e. The user will have to delete the credential twice (i.e. first in the App itself since this is default place to start and then in the device's proprietary credential manager - if it exists).

[rlin1]

Revised Proposal:
No one can expect an authenticator to maintain multiple keys for one accountInfo
(clarification to be added to Auhenticator model).

[vijaybh]

Authenticator model will be changed to say that a caller should not expect to be able to have more than one credential on a single authenticator for the same AccountInfo value.