Webauthn: Re-focus resident key descriptions on allowCredentials aspect

[emlun]

@agl remarked on the 2019-04-03 WG call that the terminology for resident keys (aka "resident credentials") conflates two disctinct aspects:

1. A resident key is stored in the authenticator.
2. A resident key can be used with empty allowCredentials, e.g.:

var options = {
  challenge: new Uint8Array([4,101,15 /* 29 more random bytes generated 
                                        by the server */]),
  timeout: 60000,  // 1 minute
  // we're letting allowCredentials default to an empty sequence
};
navigator.credentials.get({ "publicKey": options })

...and that of the two, (2) is usually the more interesting one from an RP perspective. There was broad agreement on the call that we should reformulate the terminology to focus more on aspect (2) than (1).

See also: https://github.com/w3c/webauthn/issues/991#issuecomment-479645567

[akshayku]

Resident keys can be used with or without allowlist. Infact we use it in both the ways already. So reformulating this will break existing implementation/assumptions. I object to this change in reformulating the definition.

[agl]

This wouldn't break anything, it only makes the concept of resident keys useful to an RP, which it currently, technically isn't.

As the initial comment notes, there are two concepts here: _stateful_ credentials store their private key material on an authenticator, _initiating_ credentials can be used without providing an allow-list. An initiating credential must be stateful, but not vice-versa.

Currently, the Webauthn spec defines resident credentials as stateful, and implies that means that they're also initiating. But U2F authenticators can be stateful if they wish—there's nothing stopping them from storing the private key and using a short index as a credential ID. Likewise CTAP2 authenticators can be stateful but, if rk was false when the credential was created, they may choose not to return such credentials for an empty allow-list and thus not make them initiating.

(In fact, CTAP2 defines the rk flag thus: “instructs the authenticator to store the key material on the device”. So it's not precise that they actually need to be returned for an empty allow-list!)

In order to be useful to an RP, a resident credential is one that it can get an assertion from with an empty allow-list. It's the _initiating_ property that they care about, not the security decision about whether the private key is wrapped and exported or not. But our specs are very confused about this.

[agl]

See also https://github.com/fido-alliance/fido-2-specs/pull/661