Would this RPC ever be used in a different case that isn't secondary device auth? I'm wondering if we should pick a different name. For instance, UploadKeysForRegisteredDeviceAndLogIn.

I spent some time looking at the whitepaper, and I can't find any other examples of "New Device and Comm run Key Upload (5.2.2) and Existing Device Log-in (5.3.6)" occurring, so I think we can probably leave it as-is, unless you prefer the alternate name I proposed.

In the whitepaper, I think this request is described as "New Device and Comm run Key Upload (5.2.2) and Existing Device Log-in (5.3.6)".

I think you're taking a slightly different approach here. Instead of a proper "Existing Device Log-in", you're authing the user just based on their DeviceKeyUpload.

I don't think this is as safe. By skipping the nonce and timestamp steps, you make the system hypothetically vulnerable to replay attacks.

Realized that this message is repeated many times in this file:

• RegistrationFinishResponse
• OpaqueLoginFinishResponse
• WalletLoginResponse
• This case: SecondaryDeviceLoginResponse

Is there a reason we're repeating it so many times? Does it make it easier to make changes later if we need to?

Glad you raised this. Yes, this RPC is intended to be called in this only specific case (QR code auth).
My name isn't perfect but I didn't have any better idea. I'll follow your proposal.

This is my bad, I treated our password/wallet login RPCs as "Existing Device Log-in (5.3.6)" but now looking at LogInWalletUser RPC implementation I see that it indeed validates the nonce.

Yeah I noticed this pattern too, so I followed it.
This probably can be merged into one message unless I'm missing something, cc @varun.
If so, I can create a task and do this. But I prefer doing it separately from this stack, for clarity.