Logic for responding on unknown Auth Ctrl value about ctapkey HOT 2 CLOSED

The check for if the type is known or not in the two sections of the code is done for robustness and future proofing.

Each function knows what it is able to process or not independently of the other. This means that if additional Ctrl states were added to u2f.DecodeAuthenticatorRequest it wouldn't break the assumptions of ctapkey.handleAuthenticate.

If this were written in a language like rust we could enforce this safety at the language layer by using a proper enum and an enforced check that we handle all values of that enum. But we don't have that in Go so we write a bit of extra code to gain that safety.

In terms of when we send a response, U2F is a polling protocol that has short timeouts and retries baked into it. The browser isn't expecting a response until the authenticator has something interesting to report.

But also, we are under no obligation to respond to requests we don't understand or that break the state machine. If something is broken a log message in the authenticator application will be able to provide more useful information to the user than a generic error back to the browser or the relying party.

from ctapkey.

Thanks for the clarifications! this made sense to me: "we are under no obligation to respond to requests we don't understand or that break the state machine. " Closing this.

from ctapkey.