The question is reasonable.
Web applications are going to need to store data between requests that's associated with either the user, or the specific request. The typical mechanisms -- hidden form values, server side state, and cookies -- all have their advantages and disadvantages.
When storing information specific to a given request, I tend to default towards hidden form values, because it offers the best scalability (no server-side information store). The downside is, of course, that the page can become bloated if you aren't careful about exactly how much information you store. You also need to ensure that the posted-back data is valid, since it could be tampered with by bad guys (digital signatures and encryption both being reasonable solutions).
So to me, your solution seems perfectly reasonable. I have done similar things in the past (with my Dynamic Data for MVC sample), even going so far as to build a custom model binder which allowed me to get access to the deserialized object directly in my action methods (which made unit testing them simpler, since they weren't relying on having encrypted data in form fields).