====
The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.
Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.
With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of
non-uniquely identifiable claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this
talk), a single "credential score" may not work so well.
(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See
this section. Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)