"credential ID" not signed over by authenticatorGetAssertion operation

[equalsJeffH]

I note that in authenticatorGetAssertion operation, the "credential ID" not signed over -- i.e., it is not included in authenticator data because no attObj is contained in the authenticator data returned by this operation. As I (vaguely) recall, we discussed this long ago and determined that the worst downside of a buggy authenticator returning an incorrect credential ID is that the RP will not look up the correct cred public key with which to verify the returned signed authenticator data (aka assertion) and the overall ceremony would thus end in error.

we should probably document this rationale and consequence somewhere in the spec.

[equalsJeffH]

a piece of this puzzle is also that in CTAP, the credential ID returned by authenticatorGetAssertion() is optional if allowList has exactly one member -- see #472

[rlin1]

TODO: Address in Security Considerations section.

[nadalin]

@selfissued Need to add to security considerations section, see @jcjones

[emlun]

@equalsJeffH

the worst downside of a buggy authenticator returning an incorrect credential ID is that the RP will not look up the correct cred public key with which to verify the returned signed authenticator data (aka assertion) and the overall ceremony would thus end in error.

Is that even a downside? That sounds to me like exactly what you would want to happen if the authenticator bugs out like that.

On the other hand you could get false positive authentications if the RP doesn't bother to verify the signature, or somehow by dumb chance happens to use the correct public key anyway, but at that point the entire exercise is moot anyway since the false positives would also include malicious authentication attempts.

[rlin1]

Note: This is about documenting the rationale for not signing over the credential ID - it is not about changing the assertion structure.