First of all you refer to UMA 1.0.1 which is not supported by Gluu 4.0 since it's old. Gluu 4.0 supports UMA 2 only.
Spec of UMA 2:
> The PAT is supposed to identify / bind RS/set, RO and AS together and allows for indicatign to AS what resource set the client is attempting to access etc.
It seems you refer to this snippet of UMA 1.0.1 spec
One circumstance precipitating this action is when the client has attempted access without an RPT (as described in Section 3.1.1). In order for the resource server to know which authorization server to approach and which PAT (representing a resource owner) and resource set identifier to supply, the resource server's API needs be structured in such a way that it can derive this information from the client's RPT-free access attempt. In practice, this information likely needs to be passed through the URI, headers, or body of the client's request.
It's about Resource Server implementation. If RS protects resources against multiple AS or use different clients for different resources then RS should handle it in appropriate way. Do you have usecase where you wish to use different clients/PATs for different resources?
> Could you please clarify the behaviour of GLUU wrt PAT tokens?
If under Gluu here you mean oxauth then from AS perspective it validates PAT during access to Permission Endpoint or Resource Endpoint or RPT introspection. PAT is access_token so it's validated whether token is valid or not. AS knows which client is used for given PAT.
Among Gluu products there is oxd middleware which can act as RS. In this context oxd manages PAT per client. If client1 is used to protect/access resources at RS then PAT1 is used. If client2 is used then PAT2 is used. oxd check PAT expiration and re-new it if PAT is expired. oxd is using `client_credentials` grant to obtain PAT.
oxd RS API: https://gluu.org/docs/oxd/4.0/api/#uma-2-resource-server-apis
Hope it helps,