UMA telecon 2020-09-03

Owned by Eve Maler
Last updated: Sep 03, 2020

UMA telecon 2020-09-03

Date and Time

Agenda

Minutes

Roll call

Quorum was not reached.

Approve minutes

Deferred.

PKCE status

Alec edited the UIG with the new text. People can take a look and see what they think.

Relationship Manager profile

See the policy manager API in this email thread. Also see Policy Manager Extension #363. Eve proposed a list of things to discuss and Adrian added one more thing:

- One API (AS only) or two (also RS)?
- (Each) API protection model?
- Topological and trust assumptions or lack thereof? What can be co-located? How many of each thing can there be?
- Any rules needed for policy (“policy condition”) priority between RM and AS (the “cascading” scenario)
- A clean way to model or illustrate the scenario when the RS is hosting claims (the “turtles” scenario)
- Customer requests for functionality that Eve discussed last time – this was the discussion of consent management servers (CMS's)

Would these (putative) CMS's have "read/write" APIs that allow resource owners to "put policies into" any of the servers? (What Adrian has been thinking of as bidirectional APIs.) Nancy notes that think hasn't been discussed in quite some time and these don't exist yet. A privacy concern is that a user (RO) who has a policy that touches on, say, HIV information would be potentially revealing to a server that they have HIV. Adrian agrees that policies are personal information – "they need to be protected as if they were private keys". Organizational policies of the enterprise, which could include authorization policies and other operational policies – should be safe. The RS gets to publish openly any "XACML fragments" (bits of policy, doesn't have to be XACML) that represent its own policies. The AS gets to pick up these fragments and combine them with whatever policies the RO chooses to add. (If XACML is actually used, then this usage pattern exemplifies a way that it was meant to be used – combinatorially, with priority able to be established.)

"Consent work" would need to be done to figure out the downstream privacy implications of combining these policies. Where would this work take place? HEART? Here? Somewhere in the SSI community? Eve has been wondering how bad the situation is wrt policies as PI: doesn't any one AS have to know some policies (if not "all the policies of an RO") in order to function, and so doesn't some PI have to pass to a server that may possibly at best be a limited fiduciary?

The requirement Alec was trying to meet was for the AS – through the relationship with the RM (or PM or whatever we end up calling it) – to not see PHI (PI) such as an email or birthdate of the RO's. The "Nancy paradox" is that policies are also PI. The policy manager gives the opportunity to generate random UUID's and tie those to the relevant policies that the AS needs in order to grant access, issue tokens, etc.

This was also the motivation for the resource definitions work. If a RO uses a service/app (client) for the first time and doesn't trust it (fully) yet, they can nonetheless see the scopes and resources they're about to grant access to by virtue of the client becoming "operational enough" through meeting the requirements for the patterns it was registered for.

Andi asks: How much of this needs to be made interoperable in a spec, and how much of this is implementation choice? Alec brought up the pseudonymous stuff because that's what they implemented. We totally want to understand if there are multiple applications of the base technology. For example, Domenico's work illustrating a "widget" for a policy manager way back when (see slides 10 and 15 here) was one such application. Slide 15 in particular shows how Alice is protecting her photo with UMA. Bob is presenting claims in order to get access to it. What if those claims are UMA-protected? Can we call that a "trusted claims" scenario? (Eve was calling that the "turtle" scenario for "turtles all the way down" but that didn't gain favor.) This scenario doesn't depend on using policy managers but could use it.

What scenarios do we actually have here? What does "cascading" mean? Eve thought it was combining policies from multiple sources so that an AS can function when it needs to. There is only one final AS that operates to grant access and issue access tokens, even if there are multiple AS's (as in the Pauldron/VA type of scenario).

Adrian has testified that something like HEART's "btg" ("break the glass") scope implementation scenario should be an instance of the RS (not the AS) needing to being able to observe a jurisdictional or regulatory policy, and so it needs to use the "Adrian clause".

If we are able to nail down these concepts and terms, do we require an interoperable policy language to make any of them work, or not?

Attendees

As of September 3, 2020 (pre-meeting), quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve)

  1. Michael
  2. Domenico
  3. Andi
  4. Eve

Non-voting participants:

  • Alec
  • Patrick
  • Scott
  • Adrian
  • Nancy
  • Tim