[WG-UMA] UMA Deep Dive

2 views
Skip to first unread message

Igor Zboran

unread,
May 24, 2021, 6:37:27 AMMay 24
to Eve Maler, wg-uma@kantarainitiative.org WG
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

Eve Maler

unread,
May 24, 2021, 7:41:35 AMMay 24
to Igor Zboran, wg-uma@kantarainitiative.org WG
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 <izb...@gmail.com> wrote:



Igor Zboran

unread,
May 24, 2021, 12:48:05 PMMay 24
to Eve Maler, wg-uma@kantarainitiative.org WG
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

Igor Zboran

unread,
May 25, 2021, 9:19:11 AMMay 25
to Eve Maler, wg-uma@kantarainitiative.org WG
A few notes:

The ticket digest can be a SHA256 ticket hash encoded in Base64 (it's like code_challenge in PKCE rfc7636). Inspired by the PKCE rfc, the ticket digest can be referred as ticket_challenge:

ticket_challenge = Base64URL-Encode(SHA256(ticket))

UMA - networking features:

RqP Client can be registered by resource owner as a public client with well-known name e.g. aems_network or clinic_network, so that anyone (RqP) being on the other side, with a proper RqP Client, who can demonstrate control of their email_address, can access owner's resources (resources are filtered on RS by RqP email address).

The resource owner can be admin, who registered the public client, 'Incoming' and 'Outgoing' resources and set up the relevant rules. When both Alice and Bob have servers preconfigured in this way, they can communicate with each other. Alice can push the links to her files to Bob, and Bob then downloads the files from Alice - and vice versa. It's RqP to RqP communication with authorization on both sides.

-Igor

Reply all
Reply to author
Forward
0 new messages