UMA telecon 2020-11-12

Owned by Alec Laws
Last updated: Nov 12, 2020
4 min read

UMA telecon 2020-11-12

Date and Time

Agenda

Minutes

Roll call

Quorum was not reached.

Approve minutes

Deferred

Policy Manager Draft


3. Client Trust

What do we mean by trusted claims? An UMA AS is totally open by definition. In practice an AS needs to trust the claims it can accept, or Alice can't set RqP policy against ANY IDP, only trusted ones


How does UMA fit into an existing enterprise with an IAM system? 

UMA looks towards a more consumer ecosystem, ie protect my photos from PhotoBucket at a separate AS. This is the narrative around 'controlling your own data'

Thomas get's a lot of traction with the use-case of a "Data-cooperative/data-trust", communities can get together and pool their data. The community can together host an AS. OAuth/OIDC are half-way to UMA. This is also similar to research/data-donation use-cases. Data still comes from enterprises, becomes controlled by the person. Question becomes "how can I use it?". From consumer side, Alice→Bob is the bigger UMA features over Alice→Alice access of data. Bob can be anyone

UMA shines in non-enterprise scenarios. Nancy notes that it needs to work in enterprise/cross-enterprise scenarios also. US doesn't have GDPR as driver, other health care rules are coming out driving to similar outcomes, patient centered records. 

Need to help people understand that UMA can still do all Alice→Alice flows of OAuth. True over protection mechanism, not the protocol flow. Needing only Alice→Alice shouldn't be a reason to select OAuth over UMA


Alec finds the RS-first UMA flow is hard for people to understand. George notes in consumer spaces that flows are often RS first, ex Using open table from a restaurant website, the resto first hits the RS. Challenge, getting multiple consumers products to agree on a single AS. Products do this from a federated authz perspective, not from a resource protection. RP treats the external AS as a form of authentication only. RS/RPs manage the identity locally, and federate out.

User-case: Ad-opt-outs across ad networks. Point ad network people to my service(RS) to get my preferences. Opt-out is broken due to third-party cookie blocking, eg impossible on safari


Use-case, delegation of consent. Alice has been released form the hospital and is being released to a Nursing Facility. The decision/consent capability can transfer to the new site, or stay with Alice.
Alice→AS: these people can access/modify policy for these resources. internal to AS

Alice→AS: these people can response to real-time consent requests

AS to itself: Alice is being transferred to site X, move consent ability to site X's staff

There is a "Hub" holding the patient record, and a separate UMA AS. As a patient moves from facility to facility, the new site is authorized to access the single health record.

Data-segmentation from privacy, (eg sens/* scopes in HEART). To support this, need for client to learn how to handle? NO, this is hidden in AS/RS in HEART. This is the path for scalability, limit the responsibility of each party


User Stories presented on screen:


-- resource definitions

As an RS, I need my API to follow recognized standards, in order for clients to use the API and Alice to have the greatest choice of clients

As an AS, I need to understand the meaning of resource types and scope, in order to help Alice create policy, in order to allow meaningful RS and Client registration

As an AS, I may allow clients to request permission tickets or push RARs, in order for clients to have AS-first flows, in order for clients to discover resource location

  • clarified that client isn't create the ticket, requesting using the permission API and AS returns the fresh ticket
  • need to get into the tech detail around the data model, reuse vs a new api endpoint

As an AS supporting AS-first flows, I may need to issue multiple tokens for a single client request, in order to provide properly C/RS constrained tokens

  • possible with a different grant_type to change the response, eg to an array of tokens
  • discussed up to here

-- trust model

As an RS, I need my resource capabilities verified/registered with/attested to by a trusted third party, in order ???

As an RS, I need to understand the trustworthiness of the AS, in order to effectively protect resources and serve Alice

As an AS, I should define sources of claims I trust, in order to define the target population

As an AS, I need to define conditions for client registration, in order for dynamic client/rs registration to be possible

-- policy manager

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

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 RS, I need to expose accepted ASs to Alice, in order for her to choose how to put those resources under protection


Attendees

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

  1. Thomas
  2. Michael
  3. Alec

Non-voting participants:

  1. George
  2. Vlad P
  3. Scott
  4. Kate
  5. Nancy

Regrets:

  1. Eve
  2. Domenico