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