Design question for a service that signs messages on behalf of a user

I'm working on a messaging service that lets users author messages and have them signed with an RSA key. The key is used for identity purposes only and can be revoked, so compromising the private key is annoying, but does not expose proprietary information.

Still, in order for a service to sign on behalf of a user, that user must either provide the key's passphrase (or even the key and passphrase) and have it go over the wire on each signing, or the key is stored by the service without the user's passphrase.

In either case the service itself must be trusted since at some point they will have access to the key in an unprotected form.

So the question is, what is the better design (other than "don't do it"): require the passphrase on each signing event, or rely on the service to store the key without the original passphrase and require them to ensure safe keeping (using their own passphrase, encrypt it otherwise, etc). Or is there a third way by which the service can sign on behalf of the user without exposing the private key at all?

Clarification: The idea is that the user maintains portability of their identity, i.e. they could use their key to sign and publish messages themselves or provide the key to a new authoring service they pick instead, i.e. the key follows the user, not the service.

-
Let me see if I have this straight. Every use has a public and private key. But they won't sign messages themselves, instead the server signs the messages. –  mikeazo Aug 9 '12 at 17:07
"require them to ensure safe keeping" of what? $\:$ –  Ricky Demer Aug 9 '12 at 17:18
@mikeazo Correct. I want messages that can be authenticated as unaltered and originating from a specific user, but provide this as a simple authoring experience from a web app. Messages are passed in a heterogenous system, i.e. the authoring service isn't the authority to vouch for identity. The underlying ecosystem is described here: claassen.net/geek/blog/2012/07/… –  Arne Claassen Aug 9 '12 at 17:21
@ricky safe keeping of the private key. I.e. if the web service is compromised, the key shouldn't be persisted in unencrypted form. –  Arne Claassen Aug 9 '12 at 17:22