Whee. No one actually answered my question ("If the authentication module acts as a controller, but we don't want to pass all of the request context to the module, should we stuff it in parameters or a parameter object"), but that's okay.
On Sessions for Anonymous Users: I never really liked that. Sure, the website my find it convenient to track my progress across the website, but since I have a default "Prompt Me" for any cookies the website wants to set, I will most definitely reject the cookie if it's not necessary. I don't mind anonymous cookies: but they have to do something useful for me besides tracking.
Now, I know for the average Joe user, they're going to have their browsers automatically accepting cookies. And plus, session cookies expire at the end of the session, making them not a part of the "I have too many cookies problem." But I prefer dragging our session feet as long as possible (ideally until the user has logged in).
Obviously, we have to give the implementator a choice.
When it comes to sessions and identifying users, this presents an interesting use-case of Authentication. An anonymous user with a session must prove that he has the access to the same session: but there's no password: all he needs to know is the session ID. Then, when we propagate whether or not the user is authenticated, it's really two states: the user_id, and the user_session. An anonymous user with a session would look like 0 and 2sadf98y3w2r98hae83. You get the point. Both of these two uniquely identify a user, but the user_id has a lot more clout. For mission critical applications, a combination of clever logging could alert the system when there are multiple concurrent sessions for a single user (possible abuse of the system).
I think the problem is a lot clearer when you seperate authorization from authentication.
On terminology - I think login() and logout() are sufficient for our internal representations. Problems with using this terminology is it conflicts with "logging" terminology (we could use "record" though). Also, when it comes down to it, the system chooses whether or not to display "Log in" or "Sign in" on the web page.
On Captcha - In the context of the login, at least, we aren't demanding a Captcha be filled in, rather, three successive tries will require a Captcha to be filled (until a certain time has elapsed). I like this method a lot better then just locking down the account for an hour, but, for someone who can't read the captcha, they can just wait an hour til the account "unlocks"
However, this does pose an important architectural decision: should Captcha implement the interface TuringTest?
Regarding the generation of audio and text input, that is, as Arborint put it, out of our scope. Although I do agree that there is a lack of good Captcha software out there.
Also, logic tests speaking, they
must have 1. lots of tests and 2. constant maintenance. Remember: automated bots are fast, so even if they're only able to get 1 out of 40 requests through, that still comes out to a lot.
On Access Control - though I don't use it, I really like
phpGACL's system a lot. If we implement an authorization system, I would like to offer several types of authorization, from a very simple admin can only access admin place authorization to a fully fledged authorization system with user groups and roles. So let's not talk about authorization for now, please. The two systems probably can't be divorced, but we must try.
Anonymous user making requests to the site an is allowed access. It seems like there are two scenarios here. One is that there is not Access Control code included, either hard coded or a controller decision. Two is that there is Access Control code included, but the Access Control system return "authenticated" because no Access Control data/code has been provided. If we think about the Access Control Controller in its most basic configuration could be set to either Allow All and Deny All.
Okay, this is a bit sketchy on the terminology. Remember: authentication authenticates, while access control authorizes. So I'm a bit confused to see "authenticated" coming from Access Control.
Anonymous user making requests to the site an is denied access. There must be Access Control code present. The system now needs to get the user to some Authentication code. I think the choices here are Redirect or Forward -- we should probably support both.
What if a user is logged in and doesn't have necessary priviledges? Three cases: 1. Flat out Forbidden, 2. User needs to log in, 3. User needs relogin/escalate priviledges
Once again, this stuff is complicated, but is traditionally relegated to the application itself to determine. However, it's still Access Control (hehe).
After reading the progression of this thread, what if the entire thing was built around a single default user 'Anonymous' who has rights to nothing? Since there is a determination made initially as to the users id and rights associated with the id, what if we established that each unique user to the site can be identified as 'Anonymous' with a user id of say, 0. The uniqueness of the user would be determined by their session id or some other 'to-be-determined' unique identifier.
By definition, you cannot uniquely identify an anonymous user.

I just want to caution people against using session IDs to uniquely identify people: they don't: they uniquely identify SESSIONS.
This may be overgeneralizing what we are hoping to achieve, but I think that a constant state of user tracking would not add a significant amount of overhead and could easily be applied without condition for all users.
See my reasons against it above. Of course, we will allow it.
Well, if the Authenticate class and ACL class are good enough, then you could recommend them for Zend Framework.
I would think they'd already have that? (checked, it doesn't look like it). Maybe.
Or maybe I am just getting ahead of myself. But it might something we need to consider. If someone uses the authentication app throughout their site and there is no protocol for anonymous users, what is that going to do to their setup?
Well, that's really the access control's problem. They'd have to default all.
I was thinking of site-wide authentication. Although I suppose this would probably be a conditional case. Which I guess would make sense. If the authentication application is modular then a developer that is implementing the app can choose to apply it only to certain sections of a site. Unless movement of the user is to be validated/authenticated across the entire access area for a user, in which case the authentication protocol should be applied site-wide.
An application with a front controller or a common include would be able to load the Authentication module every time. Personally, I'd do it, simply so that the skin could always say to the user, "Logged in as User234". Modular authentication, oh ho, I don't think the minimal overhead benefit justifies the added complexity.