authData in attestation vs authenticatorData in assertion naming?

[subyraman]

authData in attestation and authenticatorData in the assertion represent the same interface but are named differently. Is there a reason for this asymmetry? Would it be possible to make them both consistent as authenticatorData to avoid any confusion here?

[subyraman]

I see this is a duplicate of #892!

[emlun]

It's not quite a duplicate of #892 - that issue was just about the variable names used in the algorithm specifications, not the names of the members in the data structures. Basically, this asymmetry is a remnant from earlier design decisions.

I think the main reason for this asymmetry is that the member name authData in the attestation statement is included in the CBOR object returned from the authenticator, and the length of the member name thus impacts the size of the message that needs to be transmitted over a perhaps limited-bandwidth channel. authenticatorData on the other hand is transmitted without a name, so its length does not impact the size of the message.

In truth, though: at this time the above is a pretty weak argument since CTAP actually uses the single byte 0x01 as the key for the authData member, which the client then repackages with the string authData as the key instead (this is possible since the member name is not signed over) - see #864.

Anyway, fixing the asymmetry at this point would be a breaking change we don't want to make. It could be worth considering for L2, though.

[apowers313]

Similar to #854 too.

[equalsJeffH]

on 29-Aug-2018 call: We are going to just live with this asymmetry.