Hi Eve, Alec, Hi everyone, UMA was originally designed for B2B scenarios, whereas OAuth2 was designed for B2C scenarios. In OAuth2 the roles of the authorization server, resource server and client are co-located. This does not apply to the UMA protocol. RqP's role is not co-located with other UMA roles, RqP is like a foreigner with a passport issued in his home country. We need to specify how to issue this "passport", and how to use and control it. A good starting point could be this idea: UMA should convey the permission ticket in the form of a ticket digest to the claims provider, to have it digitally signed together with user claims and return all this as a claims token, which is pushed to the AS in an uma grant request. What does it mean? The permission ticket is extended to embrace the claims provider. Regards -Igor