Minutes

Roll call

Quorum was not reached.

Approve minutes

• Approve minutes of UMA telecon 2020-10-15

Deferred.

Policy Manager draft - review text

• Policy data model email sent by Alec

The one needed field is to specify the required values in order to achieve interoperability. Alec's first attempt at an example is for something like a Google Doc Share button for Comment access. The second example starts to get hairy. In specifying required claims, how long can we avoid starting to define a "minimum viable required claims language" for ROs to use that "doesn't need to look like a policy language"?

In the solutions with which Identos has deployment experience, how much flexibility does the RO really need? Not much, because the community AS sort of manages to limit the options in a reasonable manner given the actual community. The APIs and scopes are fixed, the packages of client requests are fixed, and so what the clients can get access to is fixed, and in their specific case, the RqP == the RO.

For dynamic APIs that rely on an ID token for invocation context, like FHIR with patient ID, UMA becomes less friendly.

Even dictating "required claims", we're sort of getting into the policy game a little bit. It seems like a slippery slope. And yet we don't think the RO really cares about the choice of language. An architecture where the AS would be a client of policy information points (PIPs) that could all speak the same policy language by agreement, even if the RO joined each pair together through OAuth in "protection API" fashion, would still be "paternalistic" rather than "self-sovereign" in outlook, though.  Our approach is intended to empower the RO more than that (and thus focuses on a client application the RO is able to choose).

We need to get clearer on our use cases/user stories. Our sample UX illustrated by Domenico doesn't (yet?) illustrate what happens if the client app interacts with multiple AS's. Can we construct user stories about what the RO wants to have happen when they have multiple AS's? multiple RS's (with resources that could be shared (and thus policy))? multiple RqP's necessitating sharing (and thus policy)? The answers to all this will dictate just what we need to solve in terms of policy and "required claims" interoperability. Alec is going to try to construct some.

Attendees

As of October 22, 2020 (pre-meeting), quorum is 6 of 11. (Michael, Karim, Domenico, Mike, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve)

1. Michael
2. Peter
3. Eve

Non-voting participants:

1. Alec
2. Scott
3. Kate
4. Anik

Regrets:

• Andi