There are some test cases where you expect wrong error codes in my opinion. These are:
test_zero_length_pin_auth:
- For both,
MakeCredential and GetAssertion the CTAP spec states that CTAP2_ERR_PIN_NOT_SET if pin is not set or CTAP2_ERR_PIN_INVALID if pin has been set should be returned.
test_set_pin_twice:
- The CTAP state states that in this case
CTAP2_ERR_PIN_AUTH_INVALID should be returned.
test_no_user_presence:
- The CTAP states that if no UP has been activated,
CTAP2_ERR_OPERATION_DENIED should be returned.
test_user_presence_permits_only_one_request:
- This is not defined in the spec for the same same channel. For different channels the CTAP spec states however that a "busy-error message" should be returned. Therefore I think that this test case should also expect a
CTAP1_ERR_CHANNEL_BUSY error.
test_ping_abort_from_different_cid:
- I don't know if I understand this testcase right. In my understanding this test expects the authenticator to service an INIT command while being busy with a PING transaction on a different channel and then having the PING timeout. Since transactions are said to be atomic I would expect the INIT command to immediately fail with a
CTAP_HID_ERR_CHANNEL_BUSY error code.
There are some test cases where you expect wrong error codes in my opinion. These are:
test_zero_length_pin_auth:
MakeCredentialandGetAssertionthe CTAP spec states thatCTAP2_ERR_PIN_NOT_SETif pin is not set orCTAP2_ERR_PIN_INVALIDif pin has been set should be returned.test_set_pin_twice:
CTAP2_ERR_PIN_AUTH_INVALIDshould be returned.test_no_user_presence:
CTAP2_ERR_OPERATION_DENIEDshould be returned.test_user_presence_permits_only_one_request:
CTAP1_ERR_CHANNEL_BUSYerror.test_ping_abort_from_different_cid:
CTAP_HID_ERR_CHANNEL_BUSYerror code.