Child pages
  • UMA telecon 2020-10-29
Skip to end of metadata
Go to start of metadata


UMA telecon 2020-10-22

Date and Time

Agenda

Minutes

Roll call

Quorum was not reached.

Approve minutes

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)

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

Non-voting participants:

  1. Adrian
  2. Nancy
  3. Kate
  4. Scott
  5. Colin

Regrets:

  • Andi
  • George
  • No labels

1 Comment

  1. Notes presented for discussion:

    UMA's promise is wide-ecosytem, one with many clients interoperably use my resources. Where my resources are protected by an AS where I can register my policy


    Interop (RS/C)
    - for content-type/download no issues, eg here is a url to an image
      - for APIs more challenging. Collapses the 'wide-ecosystem' since client software must understand RS API
      - for policy decision to be meaningful, the AS must be able to present to Alice some understanding of the resources/scopes being protected...
      - DATA MODEL, standard(should support WIDE) vs custom(necessarily NARROW)

    Integration/Authz Protocol
    - there has to be some trust model between RS<>AZ/IDP<>C ie a certifying party
      - in OIDC/OAuth this is the AS/IDP and the resource. It maintain it's client list
      - in UMA assert that it is the RO. RO tells the RS which AS to trust, and controls the clients/rqps trusted by the AS
    - the AS also requires certification beyond the dl/content-type resources, or where the ownership is less clearly defined between the RO and RS
    -  TRUST MODEL


    I also observe that I've never had a relationship with an RS which wasn't also an AS/IDP.


    Given the above, my hypothesis is that there will be many groups of trusting RS/AS/C that serve some known user population (RO/RQP) over some set of resource/API types. Users would be identified either by an AS or RS


    The goal of these extensions is to provide Alice a single place to many resources and policy across certifying domains.

    As a RS, I need to expose available resource to Alice, in order for her to choose how to put those resources under protection

    As a AS, I need to expose the policy conditions I can enforce, in order for Alice to select how her resources will be protected