Hi Eve,

I'll explain my thought processes :-) By B2B I mean human interaction between companies e.g. in the automotive supply chain - the company's purchasing agent is not a customer / consumer, the company is a customer. Wikipedia states that UMA was influenced by the goals of the Vendor Relationship Management movement. So I came to the conclusion that UMA was designed for B2B scenarios. I am sorry if I was wrong.

By B2B-nature of UMA I mean: RqP is an employee of the other company with a "passport" issued by his home company.

I know that the ticket is allowed to have a structure, but in this case it is not helpful. To clarify the main idea of the original sentence, I replaced the first word "UMA" with "The RqP Client", which means I was thinking of pushed claims.

The RqP Client 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.

There is no need for an audience claim if you have the signed ticket digest.

This should work even if the “passport” came from the "foreigner's home country”.

The claims provider publishes its metadata on a URL: .well-known/claims-provider-configuration, ideally, on 'https://' + domain_part_of_rqp_email_address + '/.well-known/claims-provider-configuration'.

The claims provider should be protected by a local AuthN/AuthZ server.

Here I published some preliminary sequence diagrams: https://github.com/uma-email/poc

It's still more of an idea than a real concept.

-Igor

On Mon, May 24, 2021 at 1:41 PM Eve Maler <eve@xmlgrrl.com> wrote:

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