I don't like the idea of creating new users just for any application. I favour the model that eBay uses, where eBay creates for the user a special token, tied to the username and the application it is to be used with. In the case of PM, we could create such tokens based on the user name, the proxy name and the rights the user wants to grant the proxy.

That will of course need another table to manage the tokens, and checks in all actions that are available to the proxy, but I'd prefer this, as in a case of emergency or a compromised proxy, it's very easy to wipe out all access for that proxy.

As I see it, the workflow would be like this:

1. The proxy tells the user its name and what permission it would like, or redirect sthe user to a page on PerlMonks which is set up with the proxy name and the wanted permissions.
2. The user accepts or modifies these permissions, and is sent to a second page on which PerlMonks displays the token, which the user then pastes into the proxy administration page.
3. Alternatively, the proxy could supply a redirect URL to which the user is redirected after setting up the token, just like eBay does. This would allow closer integration of the authentication into the proxy application, but also open up a vulnerability potential for cross-site scripting attacks.
4. The proxy acts on behalf of the users using their tokens
5. If a user does not submit the request from step 2, no token is generated
6. Token revocation is easily maintained by the user in a separate step. Of course, token maintenance cannot be farmed out to proxies.