Dictionary members should be ordered lexicographically per Web IDL Standard

[zacknewman]

Per Web IDL Standard:

The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered before non-inherited members, and the dictionary members on the one dictionary definition (including any partial dictionary definitions) are ordered lexicographically by the Unicode codepoints that comprise their identifiers.

For example, with the following definitions:

dictionary B : A {
  long b;
  long a;
};

dictionary A {
  long c;
  long g;
};

dictionary C : B {
  long e;
  long f;
};

partial dictionary A {
  long h;
  long d;
};

the order of the dictionary members of a dictionary value of type C is c, d, g, h, a, b, e, f.

This means that while dictionary definitions in the spec are fine since the order of members only applies to values of the dictionary, most of the payloads I have seen in the "wild" simply follow the order of the definitions. Here is an example in the spec itself that violates Web IDL (e.g., among other ordering issues, authenticatorSelection should be the first member of publicKey). If the dictionary definitions were ordered the way values must be ordered though, then I believe implementations will be less likely to violate the Web IDL Standard since clearly most RP library maintainers are not reading Web IDL Standard but instead follow the order of the definitions they see in the WebAuthn spec.

[emlun]

I think this order only applies to the internal dictionary representation that determines things like iteration order. I don't think it's meant to be enforced for parsing values in language bindings. I'll have to review the WebIDL spec some more before I'm sure, but I don't think there's any issue with the spec examples.

[zacknewman]

Honestly I know next to nothing about Web IDL. I only started looking at it since you mentioned it in #2082. If the order does not matter, then presumably #2082 should be closed? Is there any recommendation at all on the order of fields? Lexicographic order like Web IDL? Source definition order? In the RP library I am writing, I initially adhered to the source definition order when serializing data, but I then switched to the order mentioned in Web IDL. I realize it likely does not matter what order I use, but I'd rather use the "safest" order if there is one.

[emlun]

I'll keep #2082 open because layout consistency is good for readability even when not formally required.

Is there any recommendation at all on the order of fields?

For how RPs should order fields in JavaScript representations of the options objects: no, order should not matter at all.

The low-level CTAP protocol does care about serialization order, but that's a different protocol which is not exposed to web applications and is not defined in WebIDL.