UMA telecon 2020-10-22

Date and Time

Primary-week Thursdays 6:30am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
- United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2020-10-15, 2020-10-22
Chair and legal editor positions up for annual term
Policy Manager draft text
IIW recap
AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2020-10-15, 2020-10-22

Deferred.

Chair and legal editor positions up for annual term

Taking nominations

Policy Manager draft text

Alec has worked on some user stories (attached to the minutes doc), going back to some of his original work. He has incorporated some of our "wide-ecosystem" and "client trust" thinking. What ecosystem, specifically, is wide here? Adrian's goal tends to be that the RO gets total control ("self-sovereign", not classic federation). Alec struggles with SSI in that the wallets have no certification. Could the AS help with that role? Alec suggests there are two themes: interoperability between the RS and client, and integration. Or maybe better stated, it's "data model" vs. "trust model". They get really conflated all the time.

FedZ Sec 1.4 says "The resource server defines the boundaries of resources and the scopes available to each resource, and interprets how clients' resource requests map to permission requests, by virtue of being the publisher of the API being protected and using the protection API to communicate to the authorization server." That's data model stuff: the RS defines its data model, and that of necessity collapses the trust model to some extent (narrows the ecosystem of potential clients somewhat) because only some clients will ever work with that data model. Standard data models such as FHIR are intended to widen ecosystems: to make it possible for more clients to work. The Resource Definitions solution was meant to try and ease the fact that the onus falls on the client to say what profile of the API it supports.

There has to be some trust model between RS/AS/C, that is, a certifying party. The IdP in OIDC maintains its own client list. What is the case in UMA? The RO might or might not have total control of an AS they use. The AS could have a number of ways to control whether a client (vs. a RqP) is sufficiently untrustworthy that it: a) doesn't get client credentials (say, because it doesn't have a good software statement); 2) isn't allowed to continue with the token-getting protocol; or 3) doesn't get an RPT or permissions it needs for access. The RS could use the Adrian clause. But on what basis – does the RS see the client's software statement? No, not at least within an UMA context. It could detect a device footprint or similar.

Let's say we're applying UMA hypothetically to the Data Transfer Project, which is very RS-centric, and ROs can choose their AS. It serves a population of users, which constrains clients by API type, making the ecosystem not perfectly "wide". People's relationships with RS's today include a bundled AS/IdP.

UDAP is an example of an RS/AS/C certifying party. It's about the trust model, not about the data model, and it's about the trust model in an OAuth context. Some people think UDAP and UMA are stark alternatives, but this analysis helps us start to show how this doesn't seem to be true.

We think we can make progress by applying the data model/trust model analysis and Alec's user stories.

Nancy is connected to the new DS4P work and can keep us in the loop, along with reaching out to Alec with her thoughts on consent servers.

Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Michael
Domenico
Alec
Eve

Non-voting participants:

Adrian
Nancy
Kate
Scott
Colin

Regrets:

Andi
George

Browser not supported