Shekhar takes me to task for what he perceives as a bias towards pull-based authorization (and against push-based models).
I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain.
Actually, in listing out the permutations, we explicitly called out that we were not making any assumptions about the actual mechanism by which authorization data was transferred
It’s important to note that the above diagrams are intended to show configurations of components, not information flows. For instance, for any configuration that involves the sharing of subject attributes, these may be included in the actual request to access a resource, or they may be requested by the AEF (or other component) from the subject after receipt of the access request,