What's wrong
Ctap2GetInfoResponse (get_info.rs) deserializes maxMsgSize (0x05), maxCredentialCountInList (0x07), and maxCredentialIdLength (0x08), but nothing reads them. The builders Ctap2MakeCredentialRequest::from_webauthn_request (make_credential.rs) and Ctap2GetAssertionRequest::from_webauthn_request (get_assertion.rs) receive &Ctap2GetInfoResponse yet copy allowList/excludeList through unchanged. The client never drops over-long credential ids, never chunks by the count limit, and never bounds the request by maxMsgSize (1024 bytes when absent).
ctap2_preflight (preflight.rs) trims the allow list to one credential per probe, but only when C::supports_preflight() is true. Cable overrides it to false (CableChannel::supports_preflight()), so the full allow list goes in one getAssertion. excludeList is always sent in a single request, and even the post-preflight allow list can carry several entries.
Why it matters
Over-limit lists make the authenticator reject the whole ceremony (CTAP2_ERR_LIMIT_EXCEEDED, CTAP2_ERR_REQUEST_TOO_LARGE, CTAP1_ERR_INVALID_LENGTH) or get dropped by the transport, with opaque device-specific failures. An id longer than maxCredentialIdLength cannot belong to the authenticator, so it should be filtered client-side. This hurts most on hybrid/cable, which has no preflight to trim the list.
What to do
Spec: CTAP 2.1/2.2 §6.4 authenticatorGetInfo.
What's wrong
Ctap2GetInfoResponse(get_info.rs) deserializesmaxMsgSize(0x05),maxCredentialCountInList(0x07), andmaxCredentialIdLength(0x08), but nothing reads them. The buildersCtap2MakeCredentialRequest::from_webauthn_request(make_credential.rs) andCtap2GetAssertionRequest::from_webauthn_request(get_assertion.rs) receive&Ctap2GetInfoResponseyet copyallowList/excludeListthrough unchanged. The client never drops over-long credential ids, never chunks by the count limit, and never bounds the request bymaxMsgSize(1024 bytes when absent).ctap2_preflight(preflight.rs) trims the allow list to one credential per probe, but only whenC::supports_preflight()is true. Cable overrides it to false (CableChannel::supports_preflight()), so the full allow list goes in onegetAssertion.excludeListis always sent in a single request, and even the post-preflight allow list can carry several entries.Why it matters
Over-limit lists make the authenticator reject the whole ceremony (
CTAP2_ERR_LIMIT_EXCEEDED,CTAP2_ERR_REQUEST_TOO_LARGE,CTAP1_ERR_INVALID_LENGTH) or get dropped by the transport, with opaque device-specific failures. An id longer thanmaxCredentialIdLengthcannot belong to the authenticator, so it should be filtered client-side. This hurts most on hybrid/cable, which has no preflight to trim the list.What to do
Ctap2GetInfoResponsefor the three limits with spec defaults (maxMsgSize = 1024 when absent, the other two unbounded when absent).idlength exceedsmaxCredentialIdLengthbefore sending.maxCredentialCountInList: batch across requests where the flow allows, or return a typed error when a single required request cannot fit.maxMsgSize, and fail before sending if it still exceeds after filtering.PlatformErrorvariant inwebauthn/error.rs) instead of relying on the CTAP status.make_credential_fido2andget_assertion_fido2(webauthn.rs) so cable is covered.Spec: CTAP 2.1/2.2 §6.4
authenticatorGetInfo.