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.

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.

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