Second try at this after the wiki turned my first one into a repost of the main article...
Sorry, Heiko, this page was really notes to myself and wasn't really in a state for publication. But word of it got out into the wild and it needed to be made visible. I'll try and clean it up today.
The initial timing part was very much notes to myself. I do believe that's reasonable for a design phase though.
About "Request Attributes"...
The basic idea I had in mind is that authorization decisions would be made by some sort of authorization engine. The AS would define an SPI for this engine with an available set of inputs that would be provided to the engine and an expected set of outputs -- permit, deny, perhaps other stuff like the XACML "obligations" notion.
The inputs would be from 4 broad categories
1) Information about the operation.
2) Information about the resource being accessed
3) Information about the caller
4) General environmental stuff, e.g. time of day, interface the call came in on, etc. (This last is conceptual only and not something I propose dealing with in AS 8)
The "Request Attributes" bits above are notes to myself to identify what stuff from categories 1) and 2) above we would need to provide to a rules engine to provide sufficient input for a set of rules that map to the various "roles" concepts that we've seen in different permission schemes we've heard about. It's basically thought on how to pursue the "Rules based approach" in the wiki article Anil linked.
The idea I had at its core is the authorization system could be as flexibile as the rule grammar and the available inputs will allow. Directly configuring the set of rules allows the user the maximum flexibility. This is not something I see as being in scope for AS 8 though.
For AS 8 (and forever really) we need a simplified system with a limited number of config options that internally generates (or statically defines) a set of rules that results in behavior like one of the schemes I listed. So, if user is in role "Operator", the rules would verify whether the operation is read-only, whether the resource or attribute description has a security restriction associated etc.
Basically, the simplified system is a shorthand way of expressing a fairly complex set of rules in a user-friendly fashion.
For the future, we can see if there are other, more flexibile shorthands for creating rules (e.g. a regex scheme.) Or, if appropriate we can provide direct configurability of the rules engine.