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.
It's still more of an idea than a real concept.