Hi Igor! Thank you for these interesting topics.

How do you mean it when you say UMA was design for B2B scenarios? Can you give an example of its B2B-nature? Sometimes people refer to scenarios with a “consumer Bob” in them as B2C (though Alice is usually a “consumer” too, just like in OAuth).

The ticket is only consumed by the generating entity, the AS itself, but it’s allowed to have structure. However, the client can push RqP claims to the AS’s token endpoint on the RqP’s behalf. But note that if we’re in federated identity-land (vs. DI-land), this generally only will work if the “passport” came from the same “country” (the receiving AS was the IdP that issued the ID token/assertion/whatever, because of audience constraints for security). Is claims pushing the kind of thing you were thinking of?

Eve Maler | mobile +1 425 345 6756

On May 24, 2021, at 5:37 AM, Igor Zboran <izboran@gmail.com> wrote:

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