You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
There are some test cases where you expect wrong error codes in my opinion. These are:
test_zero_length_pin_auth:
MakeCredential
andGetAssertion
the CTAP spec states thatCTAP2_ERR_PIN_NOT_SET
if pin is not set orCTAP2_ERR_PIN_INVALID
if pin has been set should be returned.test_set_pin_twice:
CTAP2_ERR_PIN_AUTH_INVALID
should be returned.test_no_user_presence:
CTAP2_ERR_OPERATION_DENIED
should be returned.test_user_presence_permits_only_one_request:
CTAP1_ERR_CHANNEL_BUSY
error.test_ping_abort_from_different_cid:
CTAP_HID_ERR_CHANNEL_BUSY
error code.The text was updated successfully, but these errors were encountered: