Hi Everyone,

Mohammad intended to response to the minutes from UMA telecon 2017-01-19 about Issue 260  https://github.com/KantaraInitiative/wg-uma/issues/260 but apparently, his message was not published [shown below].

So I am resending since I agree with him that issues raised in the WG seem to be based on policy that the example use of Cascading OAuth that Mohammad presented exemplified.  Other policies would make very different rules about which AS is “on first”. 

I know that there’s no time until late in February to have further discussions on our request that UMA WG consider this proposed profile.

I’ve requested time at the next available agenda slot.

Thank you for this first round of discussion.

-K

· Putting the RS in charge of orchestrating the cascaded authorization flow will involve the RS in making authorization decisions and handling authorization logic, including policy processing. The RS will have to decide what ASes need to be consulted and how to combine their decisions. Such arbitration must inevitably be based on some policy rules and this will end up putting the burden of authorization and policy processing on the RS, which is contrary to separation of concerns, and also defeats one of the primary purposes of UMA, which as I understand, is to take the  burden of policy processing off the shoulders of the RS. In other words, let’s draw a rectangle around that component in the RS which is in charge of this orchestration and handling these authorization decisions and call it the “Downstream AS”.

· The question of who controls each AS is a matter of policy and orthogonal to this design. The downstream AS is the eventual arbiter that should decide for any given access request, what ASes must be consulted and how their decisions must be reconciled and combined. Moreover, in the process of combining introspections from the upstream ASes, the downstream AS has the authority augment/abridge the scope/permission set as well. This provides the capability to enforce various kinds of policy combining strategies. For instance, in your example of the so called “data blocking”, if the organizational policies override patient consent, then the downstream AS should be configured with the combining policy that combines the decisions that way. Likewise, if the patient consent overrides, the respective combining policy can be stated at the downstream AS. Other combining logics (e.g. simple AND/OR, majority vote, and more sophisticated combining logic with respect to scopes/permissions) can be implemented in a similar vein (*). In all of these cases, the design is the same and thus is agnostic to the particular policy/configuration —be it authorization policy, or decision combining policy.

· I think leaving the cascaded authorization logic to out-of-band protocols, is outside the scope of this discussion and somehow beside the point. We are in a standard WG because to standardize the flow where multiple policy authorities host their own respective ASes which is a generalization of the basic UMA use-case.  Of course, this, or for that matter, even the main authorization use-case of UMA, can all be considered out of band but that’s not the point.

Regards,

Mohammad

(*) To clarify a technical detail, I’m aware that if any of the upstream RPTs refuse to issue the RPT altogether (a 403) then the flow halts and this means a disjunctive (OR) combining can’t take place. However, this can be fixed by having the upstream ASes issue an RPT with an empty scope/permission set when they intend to deny an access so that the flow can move on.

*260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers:* Recall that the use case (from the FHIR world) is that the RS has "edge authorization" it needs to perform, which it has ensconced in enterprise policies in its own authorization server. This is a way to have the "Adrian clause" reified in RPTs, and the client/RqP meet multiple sets of policy conditions, all the way. This connects to the shoebox question if you can get the RS to report what they've done. In the swimlane, the "downstream AS" is Alice's and the "upstream AS" (and any further upstream ones) belongs to the RS. So, in a way, this has positives and negatives: the incentives change because on the one hand an RS gets a lot more formal and dynamic control of liability, but on the other, it can control much more strongly what Alice gets to share, possibly enabling "data blocking" (a phrase from the health world).

This has been done as an extension already, so it could remain an extension for now. It has "set math" implications, because it introduces another set.

Eve's observations about the flow:

   - AS needs to know about the other AS because it's a client of the

   permission request endpoint

   - Client needs credentials for the upstream AS(s) too

   - Client needs to keep an "AS stack" and to hold multiple RPTs for "that

   resource" (whatever that means to the client)

   - (George added:) There's new set math that each downstream AS has to

   calculate

Kathleen Connor

VHA Security Architecture – Framework Engineering

(Edmond Scientific Company)

HL7 Security and Financial Management Cochair

Office - 360 357 3536 [Primary]

Cell – 360 480 7599