I do believe that this new approach provides a number of benefits. I would like to describe our use case to make sure that is can be effectively handled by this approach.
We have a centralized identity manager that handles authentication requests for our enterprise. However, not every authenticated user is actually authorized to use every resource. The authentication decision is centralized, but the authorization decision is local to the wiki. I intentionally named Extension:PluggableAuth that instead of PluggableAuthentication or PluggableAuthorization, since both the authentication and authorization pieces are pluggable. Authenication and authorizatoin are handled a bit differently. Further, different wikis, despite sharing the centralized authentication service, will have different sets of authorized users and may, in fact, use different authorization models.
For example, I have written an authorization plugin that we use with PluggableAuth that uses a database table to maintain a list of email addresses of users authorized to use the wiki. There is a special page used by a sysop to populate that table. This works because 1) the centralized identity management system guarantees that email addresses are persistent and uniquely identify users and 2) the number of users on the wikis in question are small enough not to overburden the sysop with authorization management requests. We are considering future authorization extensions that are more robust and can more easily handle larger numbers of users. For example, I could imagine an authorization extension that would provide a rule engine and the ability to authorize or de-authorize users on a domain level rather than an individual user level.
Perhaps, following the model of the RFC, this can be handled with a REDIRECT response by the AuthenticationProvider that communicates with the central identity manager to another chained AuthenticationProvider that handles the local authorization decision. Is that consistent with the intent of REDIRECT? (In this case, I would sort of prefer that they be called AuthProviders, since sometimes the decision is whether the user can be authenticated and sometimes whether an authenticated user is authorized - but I can probably live slightly unhappily with this.)
The part I do not like about my current approach that I would love to improve is that the authorization piece requires a user object to already be constructed. Therefore, we end up with our user table littered with users who attempted to access the wiki and were authenticated but were not authorized. (I could probably, with a little bit of work, restructure the PluggableAuth code around this.) It sounds like the RFC would handle this better, since the user would not be created in the database (if I understand it correctly) until after all of the AuthenticationProviders have had their say.
However, here's the key part: the second AuthenticationProvider (the one handling authorization) needs user identifying information provided by the first AuthenticationProvider. That is, in our case, we do not know the system-wide unique identifier of the user until after the centralized identity provider has been contacted. Would the RFC be able to accommodate user identifying information being passed between AuthenticationProviders? I realize that this creates a perhaps uncomfortable dependency between AuthenticationProviders, since the second AuthenticationProvider would not be able to give a positive result in the absence of this information, but it is necessary in order for this approach to work.
Thank you for your work on this RFC.