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.
Store the key encrypted. Send the encrypted key to the user and have them decrypt it and sign the message. Whatever your objections are to this scheme, they are most likely either misguided or can be addressed by the implementation of the scheme.