Why store WebAuthnCredential using a custom ID that is provided by the client?

[Joride]

The id used to store a WebAuthnCredential is generated by the client (e.g. browser ), as explained in the spec.
As I understand, as part of the sign-in ceremony, the client will look for all credentials stored locally for a given relyingparty (e.g. domain), and give the user the option to select one to use to authenticate.
Then, the client will send the data of the credential selected by the user to the server.
This data contains :

• the id mentioned earlier
• a username
• and the response to the challenge sent by the server
• some more data not relevant for this question (I think)

Two questions on this thinking (assuming I wrote it correctly):

1. Can the ID generated by the client be assumed to be globally unique for a given relyingparty?
2. Why not use the username as ID (provided the server and UI will prevent duplicates)? This is actually what I am currently doing.

[0xTim]

Very late reply but:

1. Yes you should be able to assume that the client can generate a unique ID (for that site).
2. Username as an ID works great until someone changes their username/email and then it breaks down. Having it tied it to a separate unique ID makes things simpler as you scale/evolve