Yes, I think this sounds right, too. A simple service contract approach would make it easy to do authentication plugins.
One problem comes to mind. We allow for a variety of new registration policies - open, admin must approve, e-mail verification etc. These are by their nature dependent on the authentication system being used. In fact in many cases the policy will be transparent to OpenACS (i.e. the foreign authenticator sets the policy for new registrants).
So ... this alone isn't really a problem but leads to my thinking (out loud, as I type this) that some care needs to be taken in defining exactly the contract that ties together our end to the authentication package (one of which would be a refactored version of the current authentication code).
The old acs-ldap package shadows externally-authenticated users in the local database. We need a party object id for perm checking and all that. So that's another area that needs to be thought out ...
