Hi all, my connection let me listen but not speak this morning :) Our view of UMA at IDENTOS is very similar to Adrian. If RSs serve a consistent/standards API (ie a FHIR profile) the client can easily consume a resource from any RS. We are advocating for UMA to healthcare entities in Canada because of the ecosystem & privacy benefits over plain Oauth 2.0/OIDC. Although RS's in Healthcare may not accept any AS (due to compliance/regulation/etc), UMA still allows many AS to define trusted ecosystems, and allow the RO to protect resources with any of them. Another major ecosystem benefit is the Clients loose coupling between the AS or RS (or both).The AS-RS must have a pre-existing relationship in most models(is this true? only after resource registration?) In our implementation the client has a few possible positions: 1. no previous knowledge of a specific AS or RS. Normal UMA. The RqP tells the client about a specific resource/RS. The RS pushes the client to the AS 2. knowledge of a specific RS. Normal UMA. The RS pushes the client to the AS 3. knowledge of a specific AS. This differs from core UMA and aligns closer to the resource indicators(?). The client requests a general resource from the AS, and the RqP binds to a specific RS during claims-gathering. The client must register with an AS for a 'resource type', and the AS must approve the scope. The client has no preference of RS/resource as long as they know the RqP is authorized access. This case also requires the AS to inform the client of the RS (we struggled with this an eventually just added a field to the token response.. bad) Regarding George's comment: "When a client uses an RPT to request a different resource, the AS should reject the RPT" Believe the AS may accept the RPT if it's under the same PAT. In the end, the RS must make the evaluation of the RPT's permissions against the requested resource Cheers, Alec Laws alec@identos.ca