UMA telecon 2020-11-12
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://kantarainitiative.org/confluence/display/uma/Calendar
- Approve minutes of UMA telecon 2020-10-15, 2020-10-22, 2020-10-29, 2020-11-05
- Continue Policy Manager / Trust Model discussion
Quorum was not reached.
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
As of October 26, 2020, quorum is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)
- Vlad P