Is there a reason to not send signed FIDO2/WebAuthn session data to the client rather than storing it server side?
Every WebAuthn implementation I've seen stores the session data server side, but that just seems pointless to me, since what seems to be essentially all the same data is already sent to the client in the options.
(For clarification what I'm calling "Session Data" essentially amounts to configuration, the challenge, userid, and timeout like seen in https://github.com/go-webauthn/webauthn)
The WebAuthn spec says
"[The challenge] MUST be randomly generated by Relying Parties in an environment they trust (e.g., on the server-side), and the returned challenge value in the client’s response MUST match what was generated. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete. Tolerating a mismatch will compromise the security of the protocol."
But if the Relying Party verifies the challenge through a valid signature, why would it matter which party stored it?
Is it that the locally stored challenge is consumed and then cannot be replayed?
