I believe I've heard some RP's do exactly that - use the credentialId to resolve the user account, then determine the corresponding public key and username. About the only reason I can think of where userHandle adds value is that it is an assertion from the authenticator as to which user the credentialId was associated with at the time of registration. Therefore at authentication time it is potentially a way of ensuring the crendentialId has not subsequently be swapped to another account at the RP (if the RP chooses to implement this measure).

Step 2 of https://www.w3.org/TR/webauthn/#verifying-assertion is prescriptive in it's intended use of userHandle, which in the context of username-less login (aka empty allowCredentials list login) is for the measure I indicated previously - ensuring the credentialId is owned by that user. I don't think this means you cannot achieve a solution with credentialId alone (I'm fairly sure you can), however when using an empty allowCredentials list the user is typically presented with a dialog by the browser for identity selection / confirmation and it would be quite odd if the RP then logged you in as someone else based on credentialId lookup.

Great, thanks for the clarification, I am going full username-less so I am doing almost exactly what you mentioned above.
A user can have multiple credentials linked to them, also when a user generates a JWT token, it is linked to the credential that was used to login, so I have full tracking from token-credential-user, hopefully eliminating any incorrect authentication.

The authenticator itself can have a policy of one credential per rpid, or one per user handle at a rpid. However, I don't think this distinction matters - you still would pass existing credential handles into a make credential while registering a credential against a user, and you can't identify for a different user account that making a credential could have destructive side effects.

You're right that the user handle has much the same function as a credential ID in terms of identifying the user. A big reason why the user handle was added is that the credential ID is created by the authenticator, which makes it undesirable to use it as a database index in some cases. The user handle is instead created by the RP, so using that gives the RP greater control of its database indices.

am unsure how the userHandle attribute should be, as there seems to be some conflicting information

@sachaw Would you mind pointing out some of that conflicting information? That seems like something we should get fixed.

On 2020-03-18 call: @sachaw -- please update? @sbweeden indicates interest in crafting a PR.