You're quite right, it is limited. On the other hand, it allows the user, and only the user, to change his password at any time also, so stealing the password will be of very limited value as well. And it seems a trivial limitation when real passwords could be harvested so easily around here.

Your suggestion would also work, and is a bit more efficient than what tilly had suggested. Since under my scheme the user could be assigned, or forced to adopt, a new, local password upon first authentication, the only real difference is the level of automation.

Also, with your scheme, there is extra work for someone... the person who must automate the /msg. If this seems trivial, then consider also the difficulty of adding a single textbox to a form, a single field to a database table, and what must be close to the simplest of all CGI programs.

But yes, what I have suggested is quite limited, and what you have suggested is a very comparable scheme. Perhaps more interesting would be to consider the real objectives. A great scheme, as I think of it, would:

1. Automatically allow access to a second site for anyone with a PerlMonks account, while maintaining the user's identity
2. Allow this access in a way that was as transparent as possible to the user (ideally requiring no work on the user's part)
3. Not give the proprietors of one external service any ability to masquerade as the user at another external service, and
4. Be easily implemented, whether by vroom or someone else (more important if it's vroom).

My suggestion achieves 1, 2 and 4, with the ability to change passwords limiting the problem of failing to achieve 3.Yours achieves 1, 3 and 4, and while it's less efficient on 2, it's not that bad on that account. I wonder whether we can come up with something which achieves all 4.