Multi Party Delegation –It’s not UMA ….Yet!

Multi Party Delegation

Tuesday 3B Convener: Justin Richer

Notes-taker(s): William Kim

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

MPD Not UMA

Justin Richer and team working on UMA implementation on top of MITREid-Connect project, found a lot of architectural decisions in the UMA protocol that made implementation difficult. Collected issues over 9 months of UMA implementation.

Earlier this year, took lessons learned and implemented into system--called it Multiparty Delegation (NOT compatible with UMA protocol!)

Justin: "Simplified the system, and made it more flexible at the same time".

Eve: UMA recent history. UMA 1.0 achieved acceptance March 2015. Then did 1.0.1 in December and addressed bunch of bugs. Collected non-backwards-compatible issues and 2016 roadmap for changes. Number of buckets: security, IoT, simplification, i.e. how it can be better aligned with OIDC/OAuth e.g. Can it be a true profile of OAuth 2.0?

MPD was developed with requirement that two users do not have to have accounts on the same server. Lead to "wide ecosystem" UMA use case.

Desirable to be able to cleanly place UMA on top of existing OIDC/OAuth setups, but wasn't possible with UMA 1.0.

Description of MPD flow (Notetaker's Disclaimer: may be missing parts):

Resource Owner flow.

Start by starting authentication session with Relying Party using local OIDC server. Unchecked UMA managed resources scope.

Now share resource to MPD server. First, declare the MPD server URL, which kicks off discovery and registration

Get presented with scope authorization screen with the UMA managed resource scope checked (UMA protection). Protection Access Token still there and works in the same way

Specific mechanisms of how this happens differs from UMA protocol (e.g. data structures, syntactic differences in resource set registration)

At this stage, pretty much still UMA with some syntactic changes.

UMA Discovery, OIDC Discovery, and OAuth Discovery were all different before.

Made alignments on UMA to OIDC Discovery.

Now Requesting Party shows up, and now its very different from UMA.

No AAT

If Bob already had account on the AS, then it would work, but this is the narrow ecosystem use case.

Pointer to AS and permission ticket MUST comes back in the header in MPD version to the Client.

UMA requesting resource one scope at a time, but developers would implement it just get all the scopes at once. It was entirely on the RS to make the call for what permissions it needs to ask for

George: Analogy for phone app asking for all the permissions up front vs. at run time.

Eve: 1. Multiple resource sets, each with it's own scopes -- complicates potentially what the client actually wants. 2. It's up to Alice (resource owner) to decide what get shares.

Justin: No, the AS ultimately decides which scope gets shared (Disagreement)

Client requested resource.

Now AS has to do some set math, scopes that the Client has requested, and scopes that Client is authorized

Also, set of policies that apply to this authorization, each of those may have scopes.

One way to handle this is to interactively involve the requesting party,

"Claims gathering endpoint", aka interactive claims gathering endpoint. In MPD, it uses OpenID Connect and it's an RP, but doesn't necessarily need to be--just needs some some way to prove the Requesting Party. "Just go get something from the RqP". 

Two ways to attach claims to a permission ticket, claims gathering endpoint or claims pushing to the endpoint.

UMA Token Profiles? Introspection vs Structured tokens

Adrian: Doesn't work with HIPAA unless the RS gives Resource Owner gets warning that Client is trying to get access.