I don't see the difference between a Captcha and a user account. In both cases a known credential is created and the user is challenged to provide the known credential. It doesn't matter whether the lifespan of the credential is for the current request, a day, a month or a year. All the authentication system cares about is matching one or more credentials from the request with one or more known credentials in its Datasource. If there is a match -- authenticated.
With Captcha the datasource is the session and a new credential is created every request. With a standard user account the datasource is a database and the User ID/Password are created by the user or an administrator.
Okay, I can't agree with that. At least, not within the scope of our current discussion. Let's first consider what a captcha is:
Captcha - A CAPTCHA is a type of challenge-response test used in computing to determine whether or not the user is human.
Where does "authentication" or "credential" come into the definition?
Credential - that which entitles one to confidence, credit, or authority. In our case, it's authentication (perhaps credential isn't a good term for it).
Authentication - the verification of the identity of a person or process. In a communication system, authentication verifies that messages really come from their stated source, like the signature on a (paper) letter.
So where's the confusion? In this case, we're taking "credential" to mean something that must be matched against a known source in the website (to, according to our definition, make the system recognize you as a valid user). This definition seems perfectly valid until you add the parentheses. A captcha is not meant to act as a credential in order to authenticate you as someone it knows about. A captcha is meant to distinguish a user from a bot.
That's why anonymous users can use Captchas without having an account.
Admittedly, matching user-supplied input to a known datasource to verify "something" is a common problem between the two, but in the context of Authentication, there is no reason why the AuthManager should be able to "verify the validity of a CAPTCHA".
So my question was: if the the Access Control system is used after Authentication, how is the User ID passed forward? Is there a corresponding $access->setUserID() for your $auth->getUserID() ?
I would expect so. The reason we're not passing user ids around, however, is because there might be other information the authentication manager has (such as which credentials were used to authorize a user), so the best idea is to make the manager itself globally available.
And what about any other applicable data that the Authentication manager happens to currently have -- that would save a redundant access to the datasource?
This data is different from "which credentials were used to authorize a user". In the former case, we're talking about extra, request-specific info. In this case, we're talking about cached data. I would imagine a caching layer would make most sense to be transparently built into the datasource/session, so that the authentication manager itself doesn't know about it. So yes, the datasource may need to know about the session (though isn't that what a session is: another datasource?)