Currently, it is assumed that Alice is both the policy owner and who pays for policies. That's fine as a basic use case, but it limits other potential use cases and causes friction for users that don't regularly operate with ETH (see #1406).

The main value proposition of NuCypher, IMHO, is empowering policy owners to decide how to share their data. Linking that to payment is not strictly necessary. Or to be more precise, payment is indeed necessary to compensate the service, but equating policy ownership to policy sponsorship is not.

What I propose here is to separate both roles (yeah, another separation...).

Broad idea of the proposed changes:

• PolicyManager.createPolicy() accepts a new parameter _policyOwner, which is a public key for a signature, in the form of an address. PolicyManager.createPolicy() assigns the ownership of the policy to this _policyOwner instead of msg.sender.
• When revoking, again, it shouldn't be necessary for the policy owner to spend ETH (i.e., gas in a TX). However, this implies that the policy owner has to somehow "authorize" the revocation; Currently, such authorization is implicit in the TX, as it's signed. Hence, we would have to implement something similar, e.g., a signature of the revocation call including the policy ID (and node address in case of revocation of an arrangement). Since _policyOwner is an address we can accept both a signature from this public key, or the revocation being called from this address (to support use contracts as policy owners too, see Make sure we support Policy authors to be smart contracts #1406).
• Note how the policy sponsor is almost irrelevant (as long as they pay :P ). The only caveat is that refunds should go back to the sponsor.

Potential extension:

• @michwill points out that Bob should also be able to revoke policies (e.g., he has been hacked). This one is trickier, as naive solutions imply identifying Bob to the policy manager contract. A tentative solution to include Bob in the mix is that the _policyOwner is an ephemeral public key whose corresponding private key is shared between Alice and Bob; that way, both can equally revoke, giving an additional deniability property (i.e., it'd be impossible to know who revoked). Note also that Alice doesn't have to do this if she doesn't want to: again, continuing our narrative of empowering Alice, at policy creation she can decide if she wants to share the power of revocation with Bob or not. However, I haven't thought deeply about this extension, and it's possible I'm missing something.

Alternative?
In #1406, there's another solution to the same problem:

this can be done by the DApp by setting up a contract acting as the policy author. Since Alice's ETH key is not tied anyway with her cryptographic keys (i.e, signing, encryption, delegation), it seems that in principle this approach has a lot of sense for this use case.