Before too late, it is better for us to define the way to assign the flags.
We have been suffering same problem when handling the resident key feature (#1191).

Do you mean to say that during the discussions of the resident key feature (PR #1191), we did consider assigning one of the "Reserved for Future Use (RFU)" flags, and in that discussion we were unsure how to go about about assigning one of the RFU flags for that purpose?

One simple way is that we assign the version number for the data structure within the extension if the authenticator supports it.

I am unsure what you mean here -- perhaps you could provide a worked-out example?

Do you mean to say that during the discussions of the resident key feature (PR #1191), we did consider assigning one of the "Reserved for Future Use (RFU)" flags, and in that discussion we were unsure how to go about about assigning one of the RFU flags for that purpose?

Yes. I think we don't have any feasible way to consume the RFU bits.

I am unsure what you mean here -- perhaps you could provide a worked-out example?

In current WebAuthn spec, we don't have any version information. So, from the RP perspective, new flags in Authenticator Data cannot be distinguishable from the old one. For doing this, we should have some distinguishable information like version. E.g., authenticator can return the version information within the authenticator extension that it supports.

I am thinking that addressing (or not) how we allocate Reserved for Future Use (RFU) authnData.Flags bits for some purpose(s) is better accomplished in FIDO Alliance in CTAP context. Also, it may be the case that given that WebAuthn+CTAP are extensible, and we will never allocate the RFU bits.